Hello Prarit, > -----Original Message----- > From: Prarit Bhargava [mailto:pra...@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. > > /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:pra...@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 <rajatj...@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