From: Andrew Morton <akpm@linux-foundation.org>
To: Huang Ying <ying.huang@intel.com>
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: Mon, 2 Nov 2009 15:02:21 -0800 [thread overview]
Message-ID: <20091102150221.948d8427.akpm@linux-foundation.org> (raw)
In-Reply-To: <1257123583.30470.1161.camel@yhuang-dev.sh.intel.com>
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.
And we'll need to wake Steven up to actually take a look at the patches!
next prev parent reply other threads:[~2009-11-02 23:02 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 [this message]
2009-11-03 0:44 ` Huang Ying
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=20091102150221.948d8427.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=swhiteho@redhat.com \
--cc=ying.huang@intel.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®