All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Rosato <mjrosato@linux.ibm.com>
To: Jared Rossi <jrossi@linux.ibm.com>,
	Zhuoying Cai <zycai@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org, cohuck@redhat.com,
	"Jason J . Herne" <jjherne@linux.ibm.com>
Subject: Re: [PATCH v2 2/8] hw/s390x/ipl: Fix incorrect PCI IPL block length constant
Date: Tue, 25 Aug 2026 15:26:57 -0400	[thread overview]
Message-ID: <a4ffeab2-82d1-4100-ae25-c00c2d562c7e@linux.ibm.com> (raw)
In-Reply-To: <36b43f47-32d7-4ff0-ad76-2d1ab1df2c7f@linux.ibm.com>


>>>>
>>> Given that, should the #define be sizeof(IplBlockPci) + 24?
>>>
>> If IplBlockPci is likely to expand in the future, it might make sense to
>> derive this value from the structure layout. For example,
>> offsetof(IplParameterBlock, pci) + sizeof(IplBlockPci) could be more
>> accurate. Otherwise, keeping it as a constant like the other definitions
>> seems reasonable as well.
> 
> All of those suggestions would be valid, but I'm leaning toward keeping it
> defined without using sizeof() for the sake of consistency if nothing
> else.  The other IPLB types are already defined as fixed numbers and for
> the IplBlockQemuScsi being used later in this patch series, it actually has
> a minimum value that is less than the sizeof() itself due to the same
> struct
> servicing both PCI and CCW controllers, where the minimum size for CCW is
> less than PCI.
> 
> I can envision several ways to improve the definitions and/or naming
> conventions, but I think it is outside the scope of this series because the
> changes should be uniformly applied to all definitions, not just PCI.

Ehh...  If you already think the other definitions should be fixed then
convention is not a good enough reason to propagate the bad practice to
new code.  Doing the new definition the right way now in this patch is
certainly within the scope of this series.

If we have structures that define the entire 336 bytes, I personally
would much prefer to see that written out with sizeof()s vs a magic
number that coincidentally must line up with the size of one or more
well-defined structures.

As for existing definitions, I agree that is out of scope: you could
follow-up later with one or more patches that cleanup the existing
definitions.

Thanks,
Matt


  reply	other threads:[~2026-08-25 19:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 14:46 [PATCH v2 0/8] s390x: Add support for virtio-scsi-pci boot device jrossi
2026-08-11 14:46 ` [PATCH v2 1/8] pc-bios/s390-ccw: Check if a PCI function is already enabled before trying to enable it jrossi
2026-08-24 17:34   ` Zhuoying Cai
2026-08-26 20:39   ` Eric Farman
2026-08-11 14:46 ` [PATCH v2 2/8] hw/s390x/ipl: Fix incorrect PCI IPL block length constant jrossi
2026-08-24 17:53   ` Zhuoying Cai
2026-08-25 10:29     ` Eric Farman
2026-08-25 16:44       ` Zhuoying Cai
2026-08-25 18:04         ` Jared Rossi
2026-08-25 19:26           ` Matthew Rosato [this message]
2026-08-26 14:40             ` Jared Rossi
2026-08-11 14:46 ` [PATCH v2 3/8] s390x/ipl: Add PCI and bus fields to iplBlockQemuScsi jrossi
2026-08-26 19:35   ` Eric Farman
2026-08-11 14:46 ` [PATCH v2 4/8] pc-bios/s390-ccw: Use bus specific IPL_TYPE directly for scsi IPL jrossi
2026-08-26 20:24   ` Eric Farman
2026-08-11 14:46 ` [PATCH v2 5/8] pc-bios/s390-ccw: Abstract virtio_run() for generic use jrossi
2026-08-26 16:42   ` Zhuoying Cai
2026-08-26 20:29   ` Eric Farman
2026-08-11 14:46 ` [PATCH v2 6/8] pc-bios/s390-ccw: Add support for virtio-scsi-pci IPL jrossi
2026-08-26 21:11   ` Eric Farman
2026-08-27 14:55     ` Jared Rossi
2026-08-11 14:46 ` [PATCH v2 7/8] s390x: Find scsi-pci boot device and build IPLB jrossi
2026-08-11 14:46 ` [PATCH v2 8/8] tests/qtest: Add s390x PCI SCSI fallback test to cdrom-test.c jrossi

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=a4ffeab2-82d1-4100-ae25-c00c2d562c7e@linux.ibm.com \
    --to=mjrosato@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=jrossi@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=zycai@linux.ibm.com \
    /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.