On 02/09/2015 12:38 PM, Rajat Jain wrote: > 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. >
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: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 > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
