This patch adds a /sysfs/firmware/ibft/table binary blob which exports

the iSCSI Boot Firmware Table (iBFT) structure. 
What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI

tools to extract from the machine NICs the iSCSI connection information

so that they can automagically mount the iSCSI share/target. Currently

the iSCSI information is hard-coded in the initrd.
The full details of the structure are located at:

ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_f...
Signed-off-by: Konrad Rzeszutek <konradr@linux.vnet.ibm.com>

Signed-off-by: Peter Jones <pjones@redhat.com>
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c

index d474cd6..11d700f 100644

--- a/arch/i386/kernel/setup.c

+++ b/arch/i386/kernel/setup.c

@@ -46,7 +46,7 @@ #include <linux/kexec.h>

 #include <linux/crash_dump.h>

 #include <linux/dmi.h>

 #include <linux/pfn.h>

-

+#include <linux/iscsi_ibft.h>

 #include <video/edid.h>
 #include <asm/apic.h>

@@ -150,6 +150,9 @@ static inline void copy_edd(void)

 }

 #endif
+void *ibft_phys;

+EXPORT_SYMBOL(ibft_phys);

+

 int __initdata user_defined_memmap = 0;
 /*

@@ -456,6 +459,15 @@ #ifdef CONFIG_KEXEC

 		reserve_bootmem(crashk_res.start,

 			crashk_res.end - crashk_res.start + 1);

 #endif

+

+	/* Scan for an iBFT (iSCSI Boot Firmware Table) */

