[arch-dev-public] rootprefix change for kmod 10
Hi all, I've been talking to Thomas about this, and we've come to the conclusion that it's probably just broken to continue shipping kmod built with a rootprefix. I think there's been two recurring problems coming up that make this revert warranted: - It makes building kernels for other distros not fun - The kernel doesn't really support it. Various Kbuild targets just break with no clean fix available. kmod 10 is to be released quite soon, and I'm planning on building without the rootprefix. It should not affect us in any real way at this point, given that /lib is now a symlink. It does mean that for the next kernel built, we'll need to make a minor adjustment to the kernel PKGBUILDs: running depmod before moving the module dir instead of vice versa. I can fix this myself in SVN when I push kmod-10 to [testing]. I've been running my own kmod without the rootprefix for the past month and change and haven't run into any problems. The only oddity is that modinfo will report "bogus" paths (/lib/modules, not /usr/lib/modules). mkinitcpio and other tools have no problems with this. The ideal solution to this, in the end, is probably to introduce another flag to kmod tools to specify the base dir at runtime, rather than at compile time. When I get some time, I'll talk to upstream and see if they're amiable to the idea. Cheers, Dave P.S. I'd also like to see us stop shipping compressed modules, but that's another matter all together.
Am 06.09.2012 21:30, schrieb Dave Reisner:
P.S. I'd also like to see us stop shipping compressed modules, but that's another matter all together.
Why? The linux package is huge as it is, and compressing modules decreases its installed size by 100MB IIRC.
On Fri, Sep 7, 2012 at 9:14 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 06.09.2012 21:30, schrieb Dave Reisner:
P.S. I'd also like to see us stop shipping compressed modules, but that's another matter all together.
Why? The linux package is huge as it is, and compressing modules decreases its installed size by 100MB IIRC.
I looked into this in the past and intended to suggest the same . If I remember correctly the installed size savings is 80MB, but if you use filesystem level compression the savings is only between 10MB and 40MB (hopefully a future btrfs release will allow us to get numbers with better precision). Also, the package size becomes smaller if the modules are not compressed separately, but I forgot exactly by how much. -t
On Fri, Sep 7, 2012 at 11:17 AM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Sep 7, 2012 at 9:14 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 06.09.2012 21:30, schrieb Dave Reisner:
P.S. I'd also like to see us stop shipping compressed modules, but that's another matter all together.
Why? The linux package is huge as it is, and compressing modules decreases its installed size by 100MB IIRC.
I looked into this in the past and intended to suggest the same . If I remember correctly the installed size savings is 80MB, but if you use filesystem level compression the savings is only between 10MB and 40MB (hopefully a future btrfs release will allow us to get numbers with better precision). Also, the package size becomes smaller if the modules are not compressed separately, but I forgot exactly by how much.
Just checked with linux-3.5.3-1-x86_64. gzipped modules --------------- package: 42M installed: 59M uncompressed modules -------------------- package: 30M installed: 142M I prefer the much smaller installed size myself. :)
Am 07.09.2012 10:49, schrieb Evangelos Foutras:
I looked into this in the past and intended to suggest the same . If I remember correctly the installed size savings is 80MB, but if you use filesystem level compression the savings is only between 10MB and 40MB (hopefully a future btrfs release will allow us to get numbers with better precision). Also, the package size becomes smaller if the modules are not compressed separately, but I forgot exactly by how much.
Just checked with linux-3.5.3-1-x86_64.
gzipped modules --------------- package: 42M installed: 59M
uncompressed modules -------------------- package: 30M installed: 142M
I prefer the much smaller installed size myself. :)
Thanks for those numbers, that is about how I remember it. Regarding Tom's comment about file system level compression: The only file system we support that does this is btrfs, which is still considered experimental. The .gz compression benefits the majority of our users. If depmod is buggy regarding the .gz modules, then it should be fixed (I remember it behaved inconsistently when mixing compressed and non-compressed modules).
On Fri, Sep 07, 2012 at 11:31:55AM +0200, Thomas Bächler wrote:
Am 07.09.2012 10:49, schrieb Evangelos Foutras:
I looked into this in the past and intended to suggest the same . If I remember correctly the installed size savings is 80MB, but if you use filesystem level compression the savings is only between 10MB and 40MB (hopefully a future btrfs release will allow us to get numbers with better precision). Also, the package size becomes smaller if the modules are not compressed separately, but I forgot exactly by how much.
Just checked with linux-3.5.3-1-x86_64.
gzipped modules --------------- package: 42M installed: 59M
uncompressed modules -------------------- package: 30M installed: 142M
I prefer the much smaller installed size myself. :)
Thanks for those numbers, that is about how I remember it.
Regarding Tom's comment about file system level compression: The only file system we support that does this is btrfs, which is still considered experimental. The .gz compression benefits the majority of our users.
If depmod is buggy regarding the .gz modules, then it should be fixed (I remember it behaved inconsistently when mixing compressed and non-compressed modules).
I recall this too. kmod's depmod doesn't suffer from this. The library side does filetype detection on open(), and picks the correct load and unload functions for that specific file. All of kmod's tools will magically just do the right thing. I'm going to assume by the lack of interest in the original post's content that no one has any objections to the change, and will roll that out today. d
Am 06.09.2012 21:30, schrieb Dave Reisner:
Hi all,
I've been talking to Thomas about this, and we've come to the conclusion that it's probably just broken to continue shipping kmod built with a rootprefix. I think there's been two recurring problems coming up that make this revert warranted:
- It makes building kernels for other distros not fun - The kernel doesn't really support it. Various Kbuild targets just break with no clean fix available.
kmod 10 is to be released quite soon, and I'm planning on building without the rootprefix. It should not affect us in any real way at this point, given that /lib is now a symlink. It does mean that for the next kernel built, we'll need to make a minor adjustment to the kernel PKGBUILDs: running depmod before moving the module dir instead of vice versa. I can fix this myself in SVN when I push kmod-10 to [testing].
Whatever, go ahead. Any thoughts about a proper fix in kmod yet?
On Fri, Sep 07, 2012 at 04:39:09PM +0200, Thomas Bächler wrote:
Am 06.09.2012 21:30, schrieb Dave Reisner:
Hi all,
I've been talking to Thomas about this, and we've come to the conclusion that it's probably just broken to continue shipping kmod built with a rootprefix. I think there's been two recurring problems coming up that make this revert warranted:
- It makes building kernels for other distros not fun - The kernel doesn't really support it. Various Kbuild targets just break with no clean fix available.
kmod 10 is to be released quite soon, and I'm planning on building without the rootprefix. It should not affect us in any real way at this point, given that /lib is now a symlink. It does mean that for the next kernel built, we'll need to make a minor adjustment to the kernel PKGBUILDs: running depmod before moving the module dir instead of vice versa. I can fix this myself in SVN when I push kmod-10 to [testing].
Whatever, go ahead.
Any thoughts about a proper fix in kmod yet?
I think the proper way to do this is to introduce a new flag to give the full path to the module dir, e.g. depmod -M /some/chroot/usr/lib/modules -k 3.5.3-1-ARCH ...would refer to modules in /some/chroot/usr/lib/modules/3.5.3-1-ARCH This might even get rid of rootprefix entirely, and kmod will "forever" default to /lib/modules. Maybe in a decade this could change. kmod-10 is in testing, and I've fixed linux and linux-lts packages in SVN. I did a compile test of linux, installed it, and made sure kmod still found modules. I trusted that the exact same change in linux-lts would yield the same results. This has _not_ been archrelease'd yet, but it will be when we move kmod to [core] (there will not be a pkgrel bump). This of course assumes that there isn't a release of 3.5.4 before then. dave
participants (4)
-
Dave Reisner
-
Evangelos Foutras
-
Thomas Bächler
-
Tom Gundersen