From: Prarit Bhargava <prarit@redhat.com>
To: Rajat Jain <rajatjain@juniper.net>
Cc: "grub-devel@gnu.org" <grub-devel@gnu.org>,
David Michael <fedora.dm0@gmail.com>,
Raghuraman Thirumalairajan <rthirumal@juniper.net>,
Andrei Borzenkov <arvidjaar@gmail.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
Sanjay Jain <sanjayj@juniper.net>,
Stu Grossman <grossman@juniper.net>
Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information
Date: Mon, 09 Feb 2015 11:28:34 -0500 [thread overview]
Message-ID: <54D8E032.4040206@redhat.com> (raw)
In-Reply-To: <DM2PR05MB975471230039CDE56338CBFB4270@DM2PR05MB975.namprd05.prod.outlook.com>
On 02/09/2015 10:27 AM, Rajat Jain wrote:
> Hello,
>
>>> 1) We have a board that boots Linux and this board itself can be plugged
>> into one of different chassis types. We need to pass different parameters to
>> the kernel based on the "CHASSIS_TYPE" information that is passed by the
>> bios in the DMI / SMBIOS tables.
>
> Actually, I had simplified the problem statement, to avoid complicating the discussion. Basically, we have enhanced the grub with a "devicetree" command that supplies a flattened device tree to the kernel (just like u-boot or others do in embedded world).
>
> http://www.denx.de/wiki/view/DULG/LinuxFDTBlob
>
> However, we need to pass different flattened device tree to the kernel based on different CHASSIS_TYPE. (because different chassis have different hardware components, slots etc that need to be handled differently).
>
>>>
>>
>> Whups ... somehow stripped all the cc's on my original reply.
>>
>> why isn't 1) already in the kernel itself?
>
> I hope my problem statement clarification above makes it clearer. However, I think the problem is more generic - essentially depending on the current machine type, we may have to do different things on different platforms, such as:
> * Loading different kernels / initrd / device tree etc.
> * Passing different kernel parameters for:
> - different root fs mount points (root=/dev/sda[a/b/c/d]......)
> - enabling disabling different kernel features / drivers / subsystem (pci=[nocrs/use_crs]...)
> - etc.
>
Well I understand the request for different kernels, but 1) implies that you're
adding additional kernel parameters based on the CHASSIS type? So I'm wondering
why you're not making some boot time decision based on the CHASSIS type instead
of a bootloader time decision.
/me is not against the patchset. I think the idea of booting different kernels
based on the HW sounds reasonable from a administration perspective.
P.
> Thanks,
>
> Rajat
>
>
>
>> -----Original Message-----
>> From: Prarit Bhargava [mailto:prarit@redhat.com]
>> Sent: Monday, February 09, 2015 4:44 AM
>> To: David Michael
>> Cc: grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov; Rajat Jain; Sanjay
>> Jain; Raghuraman Thirumalairajan; Stu Grossman
>> Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information
>>
>> On 02/08/2015 01:54 PM, David Michael wrote:
>>> The following are two use cases from Rajat Jain <rajatjain@juniper.net>:
>>>
>>> 1) We have a board that boots Linux and this board itself can be plugged
>> into one of different chassis types. We need to pass different parameters to
>> the kernel based on the "CHASSIS_TYPE" information that is passed by the
>> bios in the DMI / SMBIOS tables.
>>>
>>
>> Whups ... somehow stripped all the cc's on my original reply.
>>
>> why isn't 1) already in the kernel itself?
>>
>> P.
>
next prev parent reply other threads:[~2015-02-09 16:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-08 18:54 [PATCH v2] Add a module for retrieving SMBIOS information David Michael
2015-02-08 20:13 ` Prarit Bhargava
2015-02-09 12:43 ` Prarit Bhargava
2015-02-09 15:27 ` Rajat Jain
2015-02-09 16:28 ` Prarit Bhargava [this message]
2015-02-09 17:38 ` Rajat Jain
2015-02-09 17:43 ` Prarit Bhargava
2015-02-11 11:34 ` Andrei Borzenkov
2015-02-16 3:10 ` David Michael
2015-03-16 18:26 ` Rajat Jain
2015-03-18 3:04 ` David Michael
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=54D8E032.4040206@redhat.com \
--to=prarit@redhat.com \
--cc=arvidjaar@gmail.com \
--cc=fedora.dm0@gmail.com \
--cc=grossman@juniper.net \
--cc=grub-devel@gnu.org \
--cc=leif.lindholm@linaro.org \
--cc=rajatjain@juniper.net \
--cc=rthirumal@juniper.net \
--cc=sanjayj@juniper.net \
/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.