On 09/20/2011 05:34 AM, Natanael Copa wrote:
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.
I agree. But I think in order to do that, we'll need an mdevd binary
that uses the libudev API as mentioned by Laurent.
Its generally a good idea with standards and more than one
implementation of a standard.
Again, I agree. If Laurent wouldn't mind contributing talents as was
stated in one of the last posts, I think the mdev "suite" would be a
very nice lightweight alternative to udev (with the advantage of not
being dependent on /usr too)! I know I'd use it as much as possible. :)
If the goal was only to solve problem for embedded systems then would
probably devtmpfs be good enough?
Now that Denys has applied the file reading patch, shouldn't that speed
things up considerably for mdev? And if so, what advantage would there
be with using devtmpfs?
Dave
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
