All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Kevin O'Connor" <kevin@koconnor.net>
Cc: seabios@seabios.org, kvm@vger.kernel.org
Subject: Re: [PATCHv3 4/4] acpi: automatically generated ssdt proc
Date: Mon, 17 Oct 2011 20:16:20 +0200	[thread overview]
Message-ID: <20111017181620.GA9899@redhat.com> (raw)
In-Reply-To: <20111006021526.GA23719@morn.localdomain>

On Wed, Oct 05, 2011 at 10:15:26PM -0400, Kevin O'Connor wrote:
> Sure:
> 
> - The DSDT is big and has several cross-functional users.  Patching up
>   the DSDT for hotplug when the DSDT also has unrelated stuff (eg,
>   mouse) seems ugly.
> 
> - The PCI hotplug stuff is generating a whole bunch of devices and the
>   dynamic code is effectively disabling the unwanted ones.  It seems
>   nicer to dynamically generate the desired entries instead of bulk
>   generating and dynamically blanking.
> 
> - The CPU hotplug has similar requirements, but is implemented
>   differently - it generates the CPU objects dynamically.  It's not
>   desirable to bulk generate the CPU objects and "blank" them
>   dynamically, because 255 CPU objects would noticeably increase
>   SeaBIOS' static size.
> 
> - Some time back there were patches floating around to pass the DSDT
>   into SeaBIOS via fw_cfg interface.  Those patches never made it in
>   (I forget why), but the basic functionality seemed sound.  Patching
>   the DSDT in SeaBIOS would seem to eliminate that possibility.
> 
> None of these would be road-blocks.  However, they make me want to
> consider other approaches.

So if we had the hotplug stuff in a separate ssdt, and patched that in
the same way my patches do, this seems to address 3 comments otu of 4
(all except the second one).

We'll want to do something else for a bridge, but for now this
seems a sane compromise?

-- 
MST

  parent reply	other threads:[~2011-10-17 18:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-04 13:25 [PATCHv3 0/4] acpi: DSDT/SSDT runtime patching Michael S. Tsirkin
2011-10-04 13:26 ` [PATCHv3 1/4] acpi: generate and parse mixed asl/aml listing Michael S. Tsirkin
2011-10-04 13:26 ` [PATCHv3 2/4] acpi: EJ0 method name patching Michael S. Tsirkin
2011-10-04 13:26 ` [PATCHv3 3/4] acpi: remove _RMV Michael S. Tsirkin
2011-10-04 13:26 ` [PATCHv3 4/4] acpi: automatically generated ssdt proc Michael S. Tsirkin
2011-10-05  2:52   ` Kevin O'Connor
2011-10-05 10:35     ` Michael S. Tsirkin
2011-10-06  2:15       ` Kevin O'Connor
2011-10-17 17:47         ` [SeaBIOS] " Isaku Yamahata
2011-10-18  3:47           ` Kevin O'Connor
2011-10-17 18:16         ` Michael S. Tsirkin [this message]
2011-10-13  1:27   ` 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=20111017181620.GA9899@redhat.com \
    --to=mst@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kvm@vger.kernel.org \
    --cc=seabios@seabios.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.