Date: Sat, 5 Jun 2021 14:41:47 -0600 From: John Nielsen <lists@jnielsen.net> To: freebsd-scsi@freebsd.org Cc: "trasz@freebsd.org" <trasz@FreeBSD.org> Subject: The future of the isboot (iBFT / iSCSI boot) module Message-ID: <ABEC13B4-D362-4B9F-9AE7-99AF11AA4C62@jnielsen.net>
next in thread | raw e-mail | index | archive | help
Hi all- TL;DR=E2=80=94do we want to bring iSCSI boot support in to the base = system and if so, how? I=E2=80=99ve been maintaining (badly, at least until recently) the = net/isboot-kmod port which contains Daisuke Aoyama=E2=80=99s isboot = module. The kernel module allows a system to be booted completely via = iSCSI (no switching root, etc) from systems or NICs with native iSCSI = BIOS support or via iPXE and friends. The BIOS (or iPXE) acts as an = initiator and connects to a previously-configured target volume. Boot = (legacy or UEFI) continues normally from there=E2=80=94FreeBSD=E2=80=99s = loader can load and start the kernel, etc. What=E2=80=99s missing in the = base system is something to re-establish the iSCSI session between when = the kernel starts execution and when it tries to mount the root = filesystem. That=E2=80=99s where isboot comes in. Assuming the module is loaded at = boot, it will interpret the data structures in the mostly-standard iSCSI = Boot Firmware Table (iBFT) and use that information to identify the = correct NIC, bring it up, assign an IP address and gateway (if = provided), and establish an iSCSI session with the target. Once that is = done the volume is presented as a SCSI device using the CAM subsystem = and boot proceeds normally. The module has been around for some time (I want to say since FreeBSD = 7). I believe it was developed in tandem or for use with the net/istgt = port. I don=E2=80=99t know if it pre-dates Danny Branniss=E2=80=99 = iscsi_initiator work in base but it definitely pre-dates the = iscsid/iscsictl and ctld in base now. Upstream development on isboot has = stopped from what I can tell and the port was broken for quite some = time. I created a GitHub repo for the project and recently (with help = from several others) I updated the port to 0.2.14, which should work = with FreeBSD 1[1234]. I=E2=80=99ve made a couple more improvements and a = 0.2.15 release isn=E2=80=99t far off. See the project here if = interested: https://github.com/jnielsendotnet/isboot . I=E2=80=99m happy to maintain the port out of tree for the foreseeable = future but I think ideally this functionality should be brought in to = the base system. =46rom what I can tell the port has its own complete = iSCSI initiator implementation, and does not use what is now in = sys/dev/iscsi. That should probably change (and is a longer-term goal of = mine, though I will likely need help), but for now what approach makes = the most sense? 1) Leave it out of tree as an independent port. Pros: easy in the short term (nothing more to do) Cons: less visible to potential users, likely to suffer from bit = rot, duplicate initiator code 2) Bring it in base but keep it separate from sys/dev/iscsi. Pros: also very easy (I=E2=80=99ve done a proof of concept to = support modules/isboot and =E2=80=9Cdevice isboot=E2=80=9D in kernel), = higher visibility, allows module to be added directly to kernel, some = defense against bit rot Cons: duplicate initiator code 3) Bring it in base, but make it depend on the sys/dev/iscsi code. Pros: most of the above, no duplicate initiator code Cons: more effort, slightly out of my depth 4) Bring it in base and merge it with sys/dev/iscsi. Pros: just one module to configure / load / worry about. Could = easily control isboot functionality via loader tunable. Makes it more of = a first class citizen. Cons: more effort again, probably requires broader = ownership/buy-in. What does the list think? Any objections or considerations I=E2=80=99m = not aware of? Any sponsorship volunteers? Thanks, JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ABEC13B4-D362-4B9F-9AE7-99AF11AA4C62>