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: > > On Sun, Nov 14, 2010 at 05:39:41PM +0200, Gleb Natapov wrote: > > > +/* > > > + * This function returns device list as an array in a below format: > > > + * +-----+-----+---------------+-----+---------------+-- > > > + * | n | l1 | devpath1 | l2 | devpath2 | ... > > > + * +-----+-----+---------------+-----+---------------+-- > > > + * where: > > > + * n - a number of devise pathes (one byte) > > > + * l - length of following device path string (one byte) > > > + * devpath - non-null terminated string of length l representing > > > + * one device path > > > + */ > > > > 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? Do a memory scan, count newlines until you reach 0? > Doing it > like Blue suggest (have BOOTINDEX_LEN and BOOTINDEX_STRING) solves this. > To create nice array from bootindex string you firmware will still have > to do additional pass on it though. Why is this a problem? Pass over memory is cheap, isn't it? > With format like above the code > would look like that: > > qemu_cfg_read(&n, 1); > arr = alloc(n); > for (i=0; i<n; i++) { > qemu_cfg_read(&l, 1); > arr[i] = zalloc(l+1); > qemu_cfg_read(arr[i], l); > } > > > -- > Gleb. At this point I don't care about format. But I would like one without 1-byte-length limitations, just so we can cover whatever pci can through at us. -- MST -- 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