On Mon, Nov 15, 2010 at 03:36:25PM +0200, Gleb Natapov wrote: > On Mon, Nov 15, 2010 at 08:26:35AM -0500, Kevin O'Connor wrote: > > On Mon, Nov 15, 2010 at 09:40:08AM +0200, Gleb Natapov wrote: > > > On Sun, Nov 14, 2010 at 10:40:33PM -0500, Kevin O'Connor wrote: > > > > Why not just return a newline separated list that is null terminated? > > > > > > > Doing it like this will needlessly complicate firmware side. How do you > > > know how much memory to allocate before reading device list? > > > > My preference would be for the size to be exposed via the > > QEMU_CFG_FILE_DIR selector. (My preference would be for all objects > > in fw_cfg to have entries in QEMU_CFG_FILE_DIR describing their size > > in a reliable manner.) > > > Will interface suggested by Blue will be good for you? The one with two > fw_cfg ids. BOOTINDEX_LEN for len and BOOTINDEX_DATA for device list. I I dislike how different fw_cfg objects pass the length in different ways (eg, QEMU_CFG_E820_TABLE passes length as first 4 bytes). This is a common problem - I'd prefer if we could adopt one uniform way of passing length. I think QEMU_CFG_FILE_DIR solves this problem well. I also have an ulterior motive here. If the boot order is exposed as a newline separated list via an entry in QEMU_CFG_FILE_DIR, then this becomes free for coreboot users as well. (On coreboot, the boot order could be placed in a "file" in flash with no change to the seabios code.) -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
