Laszlo Ersek <ler...@redhat.com> writes: > On 06/24/19 12:18, Kevin Wolf wrote: >> Am 24.06.2019 um 10:01 hat Klaus Birkelund geschrieben: >>> On Thu, Jun 20, 2019 at 05:37:24PM +0200, Laszlo Ersek wrote: >>>> On 06/17/19 10:12, Klaus Birkelund wrote: >>>>> Hi all, >>>>> >>>>> I'm thinking about how to support multiple namespaces in the NVMe >>>>> device. My first idea was to add a "namespaces" property array to the >>>>> device that references blockdevs, but as Laszlo writes below, this might >>>>> not be the best idea. It also makes it troublesome to add per-namespace >>>>> parameters (which is something I will be required to do for other >>>>> reasons). Some of you might remember my first attempt at this that >>>>> included adding a new block driver (derived from raw) that could be >>>>> given certain parameters that would then be stored in the image. But I >>>>> understand that this is a no-go, and I can see why. >>>>> >>>>> I guess the optimal way would be such that the parameters was something >>>>> like: >>>>> >>>>> -blockdev >>>>> raw,node-name=blk_ns1,file.driver=file,file.filename=blk_ns1.img >>>>> -blockdev >>>>> raw,node-name=blk_ns2,file.driver=file,file.filename=blk_ns2.img >>>>> -device nvme-ns,drive=blk_ns1,ns-specific-options (nsfeat,mc,dlfeat)... >>>>> -device nvme-ns,drive=blk_ns2,... >>>>> -device nvme,... >>>>> >>>>> My question is how to state the parent/child relationship between the >>>>> nvme and nvme-ns devices. I've been looking at how ide and virtio does >>>>> this, and maybe a "bus" is the right way to go? >>>> >>>> I've added Markus to the address list, because of this question. No >>>> other (new) comments from me on the thread starter at this time, just >>>> keeping the full context. >>>> >>> >>> Hi all, >>> >>> I've succesfully implemented this by introducing a new 'nvme-ns' device >>> model. The nvme device creates a bus named from the device id ('id' >>> parameter) and the nvme-ns devices are then registered on this. >>> >>> This results in an nvme device being creates like this (two namespaces >>> example): >>> >>> -drive file=nvme0n1.img,if=none,id=disk1 >>> -drive file=nvme0n2.img,if=none,id=disk2 >>> -device nvme,serial=deadbeef,id=nvme0 >>> -device nvme-ns,drive=disk1,bus=nvme0,nsid=1 >>> -device nvme-ns,drive=disk2,bus=nvme0,nsid=2 >>> >>> How does that look as a way forward? >> >> This looks very similar to what other devices do (one bus controller >> that has multiple devices on its but), so I like it.
Devices can be wired together without a bus intermediary. You definitely want a bus when the physical connection you model has one. If not, a bus may be useful anyway, say because it provides a convenient way to encapsulate the connection model, or to support -device bus=... > +1 > > Also, I believe it's more modern nowadays to express the same example > with "blockdev" syntax, rather than "drive". (Not that I could suggest > the exact spelling for that :)) I don't expect the modern syntax to > behave differently, I just guess it's better to stick with the new in > examples / commit messages etc. Management applications should move to -blockdev. -drive has too much bad magic sticking to it. We're not urging humans to switch, at least not yet. We may want to provide convenience features on top of plain -blockdev before we do. As far as I know, we don't yet eschew -drive in documentation or commit messages. Perhaps we should consider such a policy for documentation. [...]