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: Konrad Rzeszutek Wilk on 3 Aug 2010 09:10 > > 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. Ok. Let me talk to Michael Brown about this and see what the interests are. This "unification" work would be post v2.6.36 thought. -- 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: Peter Jones on 3 Aug 2010 10:40 On 08/02/2010 10:29 PM, H. Peter Anvin wrote: > 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. The current iBFT specification and the current code (this push) includes the ability to specify the location of the iBFT table using the standard ACPI table mechanism, which is required on UEFI machines supporting iBFT, and which I would encourage non-UEFI machines to also use where possible. Obviously some systems, especially BIOS-based machines doing iSCSI boot on expansion cards, have difficulty with this, so we're not planning on de-supporting the old memory scanning method. -- Peter Obviously, a major malfunction has occurred. -- Steve Nesbitt, voice of Mission Control, January 28, 1986 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- 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 3 Aug 2010 19:30
On 08/03/2010 07:35 AM, Peter Jones wrote: > > The current iBFT specification and the current code (this push) includes the > ability to specify the location of the iBFT table using the standard ACPI table > mechanism, which is required on UEFI machines supporting iBFT, and which I > would encourage non-UEFI machines to also use where possible. Obviously some > systems, especially BIOS-based machines doing iSCSI boot on expansion cards, > have difficulty with this, so we're not planning on de-supporting the old > memory scanning method. > Not just expansion cards, but also post-INT19 software solutions. -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/ |