Prasanna Mumbai wrote:
Message-ID: <463F80C1.3020402@xxxxxxxxxxx> and proposed merging the
applications as my solution 5 weeks back on this community.
I'll assume you mean the open-iscsi list, not anaconda-devel-list.
It would be really nice if people talked to us what the best usage model
for us is before asking us to implement things like this, but alas, the
world doesn't seem to work that way.
Anyway, all the patches I've seen still open up /dev/mem and do really
terrible things that simply aren't acceptable. So we need to fix that,
as a start.
That being said, I really don't see how the anaconda patch you mailed is
in any way adequate. It doesn't address bootloader installation at all,
and that's the absolute biggest advantage iBFT can provide to us (at
least that's my suspicion, maybe I'm wrong and it just can't do that).
But while I've got a bunch of experts on iSCSI and related firmware
issues reading emails from me, I've got a couple of questions I haven't
been able to find answers to. So here goes nothing:
1) if you have an x86 box with more than iSCSI-capable NIC, from
different vendors, and they're both set to bootable in the BIOS, does
that mean you have more than one "control structure" in the iBFT? The
lack of descriptive text in section 1.4.1 of the spec makes this
somewhat unclear.
2) if you've got an iSCSI-aware NIC as your first boot device in BIOS,
is that device 0x80? (If not, I'd argue your firmware is totally broken)
3) if it is 0x80, does it show up in EDD ? (Again, if not, I'd say it's
broken)
4) What do the VLAN and DHCP fields of the NIC structure specify?
5) What does the "MAC Address" field specify? I only ask because it
seems like specifying which pci function we're talking about seems like
it should really be enough...
6) pci bus/device/function? No support for multiple domains at all? So
on a 2-socket Opteron machine with an nVidia chipset I'm just screwed?
7) what's the story with all the one bit "firmware boot selected flag"
fields? The only one that has any defined meaning is the one in the
"target structure", and its meaning is not the most clear ever. If this
control structure says we're in multi-target mode, what am I supposed to
/do/ after connecting to more than one target? There's no concept of
mount points, and no language to determine which of the various targets
is the one booting off of. Please don't tell me that target1 is "D:".
Is there a "next" version of this spec in the works? If so, what's the
feedback process? How can we become involved?
--
Peter
