iBFT features for v2.6.36
in [Kernel]
|
Prev: usb gadget: don't save bind callback in struct usb_gadget_driver
Next: [PATCH 2/2] usb gadget: don't save bind callback in struct usb_configuration
From: H. Peter Anvin on 2 Aug 2010 14:30 On 08/02/2010 07:36 AM, Konrad Rzeszutek wrote: > What is iBFT? > The iBFT is an equivalent to the Boot Flag, except that its geared > towards iSCSI and hence requires much more information (such as > the IP of target, passwords, which device to login, etc). iBFT > is a data structure populated by the BIOS or the NIC to contain this > so that the OS can read it and login to the iSCSI and present > the boot device to the initrd for mounting / FS. I really don't see iBFT as equivalent to the boot flag at all. The boot flag returns the status of the previous boot attempt; iBFT contains information about where to find the current root. Unfortunately, we're increasingly seeing a proliferation of this kind of nonstandard ACPI tables, because it is difficult to add data to ACPI at runtime. gPXE creates an aBFT table for AoE and sBFT for SRP, and memdisk uses mBFT for MEMDISK at the moment. It would be good to have some kind of common structure framework for these. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Konrad Rzeszutek Wilk on 2 Aug 2010 16:00 On Mon, Aug 02, 2010 at 11:22:21AM -0700, H. Peter Anvin wrote: > On 08/02/2010 07:36 AM, Konrad Rzeszutek wrote: > > What is iBFT? > > The iBFT is an equivalent to the Boot Flag, except that its geared > > towards iSCSI and hence requires much more information (such as > > the IP of target, passwords, which device to login, etc). iBFT > > is a data structure populated by the BIOS or the NIC to contain this > > so that the OS can read it and login to the iSCSI and present > > the boot device to the initrd for mounting / FS. > > I really don't see iBFT as equivalent to the boot flag at all. The boot I think for somebody who might confuse iBFT with a bar of soap the "equivalant" will put them in the right frame of mind. And yes it is not equivalant at all, should have said something like 'remotely akin' :-) > flag returns the status of the previous boot attempt; iBFT contains > information about where to find the current root. > > Unfortunately, we're increasingly seeing a proliferation of this kind of > nonstandard ACPI tables, because it is difficult to add data to ACPI at Keep in mind that iBFT is now a standard (woot!) > runtime. gPXE creates an aBFT table for AoE and sBFT for SRP, and > memdisk uses mBFT for MEMDISK at the moment. Oh man, didn't know those existed at all. > > It would be good to have some kind of common structure framework for these. I need to grok those tables some more to figure out what they all do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 2 Aug 2010 16:30 On 08/02/2010 12:52 PM, Konrad Rzeszutek Wilk wrote: >> >> Unfortunately, we're increasingly seeing a proliferation of this kind of >> nonstandard ACPI tables, because it is difficult to add data to ACPI at > > Keep in mind that iBFT is now a standard (woot!) > Yes, but the discovery method is ad hoc, as opposed to the standard ACPI mechanisms. >> runtime. gPXE creates an aBFT table for AoE and sBFT for SRP, and >> memdisk uses mBFT for MEMDISK at the moment. > > Oh man, didn't know those existed at all. >> >> It would be good to have some kind of common structure framework for these. > > I need to grok those tables some more to figure out what they all do. More or less the same thing as iBFT, but for AoE, SRP, or in-memory disk. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Konrad Rzeszutek Wilk on 2 Aug 2010 21:20 On Monday 02 August 2010 16:26:59 H. Peter Anvin wrote: > On 08/02/2010 12:52 PM, Konrad Rzeszutek Wilk wrote: > >> Unfortunately, we're increasingly seeing a proliferation of this kind of > >> nonstandard ACPI tables, because it is difficult to add data to ACPI at > > > > Keep in mind that iBFT is now a standard (woot!) > > Yes, but the discovery method is ad hoc, as opposed to the standard ACPI > mechanisms. The set of patches that I am asking Linus to pull now can use the ACPI table to find the table or in the fallback case the old method of scanning the memory. However if the machine has UEFI it will only do ACPI table lookup. Can you point me what 'standard ACPI mechanism' is? Like sticking the code in the drivers/acpi ? And then having a generic driver to handle the [i,a,s,m]BFT tables and maybe some subordinate ones for specific pieces where the generic can't handle it? > >> It would be good to have some kind of common structure framework for > >> these. > > > > I need to grok those tables some more to figure out what they all do. > > More or less the same thing as iBFT, but for AoE, SRP, or in-memory disk. What is the tools state ? For iBFT, iscsi-initiator-utils scans the /sys/firmware directory to extract the relevant data and does its thing. Are there tools for AoE, SCSI RDMA Protocol (SRP), and in-memory disk? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 2 Aug 2010 22:30
On 08/02/2010 06:08 PM, Konrad Rzeszutek Wilk wrote: > > Can you point me what 'standard ACPI mechanism' is? Like sticking the code in > the drivers/acpi ? And then having a generic driver to handle the > [i,a,s,m]BFT tables and maybe some subordinate ones for specific pieces where > the generic can't handle it? > With the standard ACPI mechanism I meant RDSP -> {RSDT,XSDT} -> table. If it was easily possible to add SSDTs to this table structure then probably the best thing would have been to make them PnP devices. >>>> It would be good to have some kind of common structure framework for >>>> these. >>> >>> I need to grok those tables some more to figure out what they all do. >> >> More or less the same thing as iBFT, but for AoE, SRP, or in-memory disk. > > What is the tools state ? For iBFT, iscsi-initiator-utils scans > the /sys/firmware directory to extract the relevant data and does its thing. > Are there tools for AoE, SCSI RDMA Protocol (SRP), and in-memory disk? I don't know about AoE and SRP (Michael Brown <mcb30(a)ipxe.org> would know), but I have a tool which scans for mBFT directly out of /dev/mem, which is of course kind of ugly. It's shipped with the Syslinux distribution in the utils/ directory. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |