On 1/6/25 11:05 AM, Christoph Hellwig wrote: > 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 That's certainly true. > - 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 Like I replied to Damien, that's mostly a bogus argument. If you're doing sync stuff, you can do that with a single system call. If you're building up depth, then it doesn't matter. > - 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 This is always true when it's a new piece of userspace, but not necessarily true once the use case has been established. > - 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. That's very handwavy... > 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. Sure, that is understandable. -- Jens Axboe