+	{

+	unsigned int ibft_len = find_ibft();

+	if (ibft_len)

+		/* The specs says to scan for the table between 512k to 1MB.

+		   We reserve it n case it is in the e820 RAM section. */

+		reserve_bootmem(ibft_phys, PAGE_ALIGN(ibft_len));

+	}

 }
 /*

diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c

index af838f6..0d12775 100644

--- a/arch/x86_64/kernel/setup.c

+++ b/arch/x86_64/kernel/setup.c

@@ -44,6 +44,7 @@ #include <linux/cpufreq.h>

 #include <linux/dmi.h>

 #include <linux/dma-mapping.h>

 #include <linux/ctype.h>

+#include <linux/...
[ message continues ]

~~~~~~~
Put 'static ssize_t' on same line as function name, then put parameters
Need blank line here... except why is this function in the header
---

~Randy

Phaedrus says that Quality is about caring.

-

PowerPC exports this data via the OpenFirmware so it already shows in

the /sysfs entries. I was thinking to combine those sysfs entries under this

code, but that is something in the future.
In regards to all other platforms, I figured I would only make it supported

under platforms that have been tested. Is there anything that stops this from

working for example of IA64? Well no. The hardware that supports the iBFT is

either in the BIOS or in NICs - so the SGI or HP boxes _should_ work, however 
Q: "Why is this function in the header file"

If the find_ibft() was to be implemented in firmware/iscsi_ibft.c code the

firmware-driver couldn't be compiled as a module (or rather it could, but

when the vmlinuz was to be linked it would complain about missing symbol -

find_ibft). I was thinking to let the user give the choice whether they want

to load this firmware driver or have it built-in the kernel.
Q:"Why is it inline"
Fixed.
Randy,
Thank you for taking time to do such thoroughly review.

-

It should, presumably, depend on ACPI, rather than on X86...?
	-hpa
-

Actually no.  That /should/ be the correct answer, but none of the

hardware vendors actually provide the table via ACPI yet.  Also, if they

did, the support for /sys/firmware/acpi/tables/* would be sufficient

instead of having this code *at all*.
--

   Peter

-

Is there anything other than the discovery which is braindead about

iBFT?  If so, can the tables code be taught to look for this additional

table instead of having all its own mechanism?
(Sorry - I don't really know the ACPI code all that well.)
	-hpa

-

Well, the code for the the generic ACPI table sysfs functionality is

expecting to find the tables indexed in the RSDT.  This is essentially

what the iBFT spec's authors seem to have planned, but it's simply never

been implemented in the firmware.
AFAICS, it's technically feasible to remove the sysfs parts of this code

entirely, make the probe code build a fake ACPI table header, and then

add it explicitly if present at the end of acpi_system_sysfs_init() .
I don't know how the ACPI guys would feel about that.  Len, thoughts?
--

   Peter

-

Technically, ACPI knows only about devices that are soldered onto

the motherboard when the BIOS is flashed.

So ACPI wouldn't be able to help you find this table

when you put in an iSCSI card -- unless there were some arrangement

between the motherboard BIOS and the add-in card BIOS extension,

say, to have a dummy table that gets filled in or something.
Yes, OpenFirmware is extensible via add-in cards -- assuming

they support OpenFirmware -- so in theory they could do this right

even in the add-in case.
I wouldn't object to a platform hook to make the IBFT appear as just another

ACPI table available in /sys/firmware/acpi.  But that woudln't help

a system that has IBFT but doesn't have ACPI, so it doesn't

really solve the general problem.
For tables such as this,

ACPI is just the messenger anyway, we don't know anything about

the content of the table, just about the envelope around it

and how to find the envelope.  In this case, we don't even

know how to find the envelope, so ACPI doesn't add much

value to the IBFT.
In summary, I think IBFT should depend on iSCSI alone,

and not involve ACPI at all.
-Len
-

That's not how Linux development works.  You (we) have a huge

test lab around the world.  You practice "release early, release
But we strongly prefer not to have non-inline C code in header files,

[and the function does not need to be inline]

so find_ibft() needs a home in some source file/code that won't be built

as a loadable module, right?  And preferably not duplicated (i386 &

x86_64 versions; but we should see a merged x86/ arch soon, so it

sounds).  Would ia64 have its own version of find_ibft() or use this

same code?
I think that for now you can put find_ibft() in both setup.c files

and the merged x86/ arch tree can eliminate one of them.
On looking back at the patch, why aren't the ibft_phys and find_ibft()

parts of both setup.c patches surrounded by #ifdef CONFIG_ISCSI_IBFT &

#endif ?
---

~Randy

Phaedrus says that Quality is about caring.

-

i.e., what is this binary blob  (?)
I don't see a binary blob in this patch (as stated in the first

sentence).  I'd say that this patch adds methods for exporting

(or exposing) the ibft thru sysfs.
Is there some good reason that the iSCSI connection information

shouldn't be exposed in real sysfs attribute files instead of just
---

~Randy

Phaedrus says that Quality is about caring.

-

I used the wrong choice of words. The correct one is, as you say, to
My end goal is to export the iBFT data via individual sysfs attribute files. I

was thinking to do that in the next version of this code and build on top of

this patch. 
This way the existing exploiter (iscsi-initiator-utils) can use the parsing

code it already has to extract the data from the binary blob. Then in the

next version of the iscsi-initiator-utils (and for the kernel) I can post a

patch for supporting (and exporting in the kernel) individual sysfs attribute

files.

-

Please don't do that.  Binary files are for things that are

"pass-through" only, not anything that the kernel knows the structure

of, or cares about (like PCI config space, or firmware blobs for

devices.)
Just export the individual fields of this table as individual files

please.
thanks,
greg k-h

-

My goal was to do that in the next version of this patch. My first step was

to get the fundamental work reviewed (and hopefully accepted) and then build

on top of that.
The exploiter of this binary file (/sys/firmware/ibft/table) is the

iscsi-initiator-utils package and it has a library that parses the binary

blob data. The thought was to get this first working (ie,

iscsi-initiator-utils finds /sys/firmware/ibft/table, parses it and work) and

then work to have the iscsi-initiator-support individual sysfs entries.
Or do you think I should skip the fundamental step and work on the next

version of this patch that exports the data as individual data and post that
-

Just do the individual files, do not export binary structures through

sysfs as that is not allowed.
The individual files should be much easier to export than the binary

blog anyway :)
thanks,
greg k-h

-

Konrad Rzeszutek wrote:
maybe you want to use:
[...]
Roel

-