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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-25-2012, 05:01 AM
William Hubbs
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 05:20 AM
Mike Gilbert
 
Default rfc: virtual/modutils and module-init-tools

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.
 
Old 02-25-2012, 06:21 AM
"Robin H. Johnson"
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 07:28 AM
Duncan
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 07:44 AM
Duncan
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 03:34 PM
Mike Gilbert
 
Default rfc: virtual/modutils and module-init-tools

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.
 
Old 02-25-2012, 04:25 PM
William Hubbs
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 07:04 PM
"Walter Dnes"
 
Default rfc: virtual/modutils and module-init-tools

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>
 
Old 02-25-2012, 09:40 PM
Duncan
 
Default rfc: virtual/modutils and module-init-tools

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
 
Old 02-25-2012, 09:51 PM
Duncan
 
Default rfc: virtual/modutils and module-init-tools

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
 

Thread Tools




All times are GMT. The time now is 09:25 PM.

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