Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 214035 - x11-base/x11-drm should be providing /etc/modprobe.d/x11-drm
Summary: x11-base/x11-drm should be providing /etc/modprobe.d/x11-drm
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Bryan Stine (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 215626
  Show dependency tree
 
Reported: 2008-03-20 13:28 UTC by Jakub Moc (RETIRED)
Modified: 2008-09-24 15:23 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2008-03-20 13:28:14 UTC
/etc/modules.d is long deprecated. Please provide an equivalent /etc/modprobe.d file instead.
Comment 1 Bryan Stine (RETIRED) gentoo-dev 2008-09-12 03:43:16 UTC
I've decided that, with 20080710 and on, the functionality provided with the old modules.d file will be removed. In the future, the ebuild will check for the existence of CONFIG_DRM in the kernel (set to M or Y) and bail if it's there. This will cause it to refuse to install alongside kernel drm.

I have a few reasons for the decision, and hoepfully it won't affect many end users very much.

First of all, the new modprobe.conf(or .d) file does not naturally provide the mechanism to override installed modules in a separate path in the module directory. This means that if the in-kernel drm is installed as modules, their usual place in /lib/modules/KV/kernel/drivers... would be searched _before_ /lib/modules/KV/x11-drm. There's no facility provided by modprobe.conf to change that.

Second, although there is a very hackish way to achieve that (using shell commands in modprobe.conf/d), it's ugly and may not be foolproof. I had a test version in the tree, masked, but it's not a very good solution at all in my mind.

Finally, keeping two sets of DRM modules for one kernel can end up confusing the end user and could lead to all sorts of problems with symbol mismatches or the user expecting one thing to happen, while another does. As it is, I hate to remove flexibility, but there's no better way that I can see to do this with what we've got now.

That said, is there a preferred way to handle the snapshots already in the tree? If not, I can go about removing modules.d and adjusting the linux-info checks. It looks like we'll need to keep an older snapshot around for stable xf86-video-i810 and possibly others.
Comment 2 Bryan Stine (RETIRED) gentoo-dev 2008-09-13 01:17:41 UTC
All ebuilds have had the modules.d file removed and check for CONFIG_DRM=n.
Comment 3 Martin Mokrejš 2008-09-24 08:58:09 UTC
I have one objection. When I uninstall x11-drm it removes all kernel modules from all my /lib/modules/2.6.*/ subdirs, right? I don't like this solution. If multiple version (/slots?) would be possible then it is fine. Imagine, I often test several kernels and do not want to have only one drm driver installed for a single kernel.
Comment 4 Bryan Stine (RETIRED) gentoo-dev 2008-09-24 15:23:34 UTC
Actually those modules are kept due to the config protection system (usually used under /etc, which is also applied to /lib/modules). That means that upon unmerging the package, you'll see the following in the removal output...

--- cfgpro   obj /lib/modules/${KV}/x11-drm/drm.ko
--- cfgpro   dir /lib/modules/${KV}/x11-drm

This is necessary for properly handling multiple kernels, as you wish. We used to SLOT kernel module ebuilds but it was an ugly solution that led to a whole lot of slots for users with multiple kernels.

The one drawback of the current implementation is that if you remove x11-drm for a specific kernel, then merge a new one for that same kernel, portage will detect a collision between the old modules (which are still there) and the new ones being merged.