From: Gleb Natapov <gleb@redhat.com>
To: Kevin O'Connor <kevin@koconnor.net>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 2/2] Load SMBIOS entries and files from qemu
Date: Thu, 8 Oct 2009 08:22:35 +0200 [thread overview]
Message-ID: <20091008062235.GC16702@redhat.com> (raw)
In-Reply-To: <20091007235326.GD15407@morn.localdomain>
On Wed, Oct 07, 2009 at 07:53:26PM -0400, Kevin O'Connor wrote:
> On Wed, Oct 07, 2009 at 06:16:51PM +0200, Gleb Natapov wrote:
> > Allow SMBIOS fields to be overridden and entries replaced by those
> > read from qemu.
> >
> > This is port of commit f4a09e759469be74e2598758bfae623b555c4cae
> > from qemu pc-bios tree.
> >
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
>
> Two comments:
>
> The smbios code is allocating 2K of high ram for the full table. Now
> that tables can be pulled in from qemu, is it assured that the space
> wont overflow?
No it is not. We should check this is and stop table loading on overflow.
>
> [...]
> > +#define load_str_field_with_default(type, field, def) \
> [...]
>
> These macros are really ugly - isn't there a better way to do this?
>
This is direct port from qemu pcbios, so there the code is exactly the
same if it makes you feel better :) Otherwise I agree with you that
smbios table could have been done easier, but existing qemu-to-bios
interface dictates this complex implementation. I don't see how can we get
rid of this macros. Without them we will have to open code the same
logic in every place they are used.
--
Gleb.
next prev parent reply other threads:[~2009-10-08 6:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-07 16:16 [Qemu-devel] [PATCH 1/2] resolve memory device roll over reporting issues with >32G guests Gleb Natapov
2009-10-07 16:16 ` [Qemu-devel] [PATCH 2/2] Load SMBIOS entries and files from qemu Gleb Natapov
2009-10-07 23:53 ` [Qemu-devel] " Kevin O'Connor
2009-10-08 6:22 ` Gleb Natapov [this message]
2009-10-07 23:49 ` [Qemu-devel] Re: [PATCH 1/2] resolve memory device roll over reporting issues with >32G guests Kevin O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091008062235.GC16702@redhat.com \
--to=gleb@redhat.com \
--cc=kevin@koconnor.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.