On 6/5/07, Doug Maxey <dwm@xxxxxxxxxxx> wrote:
If the case is LOM (Lan on Motherboard) then definitely bios will store the parameter, whereas in case of NIC, the NIC takes care of storing the iBFT into memory.
Using fwparam_ibft as a stand alone application to read the iBFT, and script around it while install & boot time, and using different scripting languages for different distros have issues of maintainability which i discussed in Message-ID: < 463F80C1.3020402@xxxxxxxxxxx> and proposed merging the applications as my solution 5 weeks back on this community. so i put the patches of merged fwparam_ibft.c and iscsistart.c for x86 architecture and in case of PPC i wanted someone to do that and give it to the maintainer as i don't have the hardware.
The init file of initrd has hard coded values for connection parameters still. mkinitrd is using the fwparam_ibft to get these parameter only. he isn't using this in the init script of initrd. And also having the "glue" code around fwpwram & iscsistart will be difficult to implement in Nash (at least i feel so).
On Tue, 05 Jun 2007 16:30:44 PDT, "Prasanna Mumbai" wrote:
> Hi all,
>
> Currently, Anaconda can install to an iSCSI LU but doesn't make use of the
> iBFT, if it's available. The iBFT (iSCSI Boot Firmware Table) is written to
ibft is also available (of sorts) on ppc64.
> memory by iSCSI bootable NICs.
The parameters are stashed by bios/ofw on the platform, not by the nic.
If the case is LOM (Lan on Motherboard) then definitely bios will store the parameter, whereas in case of NIC, the NIC takes care of storing the iBFT into memory.
> Recently patches were accepted that created
> the fwparam_ibft application, which would output the iBFT. The forthcoming
> patches to Open-iSCSI, mkinitrd and Anaconda will allow Anaconda to install
> to an iSCSI LU using the iBFT.
> "iscsistart" patch: added options to iscsistart, one for reading and
> displaying iBFT and other option will let you read the iBFT and establish a
> connection to the LU.
>
> "fwparam_ibft" patch: changed function main to fwparam_ibft & adds
> fwparam_ibft.c and fwpwaram_ibft.h to /usr directory and deletes the
> /util/fwparam directory. fwparam_ibft.c would get built as a part of
> iscsistart application so as to give the functionality for the options
> provided in the above patch.
>
> "anaconda" patch: Instead of calling fwparam_ibft and parsing the output it
> only needs to call iscsistart with the new "-b" option.
Why put the code in iscsistart? The fwparam_ibft can be built to
operate correctly on the the given platform with the patch in
Message-id: < 30121.1173910134@xxxxxxxxxxxxxxxx>
Subject: [RFC PATCHSET] add fwparam_ppc for open-iscsi
Using fwparam_ibft as a stand alone application to read the iBFT, and script around it while install & boot time, and using different scripting languages for different distros have issues of maintainability which i discussed in Message-ID: < 463F80C1.3020402@xxxxxxxxxxx> and proposed merging the applications as my solution 5 weeks back on this community. so i put the patches of merged fwparam_ibft.c and iscsistart.c for x86 architecture and in case of PPC i wanted someone to do that and give it to the maintainer as i don't have the hardware.
>
> "mkinitrd" patch: Instead of inserting hard coded connection parameters
> into the initrd, the initrd will simply call "iscsistart -b" which will
Already done with fwparam_ibft.
The init file of initrd has hard coded values for connection parameters still. mkinitrd is using the fwparam_ibft to get these parameter only. he isn't using this in the init script of initrd. And also having the "glue" code around fwpwram & iscsistart will be difficult to implement in Nash (at least i feel so).
++doug
