On 08.11.23 17:04, Mark Brown wrote:
On Wed, Nov 08, 2023 at 11:42:40PM +0800, Haixu Cui wrote:
On 11/6/2023 9:33 PM, Mark Brown wrote:
On Tue, Oct 24, 2023 at 08:53:46PM +0800, Haixu Cui wrote:
+ le16 bus_num;
+ le16 chip_select_max_number;
That's a *lot* of potential buses and chip selects...
Here you mean the types of bus_num and chip_select_max_number are "le16"?
Here I use 16 bits because bus_num and num_chipselect in spi_controller
structure are both 16 bits.
Yeah, I think that's more for padding/alignment reasons than anything
else. TBH I wondered if just going for a standard int might be better,
it's the combination of picking a smaller type but one that's relatively
large for the domain.
We cannot use int at interfaces between device and driver in the virtio
world:
- "int" is machine dependent, sizeof may be 2, 4 or 8.
- It is signed which would be new for the virtio specification. Not done
for other devices.
- How are signs represented? 2s complement? Strange machines do not use
2s complement. Good is that most of those strange machines have still
tubes and are by now obsolete.
- The endianess is machine dependent and device and driver may use
internally a different native byte ordering. Strange but this is imaginable.
le16 is a well defined unsigned type with sizeof 2 bytes and endianess
defined as "little endian".
What byte ordering are the multi-byte words in - CPU native or a
particular endianness (eg, wire native)?
Virtio uses little endian. (Some data structures in the RPMB device use
big endian. But this is an exception and there this was done for a good
reason.)
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
