qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch] add byteordered types


From: Jamie Lokier
Subject: Re: [Qemu-devel] [patch] add byteordered types
Date: Wed, 27 Aug 2008 19:19:14 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Gerd Hoffmann wrote:
> Anthony Liguori wrote:
> > Personally, I dislike the whole struct thing.  I even further dislike
> > having multiple sets of conversion functions that are used in different
> > places in the code.
> > 
> > Are we sure that this is something that we want to do?
> 
> As far I know this struct trick is the only way to have gcc check access
> to variables with an specific byteorder is done the correct way.  Avi
> sguuested that and I also think this checking would be useful.  I could
> live without that though if there is an agreement that we'll just stick
> with the current, unchecked cpu_to_<order><size> functions.

Provided you always use the type, and want access only via the macros,
the fact its a struct is pretty much invisible, and modern compilers
optimise them quite well like integers.

I'm not sure if a "long enum le32 { max = LONG_MAX, min = LONG_MIN }"
can be used instead of a struct (same for other "short enum" etc.), to
get some warnings instead of errors, and allow bitwise operations.

Changing in steps would work:

   1. Change all QEMU source to use the new type names (as integers),
      while continuing to use the cpu_to_XY and XY_to_cpu functions.

      Doesn't have to be all at once.

      It's probably not that much work to change all the mainline source,
      as you can use the type-safe version to catch all places that
      need changing :-)

      Let it settle for a while, until contributors start using
      the new type names in patches.

   2. _Then_ change those types to structs and make the functions type-safe.
      A small patch.

   3. Fix the few that got missed.

That's less invasive than changing the function names everywhere.

-- Jamie




reply via email to

[Prev in Thread] Current Thread [Next in Thread]