On Tue, Jun 25, 2019 at 07:51:29AM +0200, Markus Armbruster wrote: > 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=... > I'm not sure how to wire it together without the bus abstraction? So I'll stick with the bus for now. It *is* extremely convenient!
Cheers, Klaus