On Sun, Nov 10, 2002 at 04:04:11AM -0800, Maxime Henrion wrote: > 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).
Hmmm. A third header is just too much. I'd much rather we keep it where it is, visible and all, until we have a problem. This will not happen before we have a full libdce implementation I would say. But then things probably get shuffled around anyway. Note: only uuidgen(1) uses uuidgen(2). All other UUID consumers, with obviously the exception of uuid_create(3), use the DCE 1.1 interface. Making uuidgen(2) invisible is not infeasible. However, uuidgen(1) is a well-known command and I think there's benefit to keep uuidgen(2) visible. I don't think it's that unrealistic to speculate on the possible future that uuidgen(2) will be a backend (low-level) interface on more OSes. The best way to speculate is if you help force it :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
