From: Christoph Hellwig <hch@lst.de>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.
Date: Thu, 2 Oct 2008 14:55:26 +0200 [thread overview]
Message-ID: <20081002125526.GA6552@lst.de> (raw)
In-Reply-To: <48E4C2B1.7010108@redhat.com>
On Thu, Oct 02, 2008 at 02:46:41PM +0200, Gerd Hoffmann wrote:
> Christoph Hellwig wrote:
>
> >> +typedef uint16_t le16;
> >> +typedef uint32_t le32;
> >> +typedef uint64_t le64;
> >> +typedef uint16_t be16;
> >> +typedef uint32_t be32;
> >> +typedef uint64_t be64;
> >
> > Any chance you could add sparse __bitwise__ declarations so one could
> > use spare to check for using these types correctly?
>
> Is there any good documentation on that?
I don't think so. But I've recently added support for it in the XFS
userspace tools, so I have some experience.
>
> Looking at the linux kernel sources I find the bitwise stuff depend on
> the __CHECKER__ and __CHECK_ENDIAN__ defines. I can't find references
> to these in the sparse man page and sparse FAQ (sparse 0.4.1 as shipped
> by fedora 9).
>
> I can somehow guess what these two defines do. __CHECKER__ probably is
> set by sparse, and __CHECK_ENDIAN__ by the -Wbitwise switch. But I
> can't see any obvious reason why include/linux/types.h defines both
> __bitwise__ and __bitwise. I'd simply use something along the lines ...
Actually __CHECKER__ is set by sparse. __CHECK_ENDIAN__ is set on the
make command line when checking for endianess bugs. For xfsprogs I
defined the bitwise annotations unconditionally because we made sure
to not have any of this warnings left (this was quite easy becaus a lot
of the code came from the kernel and was already properly annotated)
These are the snipplets from xfsprogs that would be useful for qemu:
#ifdef __CHECKER__
#define __bitwise __attribute__((bitwise))
#define __force __attribute__((force))
#else
#define __bitwise
#define __force
#endif
The __force is needed for the actual swab macros to turn the __bitwise
annotated type back into the normal so it doesn't warn. For XFS these
conversion macros looks the same as the kernel ones:
#ifdef XFS_NATIVE_HOST
#define cpu_to_be16(val) ((__force __be16)(__u16)(val))
#define cpu_to_be32(val) ((__force __be32)(__u32)(val))
#define cpu_to_be64(val) ((__force __be64)(__u64)(val))
#define be16_to_cpu(val) ((__force __u16)(__be16)(val))
#define be32_to_cpu(val) ((__force __u32)(__be32)(val))
#define be64_to_cpu(val) ((__force __u64)(__be64)(val))
#else
#define cpu_to_be16(val) ((__force __be16)__swab16((__u16)(val)))
#define cpu_to_be32(val) ((__force __be32)__swab32((__u32)(val)))
#define cpu_to_be64(val) ((__force __be64)__swab64((__u64)(val)))
#define be16_to_cpu(val) (__swab16((__force __u16)(__be16)(val)))
#define be32_to_cpu(val) (__swab32((__force __u32)(__be32)(val)))
#define be64_to_cpu(val) (__swab64((__force __u64)(__be64)(val)))
#endif
and then you define the types as __bitwise:
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __be32;
typedef __u64 __bitwise __be64;
for qemu you'll need slight changes in the names, and also little
endian variants which we don't have in XFS.
Note that the biggest hurdle for xfsprogs was to convince libtool
that cgcc, the gcc wrapper for invoking sparse actually is a C compiler,
but that should be mood for qemu.
Note that sparse will probably complain about a lot of things in
qemu, so you'll have to add a lot -Wno-foo options in addition to
-Wbitwise.
next prev parent reply other threads:[~2008-10-02 12:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 14:12 [Qemu-devel] [PATCH 1/4] add byteordered types to qemu Gerd Hoffmann
2008-10-01 14:12 ` [Qemu-devel] [PATCH 2/4] pci: add config space struct (from qemu-xen) Gerd Hoffmann
2008-10-01 14:12 ` [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices Gerd Hoffmann
2008-10-01 14:12 ` [Qemu-devel] [PATCH 4/4] pci: use pci_config_header in pci.c Gerd Hoffmann
2008-10-01 16:30 ` Anthony Liguori
2008-10-01 19:09 ` Gerd Hoffmann
2008-10-01 19:27 ` Anthony Liguori
2008-10-02 7:56 ` Gerd Hoffmann
2008-10-02 15:52 ` Anthony Liguori
2008-10-06 16:04 ` Gerd Hoffmann
2008-10-02 8:21 ` [Qemu-devel] [PATCH 1/4] add byteordered types to qemu Christoph Hellwig
2008-10-02 12:46 ` Gerd Hoffmann
2008-10-02 12:55 ` Christoph Hellwig [this message]
2008-10-02 13:15 ` Gerd Hoffmann
2008-10-02 13:17 ` Christoph Hellwig
2008-10-02 14:08 ` Gerd Hoffmann
2008-10-02 15:55 ` Anthony Liguori
2008-10-06 16:07 ` Gerd Hoffmann
-- strict thread matches above, loose matches on Subject: below --
2008-09-10 11:45 Gerd Hoffmann
2008-08-28 8:36 Gerd Hoffmann
2008-08-28 20:08 ` Anthony Liguori
2008-08-28 20:33 ` Anthony Liguori
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=20081002125526.GA6552@lst.de \
--to=hch@lst.de \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).