On Mon, Jan 06, 2025 at 10:38:24AM -0700, Jens Axboe wrote: > > just not on the same page. I don't know anything existing and usable, > > maybe I've just not found it? > > Not that I'm aware of, it was just a suggestion/thought that we could > utilize an existing driver for this, rather than have a separate one. > Yes the proposed one is pretty simple and not large, and maintaining it > isn't a big deal, but it's still a new driver and hence why I was asking > "why can't we just use ublk for this". That also keeps the code mostly > in userspace which is nice, rather than needing kernel changes for new > features, changes, etc. Well, the reason to do a kernel driver rather than a ublk back end boils down to a few things: - writing highly concurrent code is actually a lot simpler in the kernel than in userspace because we have the right primitives for it - these primitives tend to actually be a lot faster than those available in glibc as well - the double context switch into the kernel and back for a ublk device backed by a file system will actually show up for some xfstests that do a lot of synchronous ops - having an in-tree kernel driver that you just configure / unconfigure from the shell is a lot easier to use than a daemon that needs to be running. Especially from xfstests or other test suites that do a lot of per-test setup and teardown - the kernel actually has really nice infrastructure for block drivers. I'm pretty sure doing this in userspace would actually be more code, while being harder to use and lower performance. So we could go both ways, but the kernel version was pretty obviously the preferred one to me. Maybe that's a little biasses by doing a lot of kernel work, and having run into a lot of problems and performance issues with the SCSI target user backend lately.
