Hi Linus,
This pull requests consists of features to the iBFT driver. Specifically:
- support v1.03 of the spec. The spec in question is available at:
ftp://ftp.software.ibm.com/systems/support/bladecenter/iscsi_boot_firmware_table_v1.03.pdf
- separate the iBFT parsing from the SysFS interface.
These patches have been through a few rounds of review and have been in
linux-next for two months. James Bottomley is using this tree in his
branch for the BNX2 driver, so please merge these patches before his.
It's all at:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/ibft-2.6.git for-linus
Thanks,
Konrad
Konrad Rzeszutek Wilk (1):
ibft: For UEFI machines actually do scan ACPI for iBFT.
Mike Christie (2):
ibft: separate ibft parsing from sysfs interface
ibft: convert iscsi_ibft module to iscsi boot lib
Peter Jones (2):
ibft: Update iBFT handling for v1.03 of the spec.
ibft: Use IBFT_SIGN instead of open-coding the search string.
drivers/firmware/Kconfig | 9 +
drivers/firmware/Makefile | 1 +
drivers/firmware/iscsi_boot_sysfs.c | 481 +++++++++++++++++++++++
drivers/firmware/iscsi_ibft.c | 726 +++++++++++++----------------------
drivers/firmware/iscsi_ibft_find.c | 56 +++-
include/linux/iscsi_boot_sysfs.h | 123 ++++++
include/linux/iscsi_ibft.h | 12 +-
7 files changed, 924 insertions(+), 484 deletions(-)
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.
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
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.
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
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?
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 <[email protected]> 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.
> > 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 <[email protected]> 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.
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
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
On Tue, Aug 03, 2010 at 04:23:19PM -0700, H. Peter Anvin wrote:
> 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.
Linus,
Aside the discussion we are having with hpa about expanding the iBFT
or morphing it in another beast I realized that the LinuxCon is right
around the corner.
I presume you are not going to be sitting in the back of a corner trying
to merge all of the GIT pulls right before Aug 14/15th during the
LinuxCon. So does that mean that the effective merge window is right
before LinuxCon?
If that is the case, ping! Please pull this in before you pull in
James's tree as he has patches (and post-post merge patches) that depend
on this tree.
Or by any chance are you expanding the merge window by an extra week?
P.S.
Sorry to be so noise about this, but in the past I had missed two merge
windows and I want to make sure I don't miss this one.
On Wed, 2010-08-04 at 09:38 -0400, Konrad Rzeszutek Wilk wrote:
> If that is the case, ping! Please pull this in before you pull in
> James's tree as he has patches (and post-post merge patches) that
> depend
> on this tree.
Actually, there's no dependency ... the pull I sent is the
non-post-merge piece. It goes in independently of anyone else's tree.
Post merge will wait on the resolution of the iBFT pull
James
On Wed, Aug 4, 2010 at 6:38 AM, Konrad Rzeszutek Wilk
<[email protected]> wrote:
>
> I presume you are not going to be sitting in the back of a corner trying
> to merge all of the GIT pulls right before Aug 14/15th during the
> LinuxCon. So does that mean that the effective merge window is right
> before LinuxCon?
I'm skipping LinuxCon in Boston, to instead do LinuxCon in Brazil two
weeks later. So I will be at _a_ LinuxCon, but not the one you're
thinking (quite frankly, Brazil is just more interesting than Boston -
I've been to Boston before).
So I'm planning on sitting right at home, merging as usual. And
LinuxCon is at the very end of the merge window, so I'd expect that
any developer who sends me merge requests and is at LinuxCon will have
sent his request before it.
Linus