There are various practices around about where to install extra kernel modules, I thought I'd throw in a quick RFC about what people think is the best practice, and why. Some alternatives off the cuff:
0) Somewhere directly below /lib/modules/$uname, in a per-package subdir. 1) A suitable location below /lib/modules/$uname/kernel. 2) /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable. 3) Same as 2), but s/updates/$something_else_than_updates/. 4) As long as it Just Works(tm), does not matter. 5) Insert your favourite here.
Status of how things seem to be "out there" currently, based on a very brief look: - fedora.us: both 0 (for thinkpad) and 1 (for alsa) - livna.org, Dag, freshrpms (FC1/alsa only checked): 1 - ATrpms: 2 - CCRMA uses something that doesn't fit 100% any of the above, but I guess 2 would be the closest.
My .02€ of the above:
0) Yuck, gets messy. 1) IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor. 2) My #1 pick as of now, maybe, depending on 3) below. 3) Is this better or worse than 2)? Dunno. Is "updates" the only dir that Just Works in earlier distro versions? Is using "updates" more or less likely to cause conflicts than "extra" or something else? Is it a bad thing to put all these extra modules to "updates", when the vast majority of them are not updates per se, but "new" modules instead (in the sense that they're not included in the vendor's kernel)? 4) I would feel more comfortable with some kind of documented guidelines or best practices, for consistency.
Comments?
Ville Skyttä wrote :
- Somewhere directly below /lib/modules/$uname, in a per-package subdir.
- A suitable location below /lib/modules/$uname/kernel.
- /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable.
- Same as 2), but s/updates/$something_else_than_updates/.
- As long as it Just Works(tm), does not matter.
- Insert your favourite here.
[...]
My .02___ of the above:
- Yuck, gets messy.
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
- My #1 pick as of now, maybe, depending on 3) below.
- Is this better or worse than 2)? Dunno. Is "updates" the only dir that Just Works in earlier distro versions? Is using "updates" more or less likely to cause conflicts than "extra" or something else? Is it a bad thing to put all these extra modules to "updates", when the vast majority of them are not updates per se, but "new" modules instead (in the sense that they're not included in the vendor's kernel)?
- I would feel more comfortable with some kind of documented guidelines or best practices, for consistency.
Comments?
I definitely wouldn't mind going for 2) or 3). Having the sub-dir called something else than "updates" for kernel modules that are already existing in the original "kernel" module tree could lead to confusion, no? Also, the most important point I think is to be sure that the location where the separately packaged modules are installed gets precedence over the original "kernel" module tree, in order to make sure we can package more recent versions of modules already shipped with the kernel and have those loaded instead of the default ones. I'd go for "updates".
BTW, what I do currently is 1) but also 2) ("updates" without mirroring the structure, though) for modules already shipped with the kernel (pwc/pwcx for instance).
Matthias
On Sun, Sep 12, 2004 at 09:51:04PM +0300, Ville Skyttä wrote:
There are various practices around about where to install extra kernel modules, I thought I'd throw in a quick RFC about what people think is the best practice, and why. Some alternatives off the cuff:
- Somewhere directly below /lib/modules/$uname, in a per-package subdir.
- A suitable location below /lib/modules/$uname/kernel.
- /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable.
- Same as 2), but s/updates/$something_else_than_updates/.
3a) lkml style is s/updates/extra/, but last time I checked it flattened the directory structure (in contrast to 2).
- As long as it Just Works(tm), does not matter.
- Insert your favourite here.
Status of how things seem to be "out there" currently, based on a very brief look:
- fedora.us: both 0 (for thinkpad) and 1 (for alsa)
- livna.org, Dag, freshrpms (FC1/alsa only checked): 1
- ATrpms: 2
- CCRMA uses something that doesn't fit 100% any of the above, but I guess 2 would be the closest.
My .02€ of the above:
- Yuck, gets messy.
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
- My #1 pick as of now, maybe, depending on 3) below.
- Is this better or worse than 2)? Dunno. Is "updates" the only dir that Just Works in earlier distro versions? Is using "updates" more or less likely to cause conflicts than "extra" or something else? Is it a bad thing to put all these extra modules to "updates", when the vast majority of them are not updates per se, but "new" modules instead (in the sense that they're not included in the vendor's kernel)?
- I would feel more comfortable with some kind of documented guidelines or best practices, for consistency.
Comments?
I think I'd prefer 2) ;)
I am not really happy with the name of "updates", due to the reasons you state above, but it has already become traditional, is used by other distros (at least SuSE) as well, some kernel module software starts changing /extra/ to /updates/ also, and finally modutils give /updates/ preference over the rest [*] (the latter is technically very important, any other scheme needs to get modutils adjusted first).
OTOH /extras/ (3a above) is what the kernel developers have currently blessed, but the flat structure is irritating.
On the linguistic side both updates and extras are sometimes out of scope. "external" or similar would be more to the point.
There is some inertia toward /updates/ (modutils gives preferencs, some distros like SuSE already use it, ATrpms uses it ;), some upstream kernel modules start to use it.
Perhaps this discussion should move to lkml. I think it is important to have a coherent approach (non-packagers and packagers) here.
[*] this is half true, for FC2-shipped modutils this was forgotten, but there is a bugzilla entry with appropriate patches that hopefully made it for FC3.
On Mon, 2004-09-13 at 12:07 +0200, Axel Thimm wrote:
[*] this is half true, for FC2-shipped modutils this was forgotten, but there is a bugzilla entry with appropriate patches that hopefully made it for FC3.
thomasvs's patches are in upstream module-init-tools now (well, at least, equivalent functionality is; istr that Rusty did the implementation slightly differently)
Jeremy
On Mon, Sep 13, 2004 at 08:21:13AM -0400, Jeremy Katz wrote:
On Mon, 2004-09-13 at 12:07 +0200, Axel Thimm wrote:
[*] this is half true, for FC2-shipped modutils this was forgotten, but there is a bugzilla entry with appropriate patches that hopefully made it for FC3.
thomasvs's patches are in upstream module-init-tools now (well, at least, equivalent functionality is; istr that Rusty did the implementation slightly differently)
But he did uses /updates/ and not /extra/ as the preferred path for looking up modules?
It looks like even in kernel hacker land there is still no real consensus on where exernal modules should get placed in.
On Mon, 2004-09-13 at 13:07, Axel Thimm wrote:
OTOH /extras/ (3a above) is what the kernel developers have currently blessed, but the flat structure is irritating.
Agreed. But if that has some sort of blessing, I think it would be good to either follow the blessed structure, irritating or not, or not to install into this dir at all. I would personally go for the latter :) (and just use updates/ for everything at least until extras/ becomes a more prominent "standard").
By the way, you used both extra/ and extras/ in your message, I assume only one of them is "correct"?
It seems that alternative 2 in my original mail (updates/ with mirroring the dir structure from kernel/ where applicable) has received most +1's so far.
On Tue, Sep 14, 2004 at 10:02:32AM +0300, Ville Skyttä wrote:
On Mon, 2004-09-13 at 13:07, Axel Thimm wrote:
OTOH /extras/ (3a above) is what the kernel developers have currently blessed, but the flat structure is irritating.
Agreed. But if that has some sort of blessing, I think it would be good to either follow the blessed structure, irritating or not, or not to install into this dir at all. I would personally go for the latter :) (and just use updates/ for everything at least until extras/ becomes a more prominent "standard").
Yes, it looks like this is an area of flux. modutils /upstream) seems to prefer /updates/, the kernel sources themselves /extra/. Given that this is a "recent" change (2.6), there is probably still space for convergence.
By the way, you used both extra/ and extras/ in your message, I assume only one of them is "correct"?
Sorry, the /extra/ is correct. Here is the relevant Makefile snippet (from scripts/Makefile.modinst):
modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D))
A trivial patch would be
-modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),extra/,kernel/$(@D)) +modinst_dir = $(MODLIB)/$(if $(filter ../% /%,$@),updates/$(@D),kernel/$(@D))
This would make the kernel sources do the right thing in the sense of alternative 2).
It seems that alternative 2 in my original mail (updates/ with mirroring the dir structure from kernel/ where applicable) has received most +1's so far.
If we feel confident that this is the way to go (aka there are not objections), we should submit the patch above and see what the reaction is.
Hi *
Am Sonntag, den 12.09.2004, 21:51 +0300 schrieb Ville Skyttä:
There are various practices around about where to install extra kernel modules, I thought I'd throw in a quick RFC about what people think is the best practice, and why. Some alternatives off the cuff:
- Somewhere directly below /lib/modules/$uname, in a per-package subdir.
- A suitable location below /lib/modules/$uname/kernel.
- /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable.
- Same as 2), but s/updates/$something_else_than_updates/.
- As long as it Just Works(tm), does not matter.
- Insert your favourite here.
Status of how things seem to be "out there" currently, based on a very brief look:
- fedora.us: both 0 (for thinkpad) and 1 (for alsa)
For alsa (and some other things at livna.org) I decided to install it there, where the module would have been installed by the original scripts during a normal install.
[...]
- Yuck, gets messy.
++
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
I don't think it's a problem. I think installing the module exactly at the same place where it normally would have been installed when you compile it also has a lot of benefits.
- My #1 pick as of now, maybe, depending on 3) below.
But do we really need to mirror the stucture? Is there any benefit in doing so? Why not a simple per-package dir?
Otherwise I don't have any strong opinions. I tend a bit more to 1), but can also live with either 2) or 3)
Hi,
On Mon, Sep 13, 2004 at 04:42:52PM +0200, Thorsten Leemhuis wrote:
Am Sonntag, den 12.09.2004, 21:51 +0300 schrieb Ville Skyttä:
There are various practices around about where to install extra kernel modules, I thought I'd throw in a quick RFC about what people think is the best practice, and why. Some alternatives off the cuff:
- Somewhere directly below /lib/modules/$uname, in a per-package subdir.
- A suitable location below /lib/modules/$uname/kernel.
- /lib/modules/$uname/updates, mirroring the dir structure from /lib/modules/$uname/kernel as applicable.
- Same as 2), but s/updates/$something_else_than_updates/.
- As long as it Just Works(tm), does not matter.
- Insert your favourite here.
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
I don't think it's a problem. I think installing the module exactly at the same place where it normally would have been installed when you compile it also has a lot of benefits.
You never know what the next kernel upgrade will look like (look at firewire), the vendor namespace should be left alone, so that no unnecessary migrations and specfile editing occurs.
It is just like the case of /usr vs /usr/local or perl's perl/vendor/site hierarchies, where you mirror the substructures starting at different tree starts depending on origin.
On Mon, 2004-09-13 at 17:42, Thorsten Leemhuis wrote:
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
I don't think it's a problem. I think installing the module exactly at the same place where it normally would have been installed when you compile it also has a lot of benefits.
Could you elaborate on "lot of benefits", it is not at all clear to me. Axel already commented why intruding this "vendor space" can cause problems.
- My #1 pick as of now, maybe, depending on 3) below.
But do we really need to mirror the stucture? Is there any benefit in doing so? Why not a simple per-package dir?
Why not be consistent with what the kernel does? What benefits does a per-package dir approach have? If you are thinking about directory ownership in module packages, everything below _and including_ the "updates" or "extra" dirs should be owned by the module package(s) anyway because the kernel package does not create nor own them.
Am Dienstag, den 14.09.2004, 09:50 +0300 schrieb Ville Skyttä:
On Mon, 2004-09-13 at 17:42, Thorsten Leemhuis wrote:
- IMO shouldn't use "kernel" for stuff that is not included in kernel distributed by the kernel vendor.
I don't think it's a problem. I think installing the module exactly at the same place where it normally would have been installed when you compile it also has a lot of benefits.
Could you elaborate on "lot of benefits", it is not at all clear to me.
Mainly Documentation and Howtos of the external drivers. They all will tell you that you find the module in the place, where it is normally installed. I don't see why we should differ from those.
And if you install an RPM and later compile a newer driver version locally that is installed at the original place its always the version from the RPM witch will be used -- thats a bit confusing IMO.
Axel already commented why intruding this "vendor space" can cause problems.
I don't see the point here. We need to rebuild the RPM for each kernel anew so we can look after that.
Maybe it's something that (also) should be fixed upstream first, then everyone is happy ;-)
- My #1 pick as of now, maybe, depending on 3) below.
But do we really need to mirror the stucture? Is there any benefit in doing so? Why not a simple per-package dir?
Why not be consistent with what the kernel does? What benefits does a per-package dir approach have?
No strong arguments here. I just find a per-package dir a bit cleaner to read and see no benefits from the structure the kernel has. ;-) ls /lib/modules/uname/(extras|updates)/ simply would show which drivers are installed. No digging trough sub-directorys.
If you are thinking about directory ownership in module packages, everything below _and including_ the "updates" or "extra" dirs should be owned by the module package(s) anyway because the kernel package does not create nor own them.
Of course.
CU thl
-
Axel Thimm -
Jeremy Katz -
Matthias Saou -
Thorsten Leemhuis -
Ville Skyttä