From: Huang Ying <ying.huang@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Joe Perches <joe@perches.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 2/2] Use unified UUID/GUID definition in gfs2
Date: Tue, 03 Nov 2009 08:44:48 +0800 [thread overview]
Message-ID: <1257209088.30470.1171.camel@yhuang-dev.sh.intel.com> (raw)
In-Reply-To: <20091102150221.948d8427.akpm@linux-foundation.org>
On Tue, 2009-11-03 at 07:02 +0800, Andrew Morton wrote:
> On Mon, 02 Nov 2009 08:59:43 +0800
> Huang Ying <ying.huang@intel.com> wrote:
>
> > On Mon, 2009-11-02 at 01:35 +0800, Andrew Morton wrote:
> > > On Wed, 14 Oct 2009 14:30:07 +0800 Huang Ying <ying.huang@intel.com> wrote:
> > >
> > > > Replace u8[16] UUID definition in gfs2.
> > > >
> > > > Signed-off-by: Huang Ying <ying.huang@intel.com>
> > > > ---
> > > > fs/gfs2/incore.h | 3 ++-
> > > > fs/gfs2/ops_fstype.c | 2 +-
> > > > fs/gfs2/sys.c | 14 ++++----------
> > > > include/linux/gfs2_ondisk.h | 3 ++-
> > > > 4 files changed, 9 insertions(+), 13 deletions(-)
> > > >
> > > > --- a/fs/gfs2/incore.h
> > > > +++ b/fs/gfs2/incore.h
> > > > @@ -15,6 +15,7 @@
> > > > #include <linux/slow-work.h>
> > > > #include <linux/dlm.h>
> > > > #include <linux/buffer_head.h>
> > > > +#include <linux/uuid.h>
> > > >
> > > > #define DIO_WAIT 0x00000010
> > > > #define DIO_METADATA 0x00000020
> > > > @@ -483,7 +484,7 @@ struct gfs2_sb_host {
> > > >
> > > > char sb_lockproto[GFS2_LOCKNAME_LEN];
> > > > char sb_locktable[GFS2_LOCKNAME_LEN];
> > > > - u8 sb_uuid[16];
> > > > + uuid_be sb_uuid;
> > > > };
> > > >
> > >
> > > Breaks `make headers_check':
> > >
> > > include/linux/gfs2_ondisk.h:14: included file 'linux/uuid.h' is not exported
> > >
> > > I don't think we want to export linux/uuid.h to userspace. But
> > > fs/gfs2/incore.h _is_ shared with userspace, and needs linux/uuid.h.
> >
> > When writing uuid.h, I think it should be exported to userspace. Why
> > should we not export it to user space?
>
> It contains a pile of stuff which is of no use to userspace - functions
> definitions, function declarations, macros, additional linux includes.
>
> If we're going to do this then we need a separate header file which
> contains the userspace-needed things. And we'd need to check that it's
> desirable to use __u8 in userspace headers.
For stuff of no use to user space, I think it can be enclosed into
#ifdef __KERNEL__
#endif
It seems that <linux/types.h> and <linux/string.h> are both safe to be
included in a file exported to user space, because there is appropriate
__KERNEL__ in these files.
In include/asm-generic/int-ll64.h, it is said __xx is intended to be
used to be exported to user space.
Best Regards,
Huang Ying
next prev parent reply other threads:[~2009-11-03 0:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 6:30 Huang Ying
2009-11-01 17:35 ` Andrew Morton
2009-11-02 0:59 ` Huang Ying
2009-11-02 23:02 ` Andrew Morton
2009-11-03 0:44 ` Huang Ying [this message]
2009-11-03 1:02 ` Andrew Morton
2009-11-03 7:21 ` Huang Ying
2009-11-03 10:02 ` Sam Ravnborg
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=1257209088.30470.1171.camel@yhuang-dev.sh.intel.com \
--to=ying.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=swhiteho@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®