From: eric ernst <eric.ernst@linux.intel.com>
To: Randy Dunlap <rdunlap@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: jwboyer@fedoraproject.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/1] Add kernel parameter for kernel version
Date: Thu, 05 Jun 2014 15:56:40 -0700 [thread overview]
Message-ID: <5390F5A8.2010202@linux.intel.com> (raw)
In-Reply-To: <5390EF50.3010100@infradead.org>
On 14-06-05 03:29 PM, Randy Dunlap wrote:
> On 06/05/2014 03:15 PM, eric ernst wrote:
>> On 14-06-05 03:16 PM, Andrew Morton wrote:
>>> On Thu, 5 Jun 2014 15:09:17 -0700 eric.ernst@linux.intel.com wrote:
>>>
>>>> Create a kernel cmdline parameter, "version_addendum", which can be
>>>> used to add text to the kernel version that is reported from
>>>> /proc/version.
>>> why?
>> We have a need to keep a single product binary (kernel) across multiple android devices. A subset of these platforms are looking for extra versioning information appended to it, accessible via /proc/version. Rather than build multiple otherwise identical kernels with only this extended versioning as differentiation, we are looking to make this a command line parameter. Understandable if there isn't enough value-add for the community in this patch, but I figured I'd give the patch a shot, as we need this functionality locally. Thanks.
> Please use a newline character every 70-72 characters instead of assuming
> that all email programs will break that extra long line up into a readable
> format. (mine does not.)
Ack - sorry Randy - it was a quick cp / paste from earlier in the thread.
>
> What software needs to know the version info? how early does it run?
> Could it get the version info from 'uname -r' instead of from /proc/version?
>
> thanks,
This'll end up being used by a third party customer for tracking
particular devices, so I'm sure "much, much later" in user space. While
I'm sure they could use uname instead, the specific request was for
/proc/version.
The more I look into this patch, the more I think this is a pretty
specific use case that probably doesn't have a lot of community
value-add outside of our scenario. Thanks for the feedback.
next prev parent reply other threads:[~2014-06-05 22:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-27 19:40 [PATCH 1/1] Add kernel parameter for kernel version eric.ernst
2014-05-27 19:48 ` Josh Boyer
2014-05-27 20:06 ` Randy Dunlap
2014-06-02 18:41 ` eric ernst
2014-06-05 22:09 ` [PATCH v1 " eric.ernst
2014-06-05 22:16 ` Andrew Morton
2014-06-05 22:15 ` eric ernst
2014-06-05 22:29 ` Randy Dunlap
2014-06-05 22:56 ` eric ernst [this message]
2014-06-05 23:06 ` Richard Weinberger
2014-06-05 22:30 ` David Rientjes
2014-06-05 22:17 ` Randy Dunlap
2014-06-05 22:16 ` eric ernst
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=5390F5A8.2010202@linux.intel.com \
--to=eric.ernst@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.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.