linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Cameron, Steve" <Steve.Cameron@hp.com>
To: <Paul.Clements@steeleye.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: How to identify contents of /lib/modules/*
Date: Wed, 16 Apr 2003 13:57:15 -0500	[thread overview]
Message-ID: <45B36A38D959B44CB032DA427A6E1064045133AC@cceexc18.americas.cpqcorp.net> (raw)


Paul.Clements@steeleye.com wrote:

> The truth is, the kernel rpms for this distro are not designed to be 
> installed side by side, they really ought to be upgraded (meaning the 
> old stuff gets removed, so there's no ambiguity). Do you actually 
> have customers that are installing multiple kernels and moving /lib/modules 
> dirs around? (I know we do this in our labs, and you may too, but I 
> can't imagine too many customers doing this...)

Yes, the RPMs in question overwrite the currently used kernel.... 
(then of course, the user is rather amazed and disgusted at the 
nerve of this RPM.   The next time he has such an RPM to install 
he remembers this event, and saves off his old kernel and 
/lib/modules directory before the RPM can destroy it.)

> > Also note, I can't just figure out which is the _running_ kernel  [...]
? Hmm... I'm not sure how feasible that's going to be... 

The problem case here is this one:

1) You have a brand new machine, with a brand new disk controller.
You install the OS, use a driver diskette for the brand new
disk controller.  The driver diskette is made for the default
kernel installed by the base media.  

2) You install a new errata kernel (because let's suppose the one on the CD
has known security problems, or something.)  However, you cannot 
reboot yet because the new errata kernel does not contain a driver which 
understands your new controller.

3) Install RPM driver for the new controller.  The RPM cannot rely on 
the running kernel, because you don't care about the running kernel,
you care about the errata kernel that you just installed, but which is
not yet running.

So feasible or no, we must try.  (Anyway, I think I have something
that will work, it's just kinda ugly, is all, and I was hoping
there was a beter way.)

> Is there any chance that SuSE (oops, let the cat out of the bag ;) 

I never said SuSE.  (Excellent guess though. :-)

> would accept your driver(s) into their distribution, or

Yes, that's no problem.  But it's always too late.
There will always be the case that we must support old
kernels that were deployed before the hardware that we're
trying to support.  And by "support" I also mean that
some level of testing has occurred, so this isn't possible.

Thanks for your thoughts on the matter.

-- steve

             reply	other threads:[~2003-04-16 18:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-16 18:57 Cameron, Steve [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-04-17 20:02 How to identify contents of /lib/modules/* Perez-Gonzalez, Inaky
2003-04-16 15:58 Cameron, Steve
2003-04-16 16:01 ` Alan Cox
2003-04-16 20:54   ` Henning P. Schmiedehausen
2003-04-16  2:00 Stephen Cameron
2003-04-16 14:21 ` Alan Cox
2003-04-16 16:06   ` Dominik Kubla
2003-04-17 18:08   ` Kristofer T. Karas
2003-04-16 15:18 ` Arjan van de Ven
2003-04-16 17:08 ` Jeremy Jackson
2003-04-16 17:20 ` Paul Clements

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45B36A38D959B44CB032DA427A6E1064045133AC@cceexc18.americas.cpqcorp.net \
    --to=steve.cameron@hp.com \
    --cc=Paul.Clements@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).