From nobody Tue Jun 08 14:08:01 2021 X-Original-To: freebsd-scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 675EF7CDBB3 for ; Tue, 8 Jun 2021 14:08:12 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [69.87.218.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.freebsdsolutions.net", Issuer "freebsdsolutions.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzsXC28yrz4tr2; Tue, 8 Jun 2021 14:08:10 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from smtpclient.apple (stealth.jnielsen.net [68.69.164.122]) (authenticated bits=0) by webmail5.jnielsen.net (8.15.2/8.15.2) with ESMTPSA id 158E81L5047514 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Jun 2021 08:08:04 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host stealth.jnielsen.net [68.69.164.122] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: John Nielsen List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: The future of the isboot (iBFT / iSCSI boot) module Date: Tue, 8 Jun 2021 08:08:01 -0600 Message-Id: References: Cc: trasz@freebsd.org In-Reply-To: To: freebsd-scsi@freebsd.org X-Mailer: iPhone Mail (18F72) X-Rspamd-Queue-Id: 4FzsXC28yrz4tr2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 69.87.218.172 as permitted sender) smtp.mailfrom=lists@jnielsen.net X-Spamd-Result: default: False [-2.72 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.87.218.172:from]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; SPAMHAUS_ZRD(0.00)[69.87.218.172:from:127.0.2.255]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[jnielsen.net]; NEURAL_HAM_SHORT(-0.92)[-0.918]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6364, ipnet:69.87.218.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-scsi] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > On Jun 5, 2021, at 2:42 PM, John Nielsen 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?