FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 09-06-2012, 07:30 PM
Dave Reisner
 
Default 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.
 
Old 09-07-2012, 07:14 AM
Thomas Bächler
 
Default rootprefix change for kmod 10

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.
 
Old 09-07-2012, 08:17 AM
Tom Gundersen
 
Default rootprefix change for kmod 10

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
 
Old 09-07-2012, 08:49 AM
Evangelos Foutras
 
Default rootprefix change for kmod 10

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.
 
Old 09-07-2012, 09:31 AM
Thomas Bächler
 
Default rootprefix change for kmod 10

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).
 
Old 09-07-2012, 12:10 PM
Dave Reisner
 
Default rootprefix change for kmod 10

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
 
Old 09-07-2012, 02:39 PM
Thomas Bächler
 
Default rootprefix change for kmod 10

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?
 
Old 09-07-2012, 03:02 PM
Dave Reisner
 
Default rootprefix change for kmod 10

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
 

Thread Tools




All times are GMT. The time now is 02:57 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org