On Mar 13, 2012 10:39 PM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On Mon, 12 Mar 2012 17:53:29 -0600
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> > As Alan said in other thread, it can be "fixed" (if you think is not
> > right) for some very specific cases. Alan mentioned servers, really
> > simple desktops with simple hotplug devices, and embedded systems. For
> > mdev to "fix" the situation in the general case, it would have to
> > cover all the setups udev covers. That means bluetooth devices
> > (including keyboards and mice), USB soundcards, touch screens and the
> > like, all of them being plugged and unplugged at any time in any
> > order.
> >
> > Maybe someday mdev will be able to handle all the cases that udev
> > does. If it does (which I honestly doubt), I'm pretty sure at that
> > point it would have become as complex as udev, if not more, and it
> > will probably need the same requirements that udev has. Including the
> > simple one that for mounting a filesystem, the plumbing needed to
> > mounting it has to be available before, and we cannot keep throwing
> > everything directly on / so it can mount /usr.
>
> I'm slowly coming round to this point of view too.
>
> If you want a full blown desktop machine with all the modern bells and
> whistles that always JustWorks(tm), realise that you have a complex
> system needing complex software. And udev is designed to deal with
> that. To accomplish this task, udev needs to apply some constraints.
>
> For almost everything else, that sophistication is not needed and
> simpler (i.e. less complex) software will suffice. Currently mdev (or
> something else like it) fills that needs.
>
> So 2 different scenarios with different solutions. Horses for courses.
>

Fully agree.

However, currently the 'less complex' mdev solution is not yet a 'first
class citizen' anywhere.

Rgds,