Re: [PATCH v2] Add a module for retrieving SMBIOS information

[Prarit Bhargava]

On 02/09/2015 12:38 PM, Rajat Jain wrote:
> Hello Prarit,
> 
>> -----Original Message-----
>> From: Prarit Bhargava [mailto:address@hidden
>> Sent: Monday, February 09, 2015 8:29 AM
>> To: Rajat Jain
>> Cc: David Michael; address@hidden; 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:address@hidden
>>>> Sent: Monday, February 09, 2015 4:44 AM
>>>> To: David Michael
>>>> Cc: address@hidden; 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 <address@hidden>:
>>>>>
>>>>> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>