From: Anthony Liguori <anthony@codemonkey.ws> To: Blue Swirl <blauwirbel@gmail.com> Cc: Chris Wright <chrisw@redhat.com>, kvm@vger.kernel.org, Gleb Natapov <gleb@redhat.com>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Avi Kivity <avi@redhat.com> Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Tue, 15 Feb 2011 17:07:07 -0600 [thread overview] Message-ID: <4D5B071B.6060900@codemonkey.ws> (raw) In-Reply-To: <AANLkTinkRTDf0UoShN-41zEC_h6xrqHgpowhfwhKfWeM@mail.gmail.com> On 02/15/2011 11:11 AM, Blue Swirl wrote: > On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: > >> Any device we expose to the user through -device needs to maintain a >> compatible interface forever. For our own sanity, I think we should try to >> expose as little as possible. >> > Restricting the users from adding arbitrary devices is a different > issue. Dropping qdev support to prevent user from adding the device > seems draconian, what's wrong with no_user flag? > I think you're missing my point. It should be possible to make a device "qdev" without exposing it via a factory interface. Today it's all or nothing and that's the part I dislike. no_user is a hack. We can do better. >> A good example of a device that we should model through qdev but not expose >> via -device is actually SerialState. >> > You wouldn't want users to add any serial ports? What should be do > with serial ports then, always enable a full set of ports? How would > the user use them? > No, users should be able to create ISASerialDevice, MMIOSerialDevice, but not UART16650A. Here's what I'm talking about: class ISASerialDevice : public ISADevice { UART16650A uart; }; class MMIOSerialDevice : public PlatformDevice { UART16650A uart; }; There should be factory interfaces for ISASeriaDevice and MMIOSerialDevice but not UART16650A. >> Today, we have ISASerialState which embeds SerialState. We can also create >> a MMIO version of SerialState although there's no direct structure that >> wraps that. >> >> Ideally, SerialState would be a proper qdev device that is embedded in both >> ISASerialState and MMIOSerialState (or pick a better name). info qtree >> should show a has-a relationship for these devices. >> > I think the devices shown in qtree should always have some > relationship to real devices. If ICH10 contains all possible onboard > devices, including for example HPET, e1000 and SATA, that could use a > has-a relationship to show the composition Yeah, I'm not disagreeing at all. Ignoring the fact that modern uarts are implemented in a super i/o chip, it's same chip whether it's soldered directly on a board with direct connections to a CPU bus or whether it's exposed on the ISA bus. Regards, Anthony Liguori > but otherwise I fear this > would only increase complexity with no gain. > >
WARNING: multiple messages have this Message-ID (diff)
From: Anthony Liguori <anthony@codemonkey.ws> To: Blue Swirl <blauwirbel@gmail.com> Cc: Chris Wright <chrisw@redhat.com>, kvm@vger.kernel.org, Gleb Natapov <gleb@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com> Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Tue, 15 Feb 2011 17:07:07 -0600 [thread overview] Message-ID: <4D5B071B.6060900@codemonkey.ws> (raw) In-Reply-To: <AANLkTinkRTDf0UoShN-41zEC_h6xrqHgpowhfwhKfWeM@mail.gmail.com> On 02/15/2011 11:11 AM, Blue Swirl wrote: > On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori<anthony@codemonkey.ws> wrote: > >> Any device we expose to the user through -device needs to maintain a >> compatible interface forever. For our own sanity, I think we should try to >> expose as little as possible. >> > Restricting the users from adding arbitrary devices is a different > issue. Dropping qdev support to prevent user from adding the device > seems draconian, what's wrong with no_user flag? > I think you're missing my point. It should be possible to make a device "qdev" without exposing it via a factory interface. Today it's all or nothing and that's the part I dislike. no_user is a hack. We can do better. >> A good example of a device that we should model through qdev but not expose >> via -device is actually SerialState. >> > You wouldn't want users to add any serial ports? What should be do > with serial ports then, always enable a full set of ports? How would > the user use them? > No, users should be able to create ISASerialDevice, MMIOSerialDevice, but not UART16650A. Here's what I'm talking about: class ISASerialDevice : public ISADevice { UART16650A uart; }; class MMIOSerialDevice : public PlatformDevice { UART16650A uart; }; There should be factory interfaces for ISASeriaDevice and MMIOSerialDevice but not UART16650A. >> Today, we have ISASerialState which embeds SerialState. We can also create >> a MMIO version of SerialState although there's no direct structure that >> wraps that. >> >> Ideally, SerialState would be a proper qdev device that is embedded in both >> ISASerialState and MMIOSerialState (or pick a better name). info qtree >> should show a has-a relationship for these devices. >> > I think the devices shown in qtree should always have some > relationship to real devices. If ICH10 contains all possible onboard > devices, including for example HPET, e1000 and SATA, that could use a > has-a relationship to show the composition Yeah, I'm not disagreeing at all. Ignoring the fact that modern uarts are implemented in a super i/o chip, it's same chip whether it's soldered directly on a board with direct connections to a CPU bus or whether it's exposed on the ISA bus. Regards, Anthony Liguori > but otherwise I fear this > would only increase complexity with no gain. > >
next prev parent reply other threads:[~2011-02-15 23:07 UTC|newest] Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-08 15:55 KVM call minutes for Feb 8 Chris Wright 2011-02-08 15:55 ` [Qemu-devel] " Chris Wright 2011-02-08 16:14 ` Stefan Hajnoczi 2011-02-08 16:14 ` [Qemu-devel] " Stefan Hajnoczi 2011-02-08 16:39 ` [Qemu-devel] " Anthony Liguori 2011-02-08 16:39 ` Anthony Liguori 2011-02-08 17:13 ` Markus Armbruster 2011-02-08 17:13 ` Markus Armbruster 2011-02-08 19:02 ` Peter Maydell 2011-02-08 21:11 ` Anthony Liguori 2011-02-08 21:11 ` Anthony Liguori 2011-02-09 8:11 ` Markus Armbruster 2011-02-09 8:20 ` Peter Maydell 2011-02-09 9:02 ` Markus Armbruster 2011-02-08 19:30 ` Alexander Graf 2011-02-08 19:30 ` Aurelien Jarno 2011-02-09 8:23 ` Markus Armbruster 2011-02-09 10:43 ` Anthony Liguori 2011-02-09 10:43 ` Anthony Liguori 2011-02-09 17:38 ` Blue Swirl 2011-02-09 17:38 ` Blue Swirl 2011-02-08 21:12 ` Anthony Liguori 2011-02-09 8:01 ` Markus Armbruster 2011-02-09 10:31 ` Anthony Liguori 2011-02-09 12:28 ` Markus Armbruster 2011-02-09 14:44 ` Anthony Liguori 2011-02-09 17:48 ` Blue Swirl 2011-02-09 17:48 ` Blue Swirl 2011-02-09 19:53 ` Anthony Liguori 2011-02-09 19:59 ` Anthony Liguori 2011-02-09 20:15 ` Blue Swirl 2011-02-10 7:47 ` Anthony Liguori 2011-02-10 8:16 ` Peter Maydell 2011-02-10 8:36 ` Anthony Liguori 2011-02-10 9:04 ` Peter Maydell 2011-02-10 10:13 ` Anthony Liguori 2011-02-10 10:38 ` Peter Maydell 2011-02-10 11:24 ` Gleb Natapov 2011-02-10 11:24 ` Gleb Natapov 2011-02-10 12:23 ` Anthony Liguori 2011-02-10 13:06 ` Peter Maydell 2011-02-10 19:17 ` Scott Wood 2011-02-10 19:17 ` Scott Wood 2011-02-10 19:22 ` Peter Maydell 2011-02-10 19:22 ` Peter Maydell 2011-02-10 19:29 ` Scott Wood 2011-02-10 19:29 ` Scott Wood 2011-02-10 9:07 ` Gleb Natapov 2011-02-10 10:00 ` Anthony Liguori 2011-02-10 10:10 ` Gleb Natapov 2011-02-10 10:19 ` Anthony Liguori 2011-02-10 10:49 ` Gleb Natapov 2011-02-10 12:47 ` Anthony Liguori 2011-02-10 13:12 ` Gleb Natapov 2011-02-10 10:25 ` Avi Kivity 2011-02-10 10:25 ` Avi Kivity 2011-02-10 11:13 ` Gleb Natapov 2011-02-10 11:13 ` Gleb Natapov 2011-02-10 12:51 ` Anthony Liguori 2011-02-10 12:51 ` Anthony Liguori 2011-02-10 13:00 ` Avi Kivity 2011-02-10 13:00 ` Avi Kivity 2011-02-10 13:29 ` Gleb Natapov 2011-02-10 13:29 ` Gleb Natapov 2011-02-10 14:00 ` Anthony Liguori 2011-02-10 14:00 ` Anthony Liguori 2011-02-10 13:27 ` Gleb Natapov 2011-02-10 13:27 ` Gleb Natapov 2011-02-10 14:04 ` Anthony Liguori 2011-02-10 14:20 ` Gleb Natapov 2011-02-10 16:05 ` Anthony Liguori 2011-02-11 18:14 ` Blue Swirl 2011-02-11 18:14 ` Blue Swirl 2011-02-13 9:24 ` Gleb Natapov 2011-02-13 9:24 ` Gleb Natapov 2011-02-13 15:31 ` Anthony Liguori 2011-02-13 15:31 ` Anthony Liguori 2011-02-13 19:37 ` Blue Swirl 2011-02-13 19:37 ` Blue Swirl 2011-02-13 19:57 ` Anthony Liguori 2011-02-13 19:57 ` Anthony Liguori 2011-02-13 21:00 ` Blue Swirl 2011-02-13 21:00 ` Blue Swirl 2011-02-13 22:42 ` Anthony Liguori 2011-02-13 22:42 ` Anthony Liguori 2011-02-14 17:31 ` Blue Swirl 2011-02-14 17:31 ` Blue Swirl 2011-02-14 20:53 ` Anthony Liguori 2011-02-14 20:53 ` Anthony Liguori 2011-02-14 21:25 ` Blue Swirl 2011-02-14 21:25 ` Blue Swirl 2011-02-14 21:47 ` Anthony Liguori 2011-02-14 21:47 ` Anthony Liguori 2011-02-15 17:11 ` Blue Swirl 2011-02-15 17:11 ` Blue Swirl 2011-02-15 23:07 ` Anthony Liguori [this message] 2011-02-15 23:07 ` Anthony Liguori 2011-02-16 9:52 ` Gleb Natapov 2011-02-16 9:52 ` Gleb Natapov 2011-02-14 9:44 ` Paolo Bonzini 2011-02-14 9:44 ` Paolo Bonzini 2011-02-10 10:29 ` Avi Kivity 2011-02-13 15:38 ` Anthony Liguori 2011-02-13 15:38 ` Anthony Liguori 2011-02-13 15:56 ` Avi Kivity 2011-02-13 16:56 ` Anthony Liguori 2011-02-13 18:08 ` Gleb Natapov 2011-02-13 18:08 ` Gleb Natapov 2011-02-13 19:38 ` Anthony Liguori 2011-02-14 10:23 ` Gleb Natapov 2011-02-13 21:24 ` Peter Maydell 2011-02-13 21:24 ` Peter Maydell 2011-02-13 22:43 ` Anthony Liguori 2011-02-13 22:43 ` Anthony Liguori 2011-02-13 23:35 ` Peter Maydell 2011-02-13 15:39 ` Anthony Liguori 2011-02-13 15:39 ` Anthony Liguori 2011-02-11 17:54 ` Blue Swirl
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=4D5B071B.6060900@codemonkey.ws \ --to=anthony@codemonkey.ws \ --cc=armbru@redhat.com \ --cc=avi@redhat.com \ --cc=blauwirbel@gmail.com \ --cc=chrisw@redhat.com \ --cc=gleb@redhat.com \ --cc=kvm@vger.kernel.org \ --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: linkBe 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.