As part of an upcoming 40p patchset I have a requirement to change the PCI
configuration of the LSI SCSI. However since commits a64aa5785d "hw: Deprecate -drive
if=scsi with non-onboard HBAs" and b891538e81 "hw/ppc/prep: Fix implicit creation of
"-drive if=scsi", the lsi53c8*_create() wrapper functions don't return the device
state itself.

Rather than altering these functions to return PCIDevice I simply went ahead and split
the LSIState structure and QOM types into a new lsi53c895a.h file, as is fairly
standard QEMU practice.

Not only does this enable me to change the PCI configuration of the LSI SCSI device
in an upcoming patchset, but it also allows full access to LSIState if required
(which is fairly similar to how the code was arranged before a64aa5785d).

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


Mark Cave-Ayland (3):
  scsi: move lsi53c895a structures and defines into separate
    lsi53c895a.h file
  scsi: move lsi53c895a_create() and lsi53c810_create() callers to
    pci_create_simple()
  scsi: remove unused lsi53c895a_create() and lsi53c810_create()
    functions

 hw/arm/realview.c            |   5 +-
 hw/arm/versatilepb.c         |   5 +-
 hw/hppa/machine.c            |   5 +-
 hw/ppc/prep.c                |   6 +-
 hw/scsi/lsi53c895a.c         | 130 +---------------------------------------
 include/hw/pci/pci.h         |   3 -
 include/hw/scsi/lsi53c895a.h | 137 +++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 155 insertions(+), 136 deletions(-)
 create mode 100644 include/hw/scsi/lsi53c895a.h

-- 
2.11.0

On 2018-09-06 07:57, Mark Cave-Ayland wrote:
> As part of an upcoming 40p patchset I have a requirement to change the PCI
> configuration of the LSI SCSI. However since commits a64aa5785d "hw: Deprecate -drive
> if=scsi with non-onboard HBAs" and b891538e81 "hw/ppc/prep: Fix implicit creation of
> "-drive if=scsi", the lsi53c8*_create() wrapper functions don't return the device
> state itself.
> 
> Rather than altering these functions to return PCIDevice I simply went ahead and split
> the LSIState structure and QOM types into a new lsi53c895a.h file, as is fairly
> standard QEMU practice.
> 
> Not only does this enable me to change the PCI configuration of the LSI SCSI device
> in an upcoming patchset, but it also allows full access to LSIState if required
> (which is fairly similar to how the code was arranged before a64aa5785d).

I somehow fail to see that something outside of lsi53c895a.c should
really need to access the internals of LSIState. If there is something
that needs to be configured from the outside, it should be done via QOM
properties instead, shouldn't it? So I think I'd rather prefer if you
could do it the other way round and change the lsi*_create() functions
to return a pointer to PCIDevice instead, if possible.

 Thomas

On 6 September 2018 at 13:02, Thomas Huth <thuth@redhat.com> wrote:
> I somehow fail to see that something outside of lsi53c895a.c should
> really need to access the internals of LSIState. If there is something
> that needs to be configured from the outside, it should be done via QOM
> properties instead, shouldn't it? So I think I'd rather prefer if you
> could do it the other way round and change the lsi*_create() functions
> to return a pointer to PCIDevice instead, if possible.

Nothing typically does, but the "modern" style of having QOM objects which
use other QOM objects do so by embedding the child object's struct into
the struct of the parent requires that the struct definition is available.
The only thing of it that is used is (effectively) its size and alignment
requirements.

(I had an RFC patch some years back that would allow you to mark
up the fields of the struct as private, so the struct could be
put in the header but the compiler would complain if you tried
to actually access any of its fields:
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg01846.html )

thanks
-- PMM

On 2018-09-06 16:50, Peter Maydell wrote:
> On 6 September 2018 at 13:02, Thomas Huth <thuth@redhat.com> wrote:
>> I somehow fail to see that something outside of lsi53c895a.c should
>> really need to access the internals of LSIState. If there is something
>> that needs to be configured from the outside, it should be done via QOM
>> properties instead, shouldn't it? So I think I'd rather prefer if you
>> could do it the other way round and change the lsi*_create() functions
>> to return a pointer to PCIDevice instead, if possible.
> 
> Nothing typically does, but the "modern" style of having QOM objects which
> use other QOM objects do so by embedding the child object's struct into
> the struct of the parent requires that the struct definition is available.

