qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-ppc <qemu-ppc@nongnu.org>, "Fam Zheng" <famz@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH 0/3] scsi: remove lsi53c895a_create() and lsi53c810_create() functions
Date: Fri, 7 Sep 2018 08:27:33 +0200	[thread overview]
Message-ID: <4fa06493-e79b-79f2-ba7c-920de9dc51b2@redhat.com> (raw)
In-Reply-To: <507bad9d-61fc-c513-e023-674836eb72a1@ilande.co.uk>

On 2018-09-06 19:15, Mark Cave-Ayland wrote:
> On 06/09/18 17:40, Thomas Huth wrote:
[...]
> Amusingly the main reason I need to expose the LSIState at all is to be
> able to call scsi_bus_legacy_handle_cmdline() on the SCSI bus object
> itself. I guess you could say that this is an argument in favour of the
> existing approach, but then you're effectively moving back to the
> equivalent of _init() functions for this one particular case which these
> days are considered to be bad.

If you mind that the "init" function creates the object, too, then
simply remove the two "lsi53c*_create" functions and provide a function
that looks like this instead:

void lsi53c8xx_handle_legacy_cmdline(DeviceState *lsi_dev)
{
    LSIState *s = LSI53C895A(lsi_dev);

    scsi_bus_legacy_handle_cmdline(&s->bus);
}

Then you can create the device from another .c file and simply call this
new function instead of scsi_bus_legacy_handle_cmdline() in that other
.c file.

In the long run, I think we should maybe also rather get rid of
scsi_bus_legacy_handle_cmdline() and either remove -drive if=scsi or
provide another more generic solution instead (e.g. some code that scans
the qdev tree for SCSI controllers and attaches the devices declared
with -drive if=scsi automatically there).

> My feeling is that since the pattern of a separate header with struct
> and QOM macros (or "modern" style) is used throughout the rest of the
> codebase, why should we make an exception for this one particular case?

I don't mind too much, so if you post your series again, I won't object
again. But still, even if it's a little bit more work for you now, if we
reconsider in a couple of years that information hiding would be a good
idea, it very likely way more work to make the struct private again, so
I'd really prefer if you could keep it private now if possible.

 Thomas

  reply	other threads:[~2018-09-07  6:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06  5:57 [Qemu-devel] [PATCH 0/3] scsi: remove lsi53c895a_create() and lsi53c810_create() functions Mark Cave-Ayland
2018-09-06  5:57 ` [Qemu-devel] [PATCH 1/3] scsi: move lsi53c895a structures and defines into separate lsi53c895a.h file Mark Cave-Ayland
2018-09-06 11:52   ` Thomas Huth
2018-09-06 16:20     ` Mark Cave-Ayland
2018-09-06  5:57 ` [Qemu-devel] [PATCH 2/3] scsi: move lsi53c895a_create() and lsi53c810_create() callers to pci_create_simple() Mark Cave-Ayland
2018-09-06  5:57 ` [Qemu-devel] [PATCH 3/3] scsi: remove unused lsi53c895a_create() and lsi53c810_create() functions Mark Cave-Ayland
2018-09-06 12:02 ` [Qemu-devel] [PATCH 0/3] scsi: remove " Thomas Huth
2018-09-06 14:50   ` Peter Maydell
2018-09-06 16:40     ` Thomas Huth
2018-09-06 17:02       ` Peter Maydell
2018-09-06 17:15       ` Mark Cave-Ayland
2018-09-07  6:27         ` Thomas Huth [this message]
2018-09-07 12:34           ` Mark Cave-Ayland

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=4fa06493-e79b-79f2-ba7c-920de9dc51b2@redhat.com \
    --to=thuth@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=hpoussin@reactos.org \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /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).