On Tue, 2010-04-13 at 14:57 -0500, Mike Christie wrote: > On 04/12/2010 01:38 PM, Christopher Barry wrote: > > On Mon, 2010-04-12 at 13:06 -0500, micha...@cs.wisc.edu wrote: > >> From: Mike Christie<micha...@cs.wisc.edu> > >> > >> Not all iscsi drivers support ibft. For drivers like be2iscsi > >> that do not but are bootable through a vendor firmware specific > >> format/process this patch moves the sysfs interface from the ibft code > >> to a lib module. This then allows userspace tools to search for iscsi boot > >> info in a common place and in a common format. > >> > >> ibft iscsi boot info is exported in the same place as it was > >> before: /sys/firmware/ibft. > >> > >> vendor/fw boot info gets export in /sys/firmware/iscsi_bootX, where X is > >> the > >> scsi host number of the HBA. Underneath these parent dirs, the > >> target, ethernet, and initiator dirs are the same as they were before. > >> ... > > ===8<---- snip > >> +#endif > >> -- > >> 1.6.6.1 > >> > > > > Mike, > > To be clear, this patch will put ibft data into /var/firmware/ibft only > > Not, /var. You meant /sys right (I am not moving it to var. It is > staying in sys).
Yes - I meant /sys, sorry for typo. > > > for those devices that actually have it, but not create a tree for say > > NICs that do not currently support it? Wondering if this is a universal > > It does not change ibft behavior in any way. If a device supports ibft > and it is setup correctly when you load iscsi_ibft it gets exported in > the exact same place, with the exact files and the files have the same > format. > > The patches: > 1. separate the interface from the ibft parsing, so we could add a > different interface on like bsg if you wanted. > 2. allow drivers that do not support ibft, but support iscsi boot using > some vendor specific process, to be able to export their iscsi boot info > in the same format. These drivers just use a different root dir. Instead > of /sys/firmware/ibft, they use /sys/firmware/iscsi_bootX where X is the > host number of the iscsi HBA that was booted from. > > > > gizmo that will always populate the tree that I can rely on from > > userspace during boot. > > With these patches, and patches that are being worked on by vendors like > ServerEngines that do not support ibft and use some vendor specific > process, if you just load the iscsi driver, like be2iscsi or qla4xxx, > then they will load the iscsi_boot_sysfs module in the other patch sent > in this patchset, and /sys/firmware/iscsi_bootX will all get populated > with the boot info automagically for you. > > The iscsi tools (iscsistart and iscsiadm) will then parse and use this > data like it was ibft data and boot from disks or create records or > whatever. I am attaching the iscsi tools patches here. I am still > working with the be2iscsi guys to test it out. > > So with the patches > > iscsistart -b > > will look for ibft data. If not found then it would look for vendor > specific boot info. If found it would create a session using that > drivers's offload engine. > Thanks much for clarification, and all of your hard work. > > > > Thanks, > > -C > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