But in this case we don't have anything that "inherits" from LSIState,
so shouldn't we rather follow the "information hiding" principle and
keep the state local to the lsi53c895a.c file? If you want to use a
"LSIState *" from another .c file, you can still put an "anonymous"

 struct LSIState;
 typedef struct LSIState LSIState;

in a header somewhere without revealing the implementation.

I'm fine with putting the whole LSIState into a header file if we really
need it, but in this case, I don't see the point.

 Thomas

On 6 September 2018 at 17:40, Thomas Huth <thuth@redhat.com> wrote:
> On 2018-09-06 16:50, Peter Maydell wrote:
>> Nothing typically does, but the "modern" style of having QOM objects which
>> use other QOM objects do so by embedding the child object's struct into
>> the struct of the parent requires that the struct definition is available.
>
> But in this case we don't have anything that "inherits" from LSIState,
> so shouldn't we rather follow the "information hiding" principle and
> keep the state local to the lsi53c895a.c file? If you want to use a
> "LSIState *" from another .c file, you can still put an "anonymous"
>
>  struct LSIState;
>  typedef struct LSIState LSIState;

This doesn't work for

typedef struct MySoC {
   MyUART uart;
   LSIState scsi;
   ...
} MySoC;

This isn't inheritance, it's just use ("has-a", not "is-a").

> in a header somewhere without revealing the implementation.
>
> I'm fine with putting the whole LSIState into a header file if we really
> need it, but in this case, I don't see the point.

Looking at the rest of the series there doesn't seem to be
any code that wants to do use-by-embedding, so we can
certainly postpone moving the struct into the header file
until we need it.

thanks
-- PMM

On 06/09/18 17:40, Thomas Huth wrote:

> On 2018-09-06 16:50, Peter Maydell wrote:
>> On 6 September 2018 at 13:02, Thomas Huth <thuth@redhat.com> wrote:
>>> I somehow fail to see that something outside of lsi53c895a.c should
>>> really need to access the internals of LSIState. If there is something
>>> that needs to be configured from the outside, it should be done via QOM
>>> properties instead, shouldn't it? So I think I'd rather prefer if you
>>> could do it the other way round and change the lsi*_create() functions
>>> to return a pointer to PCIDevice instead, if possible.
>>
>> Nothing typically does, but the "modern" style of having QOM objects which
>> use other QOM objects do so by embedding the child object's struct into
>> the struct of the parent requires that the struct definition is available.
> 
> But in this case we don't have anything that "inherits" from LSIState,
> so shouldn't we rather follow the "information hiding" principle and
> keep the state local to the lsi53c895a.c file? If you want to use a
> "LSIState *" from another .c file, you can still put an "anonymous"
> 
>  struct LSIState;
>  typedef struct LSIState LSIState;
> 
> in a header somewhere without revealing the implementation.
> 
> I'm fine with putting the whole LSIState into a header file if we really
> need it, but in this case, I don't see the point.

I completely agree with you that struct members used to configure the
device initialisation should only be done via qdev properties, however
having the struct information and the QOM defines available is very,
very handy.

In terms of information hiding we are a long way away from this, and in
my experience having both the compile time and runtime checks on QOM
macros means that just doing a FOO(pci_create_simple...) or strongly
typing object links when wiring up a board catches just about all errors
developers can make.

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.

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 see Peter also mentions about marking members as public/private, but
again in my opinion and experience, with the addition of runtime as well
as compile time QOM casts a huge class of problems has now gone away -
and as a result of this, there are now more urgent problems which is
probably why no-one has really picked up Peter's patch in over 4 years.


ATB,

Mark.

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

On 07/09/18 07:27, Thomas Huth wrote:

> 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.

Well your modified function above certainly fixes my particular use case
- I'm just in the process of testing a v2 patchset that implements this
approach which I hope to post shortly.

At the end of the day I suspect that regardless of what is finally
committed, it won't really matter that much given the enormity of the
task to change the way that structs and scope are handled throughout the
codebase. So I'm happy either way :)


ATB,

Mark.