From owner-freebsd-arch Fri Oct 25 20:47:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D8837B401 for ; Fri, 25 Oct 2002 20:47:46 -0700 (PDT) Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F17F43E3B for ; Fri, 25 Oct 2002 20:47:45 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q3lU0N062583; Fri, 25 Oct 2002 20:47:30 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id g9Q3lUAS015399; Fri, 25 Oct 2002 20:47:30 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.6/8.12.6/Submit) id g9Q3lTmE015398; Fri, 25 Oct 2002 20:47:29 -0700 (PDT) Date: Fri, 25 Oct 2002 20:47:29 -0700 From: Marcel Moolenaar 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [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 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 ; on Linux 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 , but we decided that would better seperate userland from kernelland. Since uuid.h includes , 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 that includes . 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