Re: [PATCH 0/2] New zoned loop block device driver

[Jens Axboe <axboe@kernel.dk>]

On 1/6/25 8:44 AM, Christoph Hellwig wrote:
> On Mon, Jan 06, 2025 at 08:38:26AM -0700, Jens Axboe wrote:
>> On 1/6/25 8:32 AM, Christoph Hellwig wrote:
>>> On Mon, Jan 06, 2025 at 08:24:06AM -0700, Jens Axboe wrote:
>>>> A lot more code where?
>>>
>>> Very good and relevant question.  Some random new repo that no one knows
>>> about?  Not very helpful.  xfstests itself?  Maybe, but that would just
>>> means other users have to fork it.
>>
>> Why would they have to fork it? Just put it in xfstests itself. These
>> are very weak reasons, imho.
> 
> Because that way other users can't use it.  Damien has already mentioned
> some.

If it's actually useful to others, then it can become a standalone
thing. Really nothing new there.

> And someone would actually have to write that hypothetical thing.

That is certainly true.

>>>> Not in the kernel. And now we're stuck with a new
>>>> driver for a relatively niche use case. Seems like a bad tradeoff to me.
>>>
>>> Seriously, if you can't Damien and me to maintain a little driver
>>> using completely standard interfaces without any magic you'll have
>>> different problems keepign the block layer alive :)
>>
>> Asking "why do we need this driver, when we can accomplish the same with
>> existing stuff"
> 
> There is no "existing stuff"

Right, that's true on both sides now. Yes this kernel driver has been
written, but in practice there is no existing stuff.

>> is a valid question, and I'm a bit puzzled why we can't
>> just have a reasonable discussion about this.
> 
> I think this is a valid and reasonable discussion.  But maybe we're
> 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.

-- 
Jens Axboe