qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Corey Minyard <minyard@acm.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Corey Minyard <cminyard@mvista.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] Sort the fw_cfg file list
Date: Tue, 15 Mar 2016 14:45:09 +0200	[thread overview]
Message-ID: <20160315144324-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <56E80253.3080605@acm.org>

On Tue, Mar 15, 2016 at 07:38:43AM -0500, Corey Minyard wrote:
> On 03/15/2016 04:37 AM, Michael S. Tsirkin wrote:
> >On Tue, Mar 15, 2016 at 09:45:22AM +0100, Gerd Hoffmann wrote:
> >>>Depends on how you code it up.  We have a list, we look each file
> >>>there and sort accordingly.  Fine.
> >>>New devices will not be on this list, I guess you can just ignore them
> >>>and guests will not see them. OK but I think it is better to make old
> >>>machine types see them.
> >>Not a new fw_cfg file.
> >>
> >>It's existing smbios file which gets new records added by a new device.
> >>So when initializing it early (old order) it doesn't (yet) contain the
> >>new records.  When initializing it late it has them, but also has a
> >>different place in the fw_cfg directory.
> >>
> >>So old machine types initialize smbios early (for compatibility).
> >I see. So in this model, we'd have to somehow keep track of
> >the old initialization order forever, and
> >add hacks whenever we change it.
> >IMHO That would just be too hard to maintain. I have an alternative
> >proposal.
> >
> >
> >
> >>New machine types initialize smbios late (so guests see the new
> >>records).
> >
> >So here is what I propose instead:
> >
> >- always initialize it late
> >- sort late, a machine done, not when inserting entries
> >- figure out what the order of existing entries is currently,
> >   and fill an array listing them in this order.
> >   for old machine types, insert the existing entries
> >   in this specific order by using a sorting function:
> >
> >qsort(....., fw_cfg_cmp);
> >
> >where:
> >
> >fw_cfg_find(a) {
> >     for (index = 0; index < fw_cfg_legacy_array_size; ++index)
> >         if (!strcmp(a, ...))
> >             break;
> >     return index;
> >}
> >
> >fw_cfg_cmp(a, b) {
> >     in cmp;
> >     if (legacy_fw_cfg_order) {
> >         int list1 = find(a);
> >         int list2 = find(b);
> >
> >         if (list1 < list2)
> >             return -1;
> >         if (list1 > list2)
> >             return 1;
> >     }
> >
> >     return strcmp(a, b);
> >}
> 
> Last night I had an idea something like this.  Sorting by filename
> may not work because the user may pass in the file from the
> command line and you wouldn't be able to track the file name that
> way.

command line files must all have a consistent prefix,
so we can skip sorting them.
I'll need to look at the code - don't they already?
If not we IMHO absolutely must fix that before release
and give them consistent prefixes.

> Instead, you could add a "legacy_order" parameter to the fw_cfg_add
> functions.  Then figure out the current order add the numeric
> order to each call.  Then sort by the numeric order.  As long as you
> don't reorder things with the same numeric value I think that
> would work and be fairly simple to implement.  New calls could
> pass in NO_FW_CFG_LEGACY_ORDER or something like that and
> be pasted onto the end in legacy mode.
> 
> -corey

OK but it's a much larger change and less well contained.

> >
> >
> >
> >
> >
> >
> >>While mucking with the file ordering anyway:  Good opportunity to make
> >>new machine types also sort the fw_cfg directory entries, so they get a
> >>fixed order independent from the order they are created, and we will not
> >>face this problem again.
> >>
> >>cheers,
> >>   Gerd
> >What exactly do you mean by directory entries here?
> >

  reply	other threads:[~2016-03-15 12:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 16:55 [Qemu-devel] [PATCH v2] Sort the fw_cfg file list minyard
2016-03-15  6:57 ` Michael S. Tsirkin
2016-03-15  7:04   ` Gerd Hoffmann
2016-03-15  7:17     ` Michael S. Tsirkin
2016-03-15  7:34       ` Gerd Hoffmann
2016-03-15  7:45         ` Michael S. Tsirkin
2016-03-15  8:45           ` Gerd Hoffmann
2016-03-15  9:37             ` Michael S. Tsirkin
2016-03-15 12:38               ` Corey Minyard
2016-03-15 12:45                 ` Michael S. Tsirkin [this message]
2016-03-15 12:56                   ` Corey Minyard
2016-03-15 13:47                     ` Michael S. Tsirkin
2016-03-15 14:43                     ` Michael S. Tsirkin
2016-03-15 16:36                   ` Corey Minyard
2016-03-15 17:01                     ` Michael S. Tsirkin
2016-03-16 15:21                       ` Corey Minyard
2016-03-16 15:34                         ` Paolo Bonzini
2016-03-16 15:37                         ` Michael S. Tsirkin
2016-03-15 13:03               ` Gerd Hoffmann
2016-03-15 13:19                 ` Michael S. Tsirkin

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=20160315144324-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=cminyard@mvista.com \
    --cc=kraxel@redhat.com \
    --cc=minyard@acm.org \
    --cc=pbonzini@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).