Marcel Moolenaar wrote: > On Tue, Nov 05, 2002 at 03:46:24PM -0800, Maxime Henrion wrote: > [snip] > > > > That's arguably bad, sys/uuid.h shouldn't have any !_KERNEL prototypes > > > > in it. > > > > > > If there's a better place, then we should move it. We could put it in > > > <uuid.h>, but I don't want to make that header a requirement if one > > > only uses the syscall. I don't yet know what a good place would be, > > > if not <sys/uuid.h>. Suggestions? > > > > Well I don't really understand what you mean here. > > I'm not sure I like uuidgen(2) in <uuid.h>. <uuid.h> is the DCE 1.1 > compliant interface to UUIDs. <sys/uuid.h> describes the underlying > generic interface on which <uuid.h> builds. It feels wrong to mix > them... > > > Since this prototype > > is #ifndef _KERNEL in sys/sys/uuid.h and since this header is included by > > lib/libc/uuid/uuid.h, moving it into the libc header shouldn't make any > > difference both in visibility and header requirements. > > There is no difference when <uuid.h> was included already. There is > a difference when only <sys/uuid.h> was included before. One cannot > use uuidgen(2) without also including the DCE 1.1 compliant stuff.
What about having uuidgen(2) in sys/uuid.h, but hidden by a _UIDGEN_VISIBLE macro ? That's not very elegant but it will help not polluting the DCE 1.1 namespace with the syscall and let applications which need it (gpt and uuidgen IIRC) have it declared. Of course, we could also have a third header just for uuidgen(2). Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
