From: Bill Davidsen <davidsen@tmr.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Matt Domsch <Matt_Domsch@Dell.com>,
Rusty Russell <rusty@rustcorp.com.au>, Greg KH <greg@kroah.com>,
Christoph Hellwig <hch@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2.6.11-rc2] modules: add version and srcversion to sysfs
Date: Thu, 27 Jan 2005 12:41:56 -0500 [thread overview]
Message-ID: <41F927E4.7070607@tmr.com> (raw)
In-Reply-To: <1106757530.13004.220.camel@winden.suse.de>
Andreas Gruenbacher wrote:
> On Wed, 2005-01-26 at 15:09, Matt Domsch wrote:
>
>>On Wed, Jan 26, 2005 at 10:22:29AM +0100, Andreas Gruenbacher wrote:
>>
>>>On Wednesday 26 January 2005 07:05, Matt Domsch wrote:
>>>
>>>>Module: Add module version and srcversion to the sysfs tree
>>>
>>>why do you need this?
>>
>>a) Tools like DKMS, which deal with changing out individual kernel
>>modules without replacing the whole kernel, can behave smarter if they
>>can tell the version of a given module.
>
>
> They can look at the modules in /lib/modules/$(uname -r).
I think he means he wants to know what's in memory, not on the disk.
[ snip ]
>
>>c) as the unbind-driver-from-device work takes shape, it will be
>>possible to rebind a driver that's built-in (no .ko to modinfo for the
>>version) to a newly loaded module. sysfs will have the
>>currently-built-in version info, for comparison.
>>
>>d) tech support scripts can then easily grab the version info for
>>what's running presently - a question I get often.
>
>
> That's something you can do entirely in userspace by looking at the *.ko
> files.
How do you find which *.ko file was used to load the module in memory? I
think you are talking about two things here.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
next prev parent reply other threads:[~2005-01-27 17:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-19 17:13 [PATCH] drop some attibutes from the FC transport class Christoph Hellwig
2005-01-19 17:21 ` Greg KH
2005-01-19 18:38 ` Brian King
2005-01-19 18:45 ` Greg KH
2005-01-19 22:59 ` Brian King
2005-01-19 21:39 ` Mike Anderson
2005-01-19 22:40 ` Greg KH
2005-01-19 23:03 ` Brian King
2005-01-19 23:03 ` Christoph Hellwig
2005-01-19 23:08 ` Greg KH
2005-01-19 23:15 ` Matt Domsch
2005-01-19 23:42 ` Greg KH
2005-01-20 5:12 ` Matt Domsch
2005-01-20 14:41 ` Greg KH
2005-01-26 6:05 ` [PATCH 2.6.11-rc2] modules: add version and srcversion to sysfs Matt Domsch
2005-01-26 9:22 ` Andreas Gruenbacher
2005-01-26 14:09 ` Matt Domsch
2005-01-26 16:38 ` Andreas Gruenbacher
2005-01-27 17:03 ` Matt Domsch
2005-01-27 17:41 ` Bill Davidsen [this message]
2005-01-26 14:32 ` Paulo Marques
2005-01-27 2:10 ` Rusty Russell
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=41F927E4.7070607@tmr.com \
--to=davidsen@tmr.com \
--cc=Matt_Domsch@Dell.com \
--cc=agruen@suse.de \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.