From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afoFO-0003es-Gd for qemu-devel@nongnu.org; Tue, 15 Mar 2016 08:38:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afoFK-0006it-Au for qemu-devel@nongnu.org; Tue, 15 Mar 2016 08:38:50 -0400 Received: from mail-oi0-x241.google.com ([2607:f8b0:4003:c06::241]:35313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afoFK-0006in-3o for qemu-devel@nongnu.org; Tue, 15 Mar 2016 08:38:46 -0400 Received: by mail-oi0-x241.google.com with SMTP id r187so922819oih.2 for ; Tue, 15 Mar 2016 05:38:46 -0700 (PDT) Sender: Corey Minyard References: <1457974531-8768-1-git-send-email-minyard@acm.org> <20160315085654-mutt-send-email-mst@redhat.com> <1458025488.13231.20.camel@redhat.com> <20160315091411-mutt-send-email-mst@redhat.com> <1458027249.13231.27.camel@redhat.com> <20160315093529-mutt-send-email-mst@redhat.com> <1458031522.13231.39.camel@redhat.com> <20160315113016-mutt-send-email-mst@redhat.com> From: Corey Minyard Message-ID: <56E80253.3080605@acm.org> Date: Tue, 15 Mar 2016 07:38:43 -0500 MIME-Version: 1.0 In-Reply-To: <20160315113016-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] Sort the fw_cfg file list Reply-To: minyard@acm.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Gerd Hoffmann Cc: Paolo Bonzini , qemu-devel@nongnu.org, Corey Minyard 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. 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 > > > > > > >> 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? >