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

[Rajat Jain]

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.

> 
> /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,

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.
> >