All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Cc: Raghuraman Thirumalairajan <rthirumal@juniper.net>,
	David Michael <fedora.dm0@gmail.com>,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	Rajat Jain <rajatjain@juniper.net>,
	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 12:43:32 -0500	[thread overview]
Message-ID: <54D8F1C4.8080702@redhat.com> (raw)
In-Reply-To: <DM2PR05MB975EEB8FCC484E548D11D9BB4270@DM2PR05MB975.namprd05.prod.outlook.com>



On 02/09/2015 12:38 PM, Rajat Jain wrote:
> Hello Prarit,
> 
>> -----Original Message-----
>> From: Prarit Bhargava [mailto:prarit@redhat.com]
>> Sent: Monday, February 09, 2015 8:29 AM
>> To: Rajat Jain
>> Cc: David Michael; grub-devel@gnu.org; Leif Lindholm; Andrei Borzenkov;
>> Sanjay Jain; Raghuraman Thirumalairajan; Stu Grossman
>> Subject: Re: [PATCH v2] Add a module for retrieving SMBIOS information
>>
>>
>>
>> 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.
> 
> Oh OK. I guess you are saying why not read the CHASSIS_TYPE in the kernel and take different paths depending on the value? The reason is because we may want to pass different kernel options that *exist today*. (E.g. different root file systems, or hw tuning parametes etc). Ideally once deployed, we neither want to change the bootloader, nor the kernel since that would require a recompilation which is best avoided. If something changes, it is much easier to change the grub config file which can be changed anytime, and thus we are requesting the *capability* to do it in a grub script or config file.
> 

Ah, I get it.  That certainly makes sense.  I just thought there was some
specific HW command that you always wanted executed on these boards.

>>
>> /me is not against the patchset.  I think the idea of booting different kernels
>> based on the HW sounds reasonable from a administration perspective.
> 
> Yup, understood. 
> 
> Also from admin perspective, I'm suggesting that we may need tune the kernel differently depending on the HW.

Thanks for the info :)

P.

> 
> Thanks,
> 
> Rajat
> 
>>
>> 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.
>>>
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


  reply	other threads:[~2015-02-09 17:43 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
2015-02-09 17:38       ` Rajat Jain
2015-02-09 17:43         ` Prarit Bhargava [this message]
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=54D8F1C4.8080702@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.