All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: laforge@netfilter.org
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] don't use __be16 in files used by userspace
Date: Fri, 07 Oct 2005 13:24:56 -0700 (PDT)	[thread overview]
Message-ID: <20051007.132456.19624093.davem@davemloft.net> (raw)
In-Reply-To: <20051007103105.GF4719@rama>

From: Harald Welte <laforge@netfilter.org>
Date: Fri, 7 Oct 2005 12:31:05 +0200

> This (or a different solution such as 
> "#ifndef __KERNEL__ #define __be16 #endif" needs to go in before 2.6.14
> is released, since otherwise we'd break userspace compilation :(

I'm not applying this.

The reverting of endianness annotations would be a serious
regression.  If we need userland compatible defines we can
either:

1) Do what iproute2 and friends do, which is ship sanitized
   kernel headers in their userland source tree.

2) As you suggest have a suitable __be* et al. define when
   __KERNEL__ is not set.

Actually... What's the problem anyways?  #2 seems to already
be done.

In linux/types.h we have:

#ifdef __CHECKER__
#define __bitwise __attribute__((bitwise))
#else
#define __bitwise
#endif

typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;
#endif

And this should just work.

That isn't even protected by __KERNEL__, it's fully visible to
userspace when you include linux/types.h

  reply	other threads:[~2005-10-07 20:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-07 10:31 [PATCH] don't use __be16 in files used by userspace Harald Welte
2005-10-07 20:24 ` David S. Miller [this message]
2005-10-07 22:15   ` Harald Welte
2005-10-10  4:47     ` David S. Miller

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=20051007.132456.19624093.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=laforge@netfilter.org \
    --cc=netfilter-devel@lists.netfilter.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 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.