devfsd/2.6.0-test1
Quoted 9 lines
Quoted 5 lines
Agreed, it should. However, the last version I pulled had zero support for probeall, and more importantly for probe, which is somewhat harder to do cleanly without having to rewrite the config file for each kernel you boot.
Well, it implements probeall in another fashion. Also, you might try
/sbin/generate-modprobe.confto convert a modules.conf to modprobe.conf syntax.
modprobe.conf syntax is easy to implement but unfortunately PITA to use. Exactly probe and probeall have been very helful in tracking module dependencies. Now you have arbitrary shell line that is near to impossible to parse in general.
I added half-hearted support to mkinitrd and initscripts for Mandrake but it will never be complete given the current situation.
Also I fixed devfsd to correctly use modprobe.devfs or modules.devfs depending on which kernel it runs on; patch has been sent both to lkml and devfs list and is included in current Mandrake devfsd.
actually adding probe and probeall is trivial enough, I did not want to base Mandrake packages on that to avoid incompatibility.
Quoted 2 lines
Also, read the threads on the list about udev/hotplug - apparently devfsd is going out ...
as long as you have memory-based /dev you need devfsd even if it is called differently.
-andrey
Quoted 9 lines · Andrey Borzenkov
Quoted 3 lines
Well, it implements probeall in another fashion. Also, you might try
/sbin/generate-modprobe.confto convert a modules.conf to modprobe.conf syntax.modprobe.conf syntax is easy to implement but unfortunately PITA to use. Exactly probe and probeall have been very helful in tracking module dependencies. Now you have arbitrary shell line that is near to impossible to parse in general.
True.
Quoted 7 lines
I added half-hearted support to mkinitrd and initscripts for Mandrake but it will never be complete given the current situation.
Also I fixed devfsd to correctly use modprobe.devfs or modules.devfs depending on which kernel it runs on; patch has been sent both to lkml and devfs list and is included in current Mandrake devfsd.
As I have it in Gentoo, it is done modprobe side, but only because its less patches (as Rusty already added the changes to his hack, plus the modprobe.devfs I sent him).
Quoted 3 lines
actually adding probe and probeall is trivial enough, I did not want to base Mandrake packages on that to avoid incompatibility.
Have you checked with Rusty yet if he will accept probe/probeall patches for module-init-tools ? I (IMHO) do not see why it should not be possible to add if its done cleanly, and do not break anything else.
Quoted 6 lines
Quoted 2 lines
Also, read the threads on the list about udev/hotplug - apparently devfsd is going out ...
as long as you have memory-based /dev you need devfsd even if it is called differently.
I have not looked at it myself, but as far as I have it, you do not mount /dev, and just need udev/hotplug/libsysfs (not sure on libsysfs). Currently udev still call mknod, but I think Greg said he will fix that in the future.
Regards,
Signature · 1 line
Martin Schlemmer
In message <[email protected]> you write:
Quoted 4 lines
Quoted 4 lines
modprobe.conf syntax is easy to implement but unfortunately PITA to use. Exactly probe and probeall have been very helful in tracking module dependencies. Now you have arbitrary shell line that is near to impossible to parse in general.
Sure. But probe and probeall isn't enough. You'll also want conditionals in the parsing of the config file, so you can do different things on different architectures or different kernel levels. You're going to lose, here, if you try to be general 8(
We already have one hook to do arbitrary things, and I think it's quite neat:
# Sound is complex.
install sound-slot-0 /sbin/configure-sound
Now, if you want to implement a meta-language that does all this, great! But I'm resisting new features in the base, because I have to support them, and I'm incredibly lazy.
Modules already have their own hard and soft dependencies. If you have an incredibly complex modprobe.conf, it's worth asking whether the correct solution is to make modprobe.conf's syntax more powerful, or look at making a more fundamental change...
Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 4 lines · Martin Schlemmer
Quoted 3 lines · Andrey Borzenkov
Quoted 2 lines
Also, read the threads on the list about udev/hotplug - apparently devfsd is going out ...
Quoted 8 lines
Quoted 3 lines
as long as you have memory-based /dev you need devfsd even if it is called differently.
I have not looked at it myself, but as far as I have it, you do not mount /dev, and just need udev/hotplug/libsysfs (not sure on libsysfs). Currently udev still call mknod, but I think Greg said he will fix that in the future.
What's wrong with calling mknod?
I did say I thought about calling sys_mknod directly from udev, but that's just a minor change. Is that what you were referring to?
thanks,
greg k-h
Quoted 14 lines · Greg KH
Quoted 4 lines · Martin Schlemmer
Quoted 3 lines · Andrey Borzenkov
Quoted 2 lines
Also, read the threads on the list about udev/hotplug - apparently devfsd is going out ...
Quoted 8 lines
Quoted 3 lines
as long as you have memory-based /dev you need devfsd even if it is called differently.
I have not looked at it myself, but as far as I have it, you do not mount /dev, and just need udev/hotplug/libsysfs (not sure on libsysfs). Currently udev still call mknod, but I think Greg said he will fix that in the future.
Quoted 5 lines
What's wrong with calling mknod?
I did say I thought about calling
sys_mknoddirectly from udev, but that's just a minor change. Is that what you were referring to?
Yep. Nothing major - I just want to remember somebody moaning about too much overhead with udev spawning for every event in /dev.
Cheers,
Signature · 1 line
Martin Schlemmer
Quoted 4 lines · Martin Schlemmer
Yep. Nothing major - I just want to remember somebody moaning about too much overhead with udev spawning for every event in /dev.
Yeah, that was a moan of someone who didn't really know what they were talking about :)
Not a real problem, move along, nothing to see here...
thanks,
greg k-h