ctlstat is for ctld, which is iSCSI, so put it in the right package.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 64063 Build 60947: arc lint + arc unit
Event Timeline
This is not specific to ctld, instead it is for the ctl(4) drivers in the kernel which now include NVMeoF support, not just iSCSI. There is also a local SCSI target frontend for ctl(4) that isn't iSCSI. As for ctld, while it only supports iSCSI and physical target ports (think Fibre Channel), I have WIP patches to add NVMeoF support to it. However, both ctlstat and ctladm already work with the CTL target created by nvmfd(8) today. I'm not sure what package ctlstat/ctladm/ctld belong in, but it really isn't iscsi. camcontrol is in runtime which is too generic for these. camdd(8) is also not assigned a package. Maybe a "cam" package makes sense for ctl* and camdd (but apparently not camcontrol)? Or maybe a ctl package for ctl*?
(On a related note, why is nvmecontrol in an nvme-tools package rather than just "nvme"? The use of the "-tools" suffix appears to be arbitrary and inconsistent in package names.)
i am not sure how specific we want to be here. currently the FreeBSD-iscsi package includes this:
FreeBSD-iscsi-15.snap20250516172908: /etc/rc.d/ctld /etc/rc.d/iscsictl /etc/rc.d/iscsid /usr/bin/iscsictl /usr/sbin/ctladm /usr/sbin/ctld /usr/sbin/iscsid
i suggest creating a new package called FreeBSD-ctl and moving ctld, ctladm and ctlstat there. FreeBSD-iscsi can remain as the package for the iSCSI initiator.
this would support three discrete workloads:
- user wants an iSCSI initiator -> pkg in FreeBSD-iscsi
- user wants an iSCSI (or NVMoF, etc.) target -> pkg in FreeBSD-ctl
- user wants to manage hir local NVMe targets -> pkg in FreeBSD-nvme-tools
does this seem reasonable, and if so is there anything else we want to move at the same time?
You might want to drop a note in UPDATING since people who wants ctld will need to install this new package.