On Fri, Sep 16, 2011 at 01:53:20PM +0200, Bernd Petrovitsch wrote: > On Don, 2011-09-15 at 22:32 +0200, Harald Becker wrote: > > > I don't think that mdev supports an mdev.conf.d/ sort of paradigm ... > > > > ... but we can implement that /etc/mdev.d feature ... it is not too > > difficult to do. > > > > With an /etc/mdev.d system it would be easy for other packages to add > > mdev rules to the system. That way we do not mangle with /etc/mdev.conf > > in every package and scripting would be a lot easier. > > Not that I'm an udev or mdev expert but what's then the difference to > udev?
Unfortunately I'm not a udev or mdev expert either, but: udev has udevd instead of being a run-once deal. mdev can be registered into /proc/sys/kernel/hotplug and be run for every device add/remove event, where udev appears to receive kernel events using a different mechanism. Adding /etc/mdev.d would not make mdev into udev, it would just make mdev more modularly configurable which works with the concept of software packages. > Supporting the same features in quite similar way make me fear that it > will be similarly slow. Well, from what I understand, mdev parses through the entire /etc/mdev.conf file for every device it discovers (I think it does this even when running `mdev -s' which scans all existing devices). This makes mdev smaller and simpler, but probably less efficient than a daemon which parses and caches the whole configuration (like udevd). Adding a bunch of rules to mdev with more hooks and having it parse multiple files in an mdev.conf.d definitely would decrease the efficiency of a system with an mdev setup. But it would still be a simpler and perhaps easier to understand setup than a udevd one(?) -- binki Look out for missing or extraneous apostrophes!
pgpa9N5FjmF4Y.pgp
Description: PGP signature
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
