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 15:17:17 -0400 [thread overview]
Message-ID: <4AC5003D.5020304@natemccallum.com> (raw)
In-Reply-To: <20091001190733.GA27434@kroah.com>
On 10/01/2009 03:07 PM, Greg KH wrote:
> On Thu, Oct 01, 2009 at 02:56:55PM -0400, Nathaniel McCallum wrote:
>> On 10/01/2009 02:40 PM, Greg KH wrote:
>>> On Thu, Oct 01, 2009 at 02:35:40PM -0400, Nathaniel McCallum wrote:
>>>> 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).
>>>
>>> Did those modules have debugging symbols enabled? That seems like a
>>> large savings for just the module device tables.
>>
>> It does not appear so (none of the debug sections are present). But I
>> could be wrong.
>>
>> Stripping the modules on the penultimate Fedora 11 kernel results in the
>> same drop in size. I can't imagine why a release kernel would have
>> anything extra left in the modules (unless it is just by accident).
>
> Are you sure things still work after stripping? Stuff like systemtap
> and other tools?
Not at all. I have no idea what the ramifications are.
My point was merely that whatever is stripped out of the kernel should
be able (in theory) to be stripped from the modules. The only point of
difference should be the actual module symbols themselves which can in
stead be stored in ELF sections.
Nathaniel
next prev parent reply other threads:[~2009-10-01 19:17 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
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 [this message]
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=4AC5003D.5020304@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox