Re: Why are modules and modules.conf not versioned?
Steve Greenland wrote:
On 06-Nov-02, 15:54 (CST), Eric Richardson <eric.richardson@milagrosoft.com> wrote:
/etc/modules *
/etc/modules.conf *
* required and necessary as part of the operating kernel but no versions
to separate differences between versions of kernels since modules are an
essential part of the kernel.
But in general, you don't *need* version specific modules{.conf}. I've
had the same modulues.conf stuff for years. As I change hardware, I
change the configuration. I typically add stuff, not remove it, as
having "extras" doesn't cause a problem. And if I *do* need a version
specific option, I simply use the tools that the modules.conf 'language'
already provides.
Well, from a users perspective if you install or upgrade Woody and then
upgrade from 2.2 to 2.4 kernel which is optional you have problems with
a laptop as discussed earlier in this thread. 2.2 tulip_cb vs. 2.4
yenta_socket and tulip. From a users perspective you maintain modules
with the program modconf and then don't have to do anything else.
Modconf does not support the modules.conf language that I'm aware of and
the language is not a tool for userland so this is hard for a
non-programmer user.
Proposal to support different module files loaded for different kernel
versions.
I guess I don't see what this buys you that isn't already provided by
the if-then-elseif-else-endif construct and the include command. In
fact, it seems like a step backwards, because I know have to maintain
seperate files for each version, rather than being able to group things
the way they are actually used.
Making Debian easier for non-programmer user.
As for /etc/modules, again, I don't see that it is particularly version
dependent. If you have some kernel versions with more modules than
others, *and* they must be loaded at boot time (rather than 'on-demand'
through modules.conf), then simply add them to /etc/modules. If they
exist, they get loaded. If not, they don't. What's the problem?
Also when modconf and loading a module, the module goes into to
/etc/modules and the options such as "io=" or "dma=" go in the
modules.conf file. At least that how mine worked.
(As a side note, I guess I've always figured that if it's vital enough
to be in /etc/modules, why is it modularized in the first place? Yes,
for distribution kernels, sure, but once you start building you're own,
then why bother?)
If you have 2.4.18 using modules and 2.4.18custom1 that you built
yourself that builds in a portion of the modules then you will get error
messages because the modules won't load as they are built in. This does
not cause any problems but is aesthetically not so good.
That's about it. Hopefully this gives a clearer picture of what I'm
talking about.
Apparently not, as I still don't see what problem you have that isn't
solved by the existing tools.
I guess it is solved for someone that wants to learn the modules.conf
language and use it and ignore error messages while booting differnet
kernel that have different module requirements, but for a normal user it
can be a problem if they are try to upgrade or use more than one kernel
version or even build their own perhaps. Logically the module loading
goes with the current kernel version as part of the package so these
configuration files that control this should too. I think using modconf
is the normal user way manage modules and it should work for the kernel
that is active and no hand editing should be needed except for unusual
cases. modconf updates the files for you so no hand editing is needed.
In general, I like the simplicity of hand editing files in unix but
tools that do the editing for you are nice as well and can be less error
prone and are really best for the new user and non-power user or
programmer. Debian is the best most stable distro and if it is easier to
manage and install then more people can use it. That's what I would like
to see.
Eric
Reply to: