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
