[gentoo-dev] rfc: virtual/modutils and module-init-tools

[gentoo-dev] rfc: virtual/modutils and module-init-tools

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

All,

in preparation to unmask udev-181, it was brought to my attention that a
number of packages in the tree have direct dependencies on
module-init-tools. Udev-181 requires kmod, which is a replacement for
module-init-tools.

I have added virtual/modutils to the tree which as of now prefers
module-init-tools over kmod.

The dependencies on module-init-tools in the tree should be changed to
virtual/modutils. I am willing to do this myself if no one objects. If I
do, should I open individual bugs for the packages?

Also, this brings up another question. I replaced module-init-tools in
the system set with virtual/modutils.  But, since it is possible to have
a linux system with a monolithic kernel, should this even be in the
system set? If not, once the dependencies are correct, I propose
dropping virtual/modutils from the system set.

On the other hand, if we want virtual/modutils in the system set, there
should be no dependencies in the tree  on virtual/modutils.

Thoughts?

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: virtual/modutils and module-init-tools

[Mike Gilbert]

On Sat, Feb 25, 2012 at 1:01 AM, William Hubbs <williamh@gentoo.org> wrote:
> If not, once the dependencies are correct, I propose
> dropping virtual/modutils from the system set.

If we drop it from the system set, the kernel modules section of the
handbook should be updated.

Re: [gentoo-dev] rfc: virtual/modutils and module-init-tools

[Robin H. Johnson]

On Sat, Feb 25, 2012 at 12:01:07AM -0600, William Hubbs wrote:
> The dependencies on module-init-tools in the tree should be changed to
> virtual/modutils. I am willing to do this myself if no one objects. If I
> do, should I open individual bugs for the packages?
As kernel-misc, I've fixed them all up.

> Also, this brings up another question. I replaced module-init-tools in
> the system set with virtual/modutils.  But, since it is possible to have
> a linux system with a monolithic kernel, should this even be in the
> system set? If not, once the dependencies are correct, I propose
> dropping virtual/modutils from the system set.
I think we should examine dropping virtual/modutils from system.
It'll be on most systems anyway however. It's needed to build any
kernel, so the only place where it won't be would be a system with a
monolithic kernel that was built on a different host and copied over or
used for booting without being on the filesystem (common in VMs).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Duncan]

William Hubbs posted on Sat, 25 Feb 2012 00:01:07 -0600 as excerpted:

> Also, this brings up another question. I replaced module-init-tools in
> the system set with virtual/modutils.  But, since it is possible to have
> a linux system with a monolithic kernel, should this even be in the
> system set? If not, once the dependencies are correct, I propose
> dropping virtual/modutils from the system set.

FWIW, I'm one of those monolithic kernel running folks.

I'm also one of those folks with everything the PM installs on rootfs, so 
haven't been affected by the reason for masking newer udev and thus I 
unmasked and installed it some time ago.

As such, I got udev-181 before it depended on kmod, and thus know that 
udev-181 won't build without it.

Given that udev-181 requires kmod, and while udev itself isn't in the 
system set, it's the preferred dep of virtual/dev-manager, which IS in 
the system set...

By udev-181, the vast majority of gentoo users who use udev WILL have kmod 
installed (and not module-init-tools, since it and kmod block each 
other), system-set, other dependency, or not, simply due to udev.

As such, IMO virtual/modutils doesn't need to be in the system set, 
because udev pulls it in.

Since most users have udev (and it's part of the stage-3 as the preferred 
dev-manager), they'll have kmod as a dependency and given its default-
USE, they'll normally have the module-init-tools compatibility symlinks, 
so module handling will work as it always has, for them.

As such, I disagree with floppym that the handbook's kernel module 
section needs updating for this, too.  The handbook doesn't even deal 
with non-default dev-managers, nor does it mention module-init-tools, it 
just assumes it's there.  Udev, as the default dev-manager, will be 
pulling in kmod already, with its default module-init-tools compatibility 
meaning no change in documentation necessary.  Only if we're going to 
start giving users dev-manager alternatives in the handbook does it 
become an issue, and while that would be nice, I don't think it's 
necessary for this change.

