On 07.09.2021 11:17, Julien Grall wrote: > On 07/09/2021 09:33, Jan Beulich wrote: >> I'd like to suggest a different scheme, not the least because I expect >> the individual domains being independent of e.g. hypervisor command >> line options or Dom0 kernel versions. Yet varying sets of these are, >> for example, a reason to have multiple sections in the current scheme. >> Every dom0less guest would then require spelling out in every such >> section. Hence I think we'd be better off having a section per guest: >> >> [guest1] >> kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw >> property=cpus=1 >> property=memory=0xC0000 >> dtb=domu.dtb > > I much prefer the idea of the section. This is going to be easier to > parse the configuration file as we would not have to look for "domuX_" > and then distinguishing X. > >> >> These sections would then be referenced by other sections, e.g. by a >> new "guests" (or "domus", but this ends up looking a little odd for >> its matching of an unrelated latin word) keyword: >> >> guests=guest1,guest2 >> >> If it is deemed necessary to make sure such a section can't be >> (mistakenly) used to create Dom0, such sections would need identifying >> in some way. Presence of property= (or, as per below, properties=) >> could be one means (allowing an empty setting would then be desirable). > > I would expect dom0 to be described in the similar fashion at some > point. So maybe we should name the property "domains=...".
Not sure - the order above doesn't mandate domain IDs, yet Dom0 needs creating with ID 0. IOW I was deliberately suggesting "guests=". >> As to the properties, is there anything wrong with having them all on >> one line: >> >> [guest1] >> kernel=Image-domu1.bin console=ttyAMA0 root=/dev/ram0 rw >> dtb=domu.dtb >> properties=cpus=1 memory=0xC0000 > > It depends on the number of properties for the domain, this may become > quickly unreadable. > > But... if we use sections, then I think it would be better to have: > > kernel=.. > dtb=... > cpu=1 > memory=0xC0000 > > This would also allow us to create more complex setup (such as for the > static memory allocation). If that's feasible parsing-wise - sure. I was first thinking to suggest separate keywords, but then decided there was a reason this wasn't done in the original proposal (with respective dom#_ prefixes). Jan
