[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SOLVED] Re: inserting kernel modules on startup

On 24/07/14 04:48 PM, Michael Biebl wrote:
Am 24.07.2014 21:45, schrieb Gary Dale:
On 24/07/14 03:05 PM, Sven Joachim wrote:
On 2014-07-24 20:42 +0200, Gary Dale wrote:

I think you missed the point. The blacklist was in fglrx.conf where it
makes sense to not load the radeon module if I'm loading the fglrx
proprietary one. Again, this was necessary back when I was playing
around with the fglrx driver. I would have expected the system to only
parse the .conf files of modules it was loading.
Files under /etc/modprobe.d do not necessarily "belong" to any modules,
so this is not possible.  Any file there whose name ends in ".conf" will
be parsed.

Sorry but that doesn't make much sense to me. The files I have in
/etc/modprobe.d all look like they belong to kernel modules. Moreover,
the directory is related to modules.
It is like Sven says.
When you run modprobe, it will parse /etc/modprobe.conf and all files in
/etc/modprobe.d/ ending with .conf
It doesn't really matter how they are named.

So you could have named fglrx.conf foo.conf, that wouldn't have made a

So, after dropping the blacklist, you can also drop "radeon" from
/etc/modules. As already mentioned it will be autoloaded by udev.


I'm not disputing that it happens. I'm just looking for a reasonable explanation for what appears to be an unreasonable behaviour. Shouldn't the .confs be checked just once to build an internal representation of the modules rules, so that if fglrx is needed, it would block radeon and vice-versa?

As it stands, instead of the .conf files telling you how to configure the system for that module, you have to look at all the .confs to figure out what will happen. This kind of defeats the purpose of breaking the configuration into separate files for each module.

I grant that doing it differently is probably a bit more complex to program, but it would make life easier for system administrators. Why should someone have to look at the configuration for a module that isn't being used to debug a problem with a module that is?

In keeping with the configuration method of systemd, why shouldn't the computer do the sorting out?

Reply to: