On Sun, Nov 14, 2010 at 08:49:59PM +0000, Blue Swirl wrote:
quoted text > On Sun, Nov 14, 2010 at 3:39 PM, Gleb Natapov <gleb@redhat.com> wrote:
> >
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> > hw/fw_cfg.c | 14 ++++++++++++++
> > hw/fw_cfg.h | 4 +++-
> > sysemu.h | 1 +
> > vl.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 69 insertions(+), 1 deletions(-)
> >
> > diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
> > index 7b9434f..f6a67db 100644
> > --- a/hw/fw_cfg.c
> > +++ b/hw/fw_cfg.c
> > @@ -53,6 +53,7 @@ struct FWCfgState {
> > FWCfgFiles *files;
> > uint16_t cur_entry;
> > uint32_t cur_offset;
> > + Notifier machine_ready;
> > };
> >
> > static void fw_cfg_write(FWCfgState *s, uint8_t value)
> > @@ -315,6 +316,15 @@ int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
> > return 1;
> > }
> >
> > +static void fw_cfg_machine_ready(struct Notifier* n)
> > +{
> > + uint32_t len;
> > + char *bootindex = get_boot_devices_list(&len);
> > +
> > + fw_cfg_add_bytes(container_of(n, FWCfgState, machine_ready),
> > + FW_CFG_BOOTINDEX, (uint8_t*)bootindex, len);
>
> I started to implement this to OpenBIOS but I noticed a small issue.
> First the first byte must be read to determine length. Then the read
> routine will be called again to read the correct amount of bytes. This
> would work, but since there is no shortage of IDs, I'd prefer a system
> where one ID is used to query the length and another ID is used to
> read the data, without the length byte. This is similar how command
> line, initrd etc. are handled.
>
> This would have the advantage that since fw_cfg uses little endian
> format, the length value would easily scale to for example 64 bits to
> support terabytes of boot device lists. ;-)
Yea. Let's just print # of devices as a property, in ASCII.
No endian-ness, no nothing.
Also - can we just NULL-terminate each ID?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html