Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Jun 2021 08:08:01 -0600
From:      John Nielsen <lists@jnielsen.net>
To:        freebsd-scsi@freebsd.org
Cc:        trasz@freebsd.org
Subject:   Re: The future of the isboot (iBFT / iSCSI boot) module
Message-ID:  <EFFE4669-3D8C-4867-9A87-8B01C1531C21@jnielsen.net>
In-Reply-To: <ABEC13B4-D362-4B9F-9AE7-99AF11AA4C62@jnielsen.net>
References:  <ABEC13B4-D362-4B9F-9AE7-99AF11AA4C62@jnielsen.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 5, 2021, at 2:42 PM, John Nielsen <lists@jnielsen.net> wrote:
>=20
> TL;DR=E2=80=94do we want to bring iSCSI boot support in to the base system=
 and if so, what should that look like?
>=20
> I=E2=80=99ve been maintaining (badly, at least until recently) the net/isb=
oot-kmod port which contains Daisuke Aoyama=E2=80=99s isboot module. The ker=
nel module allows a system to be booted completely via iSCSI (no switching r=
oot, etc) from systems or NICs with native iSCSI BIOS support or via iPXE an=
d friends. The BIOS (or iPXE) acts as an initiator and connects to a previou=
sly-configured target volume. Boot (legacy or UEFI) continues normally from t=
here=E2=80=94FreeBSD=E2=80=99s loader can load and start the kernel, etc. Wh=
at=E2=80=99s missing in the base system is something to re-establish the iSC=
SI session between when the kernel starts execution and when it tries to mou=
nt the root filesystem.
>=20
> That=E2=80=99s where isboot comes in. Assuming the module is loaded at boo=
t, it will interpret the data structures in the mostly-standard iSCSI Boot Fi=
rmware Table (iBFT) and use that information to identify the correct NIC, br=
ing it up, assign an IP address and gateway (if provided), and establish an i=
SCSI session with the target. Once that is done the volume is presented as a=
 SCSI device using the CAM subsystem and boot proceeds normally.
>=20
> 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 do=
n=E2=80=99t know if it pre-dates Danny Branniss=E2=80=99 iscsi_initiator wor=
k in base but it definitely pre-dates the iscsid/iscsictl and ctld in base n=
ow. Upstream development on isboot has stopped from what I can tell and the p=
ort was broken for quite some time. I created a GitHub repo for the project a=
nd recently (with help from several others) I updated the port to 0.2.14, wh=
ich should work with FreeBSD 1[1234]. I=E2=80=99ve made a couple more improv=
ements and a 0.2.15 release isn=E2=80=99t far off. See the project here if i=
nterested: https://github.com/jnielsendotnet/isboot .
>=20
> I=E2=80=99m happy to maintain the port out of tree for the foreseeable fut=
ure but I think ideally this functionality should be brought in to the base s=
ystem. =46rom what I can tell the port has its own complete iSCSI initiator i=
mplementation, and does not use what is now in sys/dev/iscsi. That should pr=
obably change (and is a longer-term goal of mine, though I will likely need h=
elp), but for now what approach makes the most sense?
>=20
> 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, d=
uplicate 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 m=
odules/isboot and =E2=80=9Cdevice isboot=E2=80=9D in kernel), higher visibil=
ity, allows module to be added directly to kernel, some defense against bit r=
ot
>    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 c=
ontrol isboot functionality via loader tunable. Makes it more of a first cla=
ss citizen.
>    Cons: more effort again, probably requires broader ownership/buy-in.
>=20
> What does the list think? Any objections or considerations I=E2=80=99m not=
 aware of? Any sponsorship volunteers?

Is there another list where this would reach the right audience?





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EFFE4669-3D8C-4867-9A87-8B01C1531C21>