| 1 |
The 05/01/12, Pandu Poluan wrote: |
| 2 |
|
| 3 |
> And mdev might be a 'toy' to you, but embedded Linux developers will |
| 4 |
> vehemently disagree with you. |
| 5 |
> |
| 6 |
> And based on the responses in this thread, server guys will also |
| 7 |
> disagree with you. |
| 8 |
|
| 9 |
On the embedded side, we need udev much more than you think to support |
| 10 |
bluetooth, tablet and so. Android uses udev. This is even more true when |
| 11 |
we know that users will expect to have any plugged-in devices at |
| 12 |
whatever boot time or runing system be working out of the box. BTW, this |
| 13 |
is not a major problem since embedded devices already often use initramfs. |
| 14 |
|
| 15 |
On servers, I wouldn't be surprised that hypervisor tools will expect |
| 16 |
/dev/cdrom instead of /dev/sr0. |
| 17 |
AFAIK, mdev doesn't provide persistent device names and changing a |
| 18 |
ethernet card might result in a highly broken system where udev will let |
| 19 |
all interfaces working but the changed one. Worse, I think mdev might |
| 20 |
change of device names upon reboot so that all ethernet devices can be |
| 21 |
mixed up in ways like eth0 -> eth1, eth1 -> eth3 and eth2 -> eth0. |
| 22 |
|
| 23 |
These are only few examples and this is whole mdev hack (requirements |
| 24 |
and consequences) that makes "mdev alternative" look like a toy. |
| 25 |
|
| 26 |
People thinking that mdev could replace udev even on embedded devices |
| 27 |
and servers are wrong for both current or longer term. |
| 28 |
You might like it or not but udev is a core system tool, nowadays. |
| 29 |
|
| 30 |
As admin, I will expect to have a initramfs and udev on linux systems |
| 31 |
whatever they are desktop, embedded or servers. Actually, I already rely |
| 32 |
on initramfs for all of these kind of systems for years with success. |
| 33 |
|
| 34 |
-- |
| 35 |
Nicolas Sebrecht |
Archives