From: Nathaniel McCallum <nathaniel@natemccallum.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Exposing device ids and driver names
Date: Thu, 01 Oct 2009 14:35:40 -0400 [thread overview]
Message-ID: <4AC4F67C.7010500@natemccallum.com> (raw)
In-Reply-To: <20091001180531.GA3199@kroah.com>
On 10/01/2009 02:05 PM, Greg KH wrote:
> On Thu, Oct 01, 2009 at 01:01:50PM -0400, Nathaniel McCallum wrote:
>> On 10/01/2009 12:42 PM, Greg KH wrote:
>>> Why not just use the baseline kernel as a model for this. Do a 'make
>>> allmodconfig' and then extract the data and publish it that way. No
>>> kernel changes are needed, and then any distro can be easily matched up
>>> by this based on what they are using. That will save you time in
>>> downloading zillions of distro releases, and provide a nice easy way to
>>> show what the kernel.org releases support.
>>
>> Unfortunately, I would not be able to track changes to the kernel in
>> this model. Since this is one of my explicit goals (to make sure that
>> distro kernel changes get upstream), I think a non-invasive kernel
>> modification would be worth the effort.
>
> But this was an invasive modification, it added space to the kernel
> images for no real benifit other than for your tracking tools. That's
> not going to fly unless you can find another good use for the change.
Which is why I asked for advice for better options. I would prefer a
non-invasive modification. I am hoping that someone more familiar with
the layer would provide such a suggestion.
One potential benefit for moving module info to ELF sections would be
the ability to strip kernel modules. As a test, I did this on a recent
Fedora rawhide kernel I had lying around. Stripping the modules results
in a 43% decrease in size (82M to 47M).
But I still would prefer a non-invasive solution.
Nathaniel
next prev parent reply other threads:[~2009-10-01 18:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 16:40 Exposing device ids and driver names Nathaniel McCallum
2009-10-01 16:42 ` Greg KH
2009-10-01 17:01 ` Nathaniel McCallum
2009-10-01 18:05 ` Greg KH
2009-10-01 18:35 ` Nathaniel McCallum [this message]
2009-10-01 18:40 ` Greg KH
2009-10-01 18:56 ` Nathaniel McCallum
2009-10-01 19:07 ` Greg KH
2009-10-01 19:17 ` Nathaniel McCallum
2009-10-01 21:36 ` Nathaniel McCallum
2009-10-01 17:47 ` Stefan Richter
2009-10-01 18:02 ` Nathaniel McCallum
2009-10-01 18:23 ` Stefan Richter
2009-10-01 18:28 ` Nathaniel McCallum
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=4AC4F67C.7010500@natemccallum.com \
--to=nathaniel@natemccallum.com \
--cc=greg@kroah.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 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.