On Thu, Mar 17, 2016 at 02:55:52PM +0100, Paolo Bonzini wrote: > > > On 17/03/2016 14:49, Michael S. Tsirkin wrote: > >> On 17/03/2016 14:13, Michael S. Tsirkin wrote: > >>> > >>> QEMU command line: > >>> A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts > >>> with QEMU hardware > >> > >> Alternative: no need to prepend usr/, I think. > > > > I personally dislike telling user "do X". I don't see a reason not to be > > friendly and do X. The rare case where users do not want X can be > > easily enabled. > > I wouldn't include usr/ at all in the paths. The RFQDN recommendation > is enough to avoid clashes with etc/ and opt/.
Yes but then we need a blacklist. And usr/ is not visible to users so I do not see a problem with it. > >>> B. -fw-cfg org.qemu/unsupported/XXX as a hack, removes > >>> org.qemu/unsupported/ and leaves just XXX, > >>> for people who want to break^?^?^?^?^?debug QEMU hardware > >> > >> Alternative: fail on: > >> > >> - a blacklist of etc/* files including etc/system-states, > >> etc/smbios/smbios-tables, etc/smbios/smbios-anchor, > >> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly > >> etc/boot-menu-wait > > > > We can not predict the future. Future firmware will look for > > files under etc/mst. Users using this firmware with > > current QEMU will get a nasty surprise where it previously > > worked. > > > > Besides, it is way easier to maintain and understand a simple rule than > > a blacklist. > > The reason for the blacklist is that these are files owned by QEMU but > traditionally under etc/. The error can be simply "fw_cfg file %s is > provided by QEMU". If a file is added in the future that is owned by > QEMU, it will be under org.qemu/* so the blacklist will not grow. Yes, but a new prefix seems like a cleaner way. > >> Likewise SeaBIOS would switch from etc/ to an org.seabios/ prefix (for > >> stuff usable from both Coreboot and QEMU, e.g. > >> org.seabios/bootsplash.bmp) or org.qemu/ (for stuff that is specific to > >> QEMU). > >> > >> Files that could be moved from etc/ to org.qemu/ correspond to the ones > >> that are blacklisted in (B), e.g. etc/system-states -> > >> org.qemu/system-states. > > > > I am not sure about moving things into usr/org.qemu. > > These are system files, not user-provided ones. > > But we can argue about future plans down the road. > > Does it make more sense if it's just org.qemu, not usr/org.qemu? > > Thanks, > > Paolo I am not sure, let's discuss after 2.6. -- MST