[ltp] ibm_acpi and modprobe.conf

[linux-thinkpad@linux-thinkpad.org]

FeRD,

Wow, long mail.  Unsure I can do it the honour of a full respone on
every point, but I'll try to respond to some:

> Careful there -- are you sure about the "ignores settings" thing being true? 
> If so, that would be weird, as all the other boot-loaded modules respect 
> modprobe.conf.

Well, you know... I'm not finding that so, but it may be me doing
something wrong.  I also --preload radeonfb into my initrd, as you'll
see on another thread on this list, and the mkinitrd manpage implies
this will respect options in modprobe.conf - but so far I can't get
it to.

> However, if my "multiple versions" hypothesis is correct, it 
> may explain the problem... version 0.8 of the ibm_acpi module didn't do much 
> of anything with "experimental=1",

Yes indeed - I really actually need to do some proper rebooting and
experimenting with both problems.  Lazy me, I'll try and do so in the
next few days.

> I don't load it at bootup, it's autodetected. In the same way I don't load 
> the ide, yenta, or serio drivers. Just hardware autodetection Doing The Right 
> Thing(tm), in my mind. *shrug* More black magic, but certainly black magic 
> with precedent. Like I said, there are plenty of hardware drivers I don't 
> load by hand. (Like... all of them.)

It's the black magic thing that gets me: I *should* be able to
understand this, but never been good at the low-level hardware
detection thing at bootup.  If anyone can push me in the right
direction as to how the need for ibm_acpi is recognised from hardware
and the module loaded at bootup with nothing in modprobe.conf, I'd
be grateful.

>> Maybe I
>> could rename the kernel one and reboot, yes.
>
>
> I'd be VERY interested in the results of that test,

Right. I should do that. Yes :)

> If you are indeed getting the old version loaded, the question comes back to 
> WHY. If I were to speculate, I'd guess that perhaps ibm_acpi.ko itself isn't 
> in the initrd, but perhaps a modules.dep _IS_ that the system is using for 
> boot-time module loading.

Oh, it's indeed not in the initrd - very easy to unpack and inspect
it with gzip.

> Going back to the deletion issue -- hey, I agree with you, I don't like it 
> either. But I also don't like having two versions of the module installed, 
> especially since there's NO justifiable reason for that. (Meaning, it's NEVER 
> the situation you WANT to arrive at.) It's not like you can EVER use both at 
> once. That's why the kernel doesn't even really seem to HAVE a strong and 
> universal concept of module "versioning". (I think that's part of the problem 
> here, and why it's so hard to do things like check "whch version" of a module 
> is loaded. Plenty of modules don't even DISPLAY a version via modinfo.) I 
> don't even like having two versions of a shared library installed unless I 
> have to, and there ARE situations where that's desirable/necessary. With 
> kernel modules, it's ALWAYS got to be one or the other, in reality, so I'm 
> especially reticent about the whole two-versions thing.

Yes - two sides to every story.  It seems though to me that there are
valid conceptual parts of unix where two copies of the same thing
exist, and a formal method is used to ensure which gets used: $PATH
and $LD_LIBRARY_PATH for instance.  In my naivety (not being a kernel
hacker) I assumed some similarly sensible scheme was being followed
here for kernel modules: that anything in

/lib/modules/`uname -r`/kernel/drivers/acpi (=the standard driver)

would be overridden by anything in

/lib/modules/`uname -r`/acpi (=a newer one I added)

which would make sense (to me!), and similarly for all.  It does
appear however that this scheme isn't actually formalised, even
though it seems to happen, at least after bootup.

> Here's how I look at the options here:
>
> 1. The "right solution" to this is probably to roll your own kernel RPM 
> including ibm_acpi version 0.11. That seems like overkill, and a nightmare to 
> have to maintain. But if you wanna be a purist, the Don Quixote Institute for 
> Purism recommends this solution vehemently and unwaveringly. :)

I used to be THAT purist - I now am vehemently RPM purist through
sheer exhaustion :)

> 3. In a section of your original message I cut out, you mentioned you're 
> rolling your own initrd for swsusp2. So am I, but automagically using 
> Matthias Hensler's <a href="http://mhensler.de/swsusp/">Fedora Core 3/4 
> Swsusp2 RPMs</a> and the corresponding mkinitrd.

Indeed, same here, as I just actually posted in another message,
coincidentally.  I've caused Mathias some real pain with fs
corruptions in suspend2 on the suspend2-users list, so thanks and
sorry Mathias, if you're reading :)

> and also to propose we ask that he start rolling 
> version 0.11 of ibm_acpi into his releases. That's likely  a quicker process 
> than getting the official releases up to date, and there is some precedent 
> there: Matthias' RPMs include the ntfs module, which isn't part of the FC4 
> official builds.

Ah, hmm, cough.  I hadn't noticed Mathias *did* include this.
Handy yes, but the thing that really attracts me to Mathias's kernels
(and why I tried to do this previously with *lots* of help from the
suspend2 people - see http://www.suspend2.net/fedora/ for the relic
of this) is that I think it's really important to stick to Fedora
kernels as far as possible.  We all know the history of "enhancements"
in other OS's.  I have to express some reticience here to the idea
that Mathias's kernels might start *replacing* Fedora modules with
newer ones on request.  Much better to add an RFE to Fedora's bugzilla
I think, if there aren't any proprietary issues (can't imagine there
could be) as would be the case with ntfs. This might be a bit off-topic
here and an issue for Mathias alone though.

So yes - I do use Mathias's mkinitrd-swsusp2 - just that I have to do
my own to --preload=radeonfb too, so that I can use the S3 power
drain reduction patch (see other threads).

I mustn't go on, but thanks also for you comments on ibm_acpi,
modinfo and the presence/absence of /sys info - I hadn't been looking
that closely.  I really need to just do some renaming, rebooting and
playing with modprobe.conf and initrd.  Which I will :)

Honey