That leaves those using a dev-manager other than udev in a current 
installation who are depending on the current system set listing to bring 
in module-init-tools.  I believe busybox has it's own modutils as well, 
doesn't it, so that eliminates them.  Similarly, the fbsd folks aren't 
likely to be using Linux module-init-tools, right?

That leaves those still using kernel 2.4 and devfsd, and those using 
static-dev.

Is kernel 2.4 and devfsd still a supported option?  If not, that pretty 
much eliminates it.  If it /is/ still supported, maybe this can be our 
excuse to drop it?  Is that feasible, or are there users, perhaps on some 
of the supported exotic archs, for which kernel 2.6 and udev, etc, is not 
a viable option?

That means the static-dev folks, and possibly some still on 2.4 and devfs, 
if that's even still supported.  Static-dev could arguably pull in 
modultils as a dependency, or a news item could be created that triggered 
on static-dev installed.  Similarly for devfsd, if it's still supported.

> On the other hand, if we want virtual/modutils in the system set, there
> should be no dependencies in the tree  on virtual/modutils.

Good point.  Hopefully, tho, it can simply be removed from the system set.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Duncan]

Robin H. Johnson posted on Sat, 25 Feb 2012 07:21:40 +0000 as excerpted:

> I think we should examine dropping virtual/modutils from system.
> It'll be on most systems anyway however. It's needed to build any
> kernel, so the only place where it won't be would be a system with a
> monolithic kernel that was built on a different host and copied over or
> used for booting without being on the filesystem (common in VMs).

I beg to disagree.  I've been building monolithic kernels for years now, 
and had module-init-tools in package.provided and not on the system at 
all.

In fact, that's the case for both my main amd64 system and my 32-bit x86 
netbook system.  No module-init-utils.

You are however correct that it'll be on most systems, at least with 
udev-181, since udev won't build without kmod, now.  (I found that out 
when the build broke on me due to missing kmod, as I've had udev unmasked 
for awhile and got 181 before kmod was added as a dep.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Mike Gilbert]

On Sat, Feb 25, 2012 at 3:28 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> As such, I disagree with floppym that the handbook's kernel module
> section needs updating for this, too.  The handbook doesn't even deal
> with non-default dev-managers, nor does it mention module-init-tools, it
> just assumes it's there.  Udev, as the default dev-manager, will be
> pulling in kmod already, with its default module-init-tools compatibility
> meaning no change in documentation necessary.  Only if we're going to
> start giving users dev-manager alternatives in the handbook does it
> become an issue, and while that would be nice, I don't think it's
> necessary for this change.

Yes, I did not think that through. If kmod gets pulled in via udev in
the stage3 tarballs, the docs are fine as-is.

Re: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On Sat, Feb 25, 2012 at 08:44:39AM +0000, Duncan wrote:
> You are however correct that it'll be on most systems, at least with 
> udev-181, since udev won't build without kmod, now.  (I found that out 
> when the build broke on me due to missing kmod, as I've had udev unmasked 
> for awhile and got 181 before kmod was added as a dep.)

But, one thing about kmod is that you can turn off the command line
portions of it completely on a monolythic system since udev just uses
the library. That is actually the main reason we are transitioning over
to kmod.

You do that by putting the following in /etc/portage/package.use:

sys-apps/kmod -compat -tools

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Walter Dnes]

On Sat, Feb 25, 2012 at 08:28:23AM +0000, Duncan wrote

> That leaves those using a dev-manager other than udev in a current 
> installation who are depending on the current system set listing to bring 
> in module-init-tools.  I believe busybox has it's own modutils as well, 
> doesn't it, so that eliminates them.

  Would this require tweaking the virtual/dev-manager ebuild?  Taking a
quick glance at http://busybox.net/downloads/BusyBox.html it does have
lsmod/modprobe/rmmod, but not modinfo.  Are there any ebuilds or init
scripts that use modprobe or rmmod?  If so, the ebuild should at least
have an ewarn message telling mdev users to create the necessary
symlinks to modprobe/rmmod.  Maybe even attempt to create the symlinks
if they don't already exist.

  I'm not a programmer or developer, but I am running udev-less Gentoo
using busybox's mdev.  I've got a spare machine that I'm willing to use
as a guinea-pig for testing mdev under the proposed setup.

  How difficult would it be to set up an mdev-based profile, already?

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Duncan]

William Hubbs posted on Sat, 25 Feb 2012 11:25:55 -0600 as excerpted:

> On Sat, Feb 25, 2012 at 08:44:39AM +0000, Duncan wrote:
>> You are however correct that it'll be on most systems, at least with
>> udev-181, since udev won't build without kmod, now.  (I found that out
>> when the build broke on me due to missing kmod, as I've had udev
>> unmasked for awhile and got 181 before kmod was added as a dep.)
> 
> But, one thing about kmod is that you can turn off the command line
> portions of it completely on a monolythic system since udev just uses
> the library. That is actually the main reason we are transitioning over
> to kmod.
> 
> You do that by putting the following in /etc/portage/package.use:
> 
> sys-apps/kmod -compat -tools

Good point, and I'd done exactly that.

But current docs and @system assume modules, and on principles of least 
change for both packages and docs, I kept that assumption.

For advanced users with monolithic kernel systems, kmod as a udev dep and 
modutils removed from @system will at once be already better and worse 
than current state, better, since a package.use entry is way less drastic 
than a package.provided and an @system negating packages files entries, 
worse, since previously, no modutils package was necessary at all once 
the appropriate portage configs were setup, but now, kmod is required for 
udev, as an upstream choice made for us.  package.use can take care of 
the command line stuff, but the package is still a hard dep, since udev 
itself won't build without it.

Unless of course upstream udev provides a build-time option allowing udev 
to be built without module support, so it doesn't link kmod at all.  I've 
not actually investigated that, but I doubt they do.  It would sure be 
nice, tho, if they did.  Has a request been made, at least?  Gentoo could 
then expose that option as a USE flag in the routine fashion, which would 
make killing the kmod dep entirely possible, for those who do have 
monolithic kernels.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: rfc: virtual/modutils and module-init-tools

[Duncan]

Walter Dnes posted on Sat, 25 Feb 2012 15:04:22 -0500 as excerpted:

> On Sat, Feb 25, 2012 at 08:28:23AM +0000, Duncan wrote
> 
>> That leaves those using a dev-manager other than udev in a current
>> installation who are depending on the current system set listing to
>> bring in module-init-tools.  I believe busybox has it's own modutils as
>> well, doesn't it, so that eliminates them.
> 
>   Would this require tweaking the virtual/dev-manager ebuild?  Taking a
> quick glance at http://busybox.net/downloads/BusyBox.html it does have
> lsmod/modprobe/rmmod, but not modinfo.  Are there any ebuilds or init
> scripts that use modprobe or rmmod?  If so, the ebuild should at least
> have an ewarn message telling mdev users to create the necessary
> symlinks to modprobe/rmmod.  Maybe even attempt to create the symlinks
> if they don't already exist.

FWIW I don't have busybox installed either (negating @system entry in 
/etc/portage/profiles/packages, I use either init=/bin/bash on the kernel 
command line, or a second copy of the rootfs taken when the system was 
generally stable, as my emergency boot solution, no busybox necessary), 
so I'm not familiar with it at all.

But as I stated I've had module-init-tools in package.provided for quite 
some time, no noticed ill effects.  The only deps I see on it presently 
are sys-apps/rescan-scsi-bus (itself a dep of k3b, cd/dvd-burning app, 
this will obviously be replaced with a virtual/modutils dep) and
virtual/modutils itself.  I don't see any deps on virtual/modutils 
presently.  But of course I don't have all apps installed, either.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman