Re: [pve-devel] [PATCH qemu-server 20/22] blockdev: add helpers to generate blockdev commandline

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

> Fiona Ebner <f.ebner@proxmox.com> hat am 17.06.2025 11:37 CEST geschrieben:
> 
>  
> Am 13.06.25 um 13:35 schrieb Fabian Grünbichler:
> > On June 12, 2025 4:02 pm, Fiona Ebner wrote:
> >> The drive device and node structure is:
> >> front-end device {ide-hd,scsi-hd,virtio-blk-pci} (id=$drive_id)
> >>  - throttle node (node-name=$drive_id)
> > 
> > should we prefix this is well to not "use" the basic name (e.g., in case
> > in the future a new "topmost" node comes along)?
> 
> We could, but what would be the advantage?

mainly a consistent naming scheme I guess? :)

> We can just rename it when the time comes and call the new top-most node
> $drive_id then. We reference the node from the front-end device, so if
> we do it now, the name would also need to be adapted there and again in
> the future. But I'd rather like keeping the front-end device referring
> to $drive_id and making sure that is the one we want also in the future.
> 
> We want to operate below the throttle node, because the throttling would
> also apply to block jobs, not just guest reads, which we do not want. So
> it's very likely that we want to insert any future node in the chain
> still below the throttling node.

sounds sensible

> 
> >> +my sub read_only_json_option {
> >> +    my ($drive, $options) = @_;
> >> +
> >> +    return JSON::true if $drive->{ro} || drive_is_cdrom($drive) || $options->{'read-only'};
> >> +    return JSON::false;
> > 
> > should we maybe have a generic jsonify-helper instead?
> 
> For bool, I'll add one to pve-common since I need to touch that anyways.
> But in general, we cannot know if a string that looks like a number
> should be a number or not without additional info.

yes, I meant for bools. and yes, of course for number handling we'd need
to "know" at the call site whether to encode something as a JSON number
or as-is as a string (our API is quite relaxed in that regard, but that
is not the case for other external interfaces).


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel