> 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. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
