Re: The future of the isboot (iBFT / iSCSI boot) module

From: John Baldwin <>
Date: Mon, 14 Jun 2021 08:38:37 -0700
On 6/8/21 11:22 AM, John Nielsen wrote:
> [re-posted with minor edits from -scsi]
> Hi all-
> TL;DR—do we want to bring iSCSI boot support in to the base system and if so, what should that look like?
> I’ve been maintaining (badly, at least until recently) the net/isboot-kmod port which contains Daisuke Aoyama’s 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—FreeBSD’s loader can load and start the kernel, etc. What’s 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’s 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’t know if it pre-dates Danny Branniss’ 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’ve made a couple more improvements and a 0.2.15 release isn’t far off. See the project here if interested: .
> I’m 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. From 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, foot-shooting is easier with an out-of-tree module required to mount root
> 2) Bring it in base but keep it separate from sys/dev/iscsi.
> 	Pros: also very easy (I’ve done a proof of concept to support modules/isboot and “device isboot” in kernel), higher visibility, easily updated with the rest of the system (or even linked in to the kernel directly), 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’m not aware of? Any sponsorship volunteers?

I'd be a bit nervous about just going with 2) unless there's a person lined up
to do the work of 3).  The iscsi initiator and target already don't really share
a ton of code (and possibly duplicate some things as a result).

It's also probably going to be hard to get review for a 3rd iscsi initiator vs
something smaller that reuses sys/dev/iscsi.

John Baldwin
Received on Mon Jun 14 2021 - 15:38:37 UTC

Original text of this message