Re: [RFC 2/2] Use unified UUID/GUID definition in gfs2

[Huang Ying]

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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
> > > 
> > > > Replace u8[16] UUID definition in gfs2.
> > > > 
> > > > Signed-off-by: Huang Ying <ying.huang@xxxxxxxxx>
> > > > ---
> > > >  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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/