All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Thu, 18 Mar 2010 09:36:15 +0100	[thread overview]
Message-ID: <m339zyni0w.fsf@trasno.mitica> (raw)
In-Reply-To: <20100318074239.GA23474@redhat.com> (Michael S. Tsirkin's message of "Thu, 18 Mar 2010 09:42:39 +0200")

"Michael S. Tsirkin" <mst@redhat.com> wrote:

>>   Look at the rest of hw/*.
>
> I think you mean that a similar assumption is made by lots of
> other code. Does not mean it's always a good idea and that
> we need to force this assumption everywhere.

Principle of Least Surprise.  as posted in the other email, removing
that assumption don't bring us anything and just make code more complex
(not a huge ammount, but more complex).

>> The only "sane" way of doing OOP on C is to use the super-class memmbers as the
>> 1st member of the sub-classes.  That will not change anytime soon.  And
>> trying to "emulate" multiple inheritance in C is completely "insane".
>
> container_of does it and I think it's sane.
> People like comparing it to inheritance but for me it's just
> using a field in a structure. multiple fields in a structure are insane?

It is inheritance.

we assume in virtio_common_init() can be called for all virtio devices.
That means that all virtio devices have "something" in common.
That is the basic concept of super-class and sub-class.  Yes, C sucks
for describing that kind of relationships, but that is a different matter.

>> This "assumption" is used for all the
>> code left and right.  It is an essentioal part of the qdev design, not
>> something that can be changed easily.
>
> I do not think it is essential at all. We just add an offset.
> Yes we make such assumptions a lot but it's a bug, not a feature.

Clearly, we don't agree here.  For me it is a "feature" that all virtio
devices are in the way:

struct virtio_common {
...
}

struct virtio_specific {
       struct virtio_common common;
       <specific fields>
}

And then I can pass virtio_specific pointers to virtio_common routines
and things just work.  Special importance when we have callbacks, and
virtio_specific parts are only used in virtio_specific.c file.

Why do you want to break that assumption that is used (in a good place)
in a lot of qemu code (qdev "requires" it)?  For me is a clear case of
coherence.  Virtio* can live with container_of() instead of DO_UPCAST()
because they are not exposed (directly) through qdev.  Then mark it as
different that everything else, indeed if it don't bring us anything,
just to confuse new users.  This is one of the features that I hate
more,  searching for how to use a qemu api because from only the
prototypes it is not clear, and just pick an example, and that one uses
it in a non-conventional way.

Later, Juan.

  reply	other threads:[~2010-03-18  8:37 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-16 18:51 [Qemu-devel] [PATCH 0/9] Virtio cleanups Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 1/9] qemu/pci: document msix_entries_nr field Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 2/9] virtio: Teach virtio-balloon about DO_UPCAST Juan Quintela
2010-03-18  7:29   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 3/9] virtio: Teach virtio-blk " Juan Quintela
2010-03-18  7:29   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 4/9] virtio: Teach virtio-net " Juan Quintela
2010-03-18  7:29   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 5/9] virtio: Use DO_UPCAST instead of a cast Juan Quintela
2010-03-18  7:30   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 6/9] virtio-pci: Remove duplicate test Juan Quintela
2010-03-18  7:25   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-18  8:26     ` Juan Quintela
2010-03-18  8:47       ` Michael S. Tsirkin
2010-03-18  8:59         ` Juan Quintela
2010-03-18  9:11           ` Michael S. Tsirkin
2010-03-18 11:40             ` Juan Quintela
2010-03-18 13:24               ` Michael S. Tsirkin
2010-03-18 13:47                 ` Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 7/9] QLIST: Introduce QLIST_COPY_HEAD Juan Quintela
2010-03-16 18:51 ` [Qemu-devel] [PATCH 8/9] virtio-blk: change rq type to VirtIOBlockReq Juan Quintela
2010-03-18  7:27   ` [Qemu-devel] " Michael S. Tsirkin
2010-03-16 18:51 ` [Qemu-devel] [PATCH 9/9] virtio-blk: use QLIST for the list of requests Juan Quintela
2010-03-18  6:40 ` [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups Michael S. Tsirkin
2010-03-18  7:36   ` Juan Quintela
2010-03-18  7:42     ` Michael S. Tsirkin
2010-03-18  8:36       ` Juan Quintela [this message]
2010-03-18  9:07         ` Michael S. Tsirkin
2010-03-18 11:53           ` Juan Quintela
2010-03-18 12:33             ` Michael S. Tsirkin
2010-03-18 13:43               ` Juan Quintela
2010-03-18 13:47                 ` Michael S. Tsirkin
2010-03-18 14:21                   ` Juan Quintela
2010-03-18 17:13                     ` Michael S. Tsirkin
2010-03-19  1:41             ` Jamie Lokier
2010-03-21 14:31               ` Michael S. Tsirkin
2010-03-21 18:11                 ` Jamie Lokier
2010-03-21 19:16                   ` Michael S. Tsirkin
2010-03-22  1:06                     ` Juan Quintela
2010-03-22  2:51                       ` Anthony Liguori
2010-03-22 13:30                         ` Paul Brook
2010-03-22 14:49                           ` Anthony Liguori
2010-03-22 14:50                             ` Michael S. Tsirkin
2010-03-22 15:03                               ` Anthony Liguori
2010-03-22 15:17                                 ` Michael S. Tsirkin
2010-03-22 15:50                                   ` Anthony Liguori
2010-03-22 16:16                                     ` Paul Brook
2010-03-22 18:48                                       ` Anthony Liguori
2010-03-22 21:00                                         ` Paul Brook
2010-03-23  1:13                                           ` Anthony Liguori
2010-03-22 15:51                                   ` Paul Brook
2010-03-22 17:19                                     ` Michael S. Tsirkin
2010-03-22 22:16                                       ` Juan Quintela
2010-03-23  0:49                                         ` Paul Brook
2010-03-23  1:16                                           ` Anthony Liguori
2010-03-23 10:47                                             ` Michael S. Tsirkin
2010-03-23 11:11                                               ` Gerd Hoffmann
2010-03-23 11:40                                               ` Paul Brook
2010-03-23 11:58                                                 ` Michael S. Tsirkin
2010-03-23 12:32                                                   ` Juan Quintela
2010-03-21 19:57                   ` Michael S. Tsirkin
2010-03-22  1:13                     ` Juan Quintela
2010-03-22  8:37                       ` Michael S. Tsirkin
2010-03-18 10:05         ` Michael S. Tsirkin
2010-03-18 15:43     ` Gerd Hoffmann
2010-03-18 16:20       ` Juan Quintela
2010-03-18 16:36         ` Gerd Hoffmann
2010-03-18 17:08           ` Juan Quintela
2010-03-18 17:21             ` Michael S. Tsirkin
2010-03-18 19:37               ` Juan Quintela
2010-03-18 20:07           ` Anthony Liguori

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=m339zyni0w.fsf@trasno.mitica \
    --to=quintela@redhat.com \
    --cc=mst@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 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.