On Mon, Sep 19, 2011 at 5:44 PM, Laurent Bercot <[email protected]> wrote: >> what worries me most is all the apps that depends on libudev (xorg, >> gvfs, etc). Those will still need udev for the full "experience" > > What these apps need is an implementation of the libudev API, not > necessarily the original libudev. > > I have just taken a look at the libudev API documentation. It's not > overly complex, and it's sensible for the most part; I could probably > provide an alternative libudev fast enough if needed. > > The real remaining problem is the library's backend, as in how to > design a simpler, more modular, but fully functional udev implementation. > mdev is a start, but it needs to be expanded if libudev functionality is > needed. > I wouldn't worry too much, though. libudev-using programs are usually > behemoths that you would not run on embedded systems; on systems where you > need them, you can afford to run a full udev. Providing a full-fledged > alternative udev implementation is mostly aesthetics at this point.
I thought the goal was to get rid of udev due to arrogant attitude from developer, doing things like requiring /usr merge in to / without caring what distros other than Fedora/RedHat thinks. Its generally a good idea with standards and more than one implementation of a standard. If the goal was only to solve problem for embedded systems then would probably devtmpfs be good enough? -- Natanael Copa _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
