Date: Fri, 25 Oct 2002 20:47:29 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: freebsd-arch@FreeBSD.org Cc: hiten@uk.FreeBSD.org Subject: RFC: DCE 1.1 compatible UUID support functions in libc Message-ID: <20021026034729.GA15295@athlon.pn.xcllnt.net>
next in thread | raw e-mail | index | archive | help
[Rather long] Gang, In order to support immediate and future work, I'd like to commit the set of DCE 1.1 compatible UUID functions. For the impatient: http://www.xcllnt.net/~marcel/uuid.patch Credits: This work is mostly a joint effort between Hiten Pandya and me. Although I don't think we'd have a manpage without him :-) Rationale: UUIDs, or maybe better known as GUIDs, are playing an ever increasing role in hardware and software. It's hip, I guess :-) The source tree has two ia64 specific tools that need to operate on UUIDs, of which the GPT tool probably is a good one to mention given the lively discussion on partitioning and naming. Other people, among which Hiten, greatly benefit from heving the functions present for their porting work. Implementation decisions: One of the biggest problems with UUIDs from an implementation point of view is that they are ripped from their RPC context. This makes it impossible to be truely DCE 1.1 compliant. In this version, we had to address the following problems: 1. Where to put the functions? Multiple vendors have DCE implementations and they all seem to disagree in little things. But all of them share the fact that the UUID functions are part of the complete RPC implementation. This means that one needs to include <dce/uuid.h> and link with -ldce. For functions that havea high level of core visibility, this didn't seem right. SGI has implemented the functions in libc and Linux has put them in libuuid. On SGI one needs to include <sys/uuid.h>; on Linux <uuid/uuid.h> We decided that putting the functions in libc would not prohibit a full RPC implementation to work by including -ldce without some weird UUID specific library. We already have <sys/uuid.h>, but we decided that <uuid.h> would better seperate userland from kernelland. Since uuid.h includes <sys/uuid.h>, we can freely move definitions and prototypes from one land to the other without causing breakages. A full DCE implementation can always provide a dummy <dce/uuid.h> that includes <uuid.h>. 2. What to do with the silly status argument? The specification is typical. It's so typical that there's a strong desire to make its use more common. Hence, we decided that we would not make the status argument mandatory by allowing a NULL pointer to be passed. The only function that returns a status other than "uuid_s_ok", is uuid_from_string(). Compliant code will not make use of this feature. 3. We don't have a rpc_string_free() function. uuid_to_string() allocates the memory required for the string representation of an UUID. The specification states that this memory should be freed after use by calling rpc_string_free(). We decided that there's no problem. Any non-DCE code uses free() and as long as rpc_string_free() can be replaced with free(), nothing is broken. Review notes: 1. The manpage The manpage included in the patch is not the final version. Hiten is revising it currently. 2. src/lib/libc/Makefile.inc Not part of the big patch, but the one-liner required there is: Index: Makefile.inc =================================================================== RCS file: /home/ncvs/src/lib/libc/Makefile.inc,v retrieving revision 1.8 diff -u -r1.8 Makefile.inc --- Makefile.inc 15 May 2002 20:07:31 -0000 1.8 +++ Makefile.inc 20 Oct 2002 09:28:05 -0000 @@ -37,6 +37,7 @@ .include "${.CURDIR}/../libc/string/Makefile.inc" .include "${.CURDIR}/../libc/sys/Makefile.inc" .include "${.CURDIR}/../libc/rpc/Makefile.inc" +.include "${.CURDIR}/../libc/uuid/Makefile.inc" .include "${.CURDIR}/../libc/xdr/Makefile.inc" .if !defined(NO_YP_LIBC) CFLAGS+= -DYP So, let us know the verdict! -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021026034729.GA15295>