summaryrefslogtreecommitdiffstats
path: root/usr.bin/uuidgen
Commit message (Collapse)AuthorAgeFilesLines
* The uuidgen(1) program is WARNS=6 clean, so flag it as such.mux2003-12-071-1/+1
| | | | Tested on: i386, sparc64
* Erase whitspace at EOL.ru2003-05-221-1/+1
| | | | Approved by: re (blanket)
* Add an -o filename option to have the output written to a file.marcel2003-03-152-6/+22
| | | | | | | This option is present on most uuidgen(1) implementations even though normal file redirection can be used to achieve the same. Submitted by: Hiten Pandya <hiten@unixdaemons.com>
* o Remove $Id$ from copyright; there's $FreeBSD$,marcel2002-11-012-18/+8
| | | | | | | o Remove static function uuid_print(); use uuid_to_string(3) in combination with printf(3) to achieve the same, o Remove unneeded includes, o Add a reference to uuid(3) to the manpage.
* mdoc(7) police: kill hard sentence breaks.ru2002-05-301-3/+5
|
* Add uuidgen(2) and uuidgen(1).marcel2002-05-283-0/+190
The uuidgen command, by means of the uuidgen syscall, generates one or more Universally Unique Identifiers compatible with OSF/DCE 1.1 version 1 UUIDs. From the Perforce logs (change 11995): Round of cleanups: o Give uuidgen() the correct prototype in syscalls.master o Define struct uuid according to DCE 1.1 in sys/uuid.h o Use struct uuid instead of uuid_t. The latter is defined in sys/uuid.h but should not be used in kernel land. o Add snprintf_uuid(), printf_uuid() and sbuf_printf_uuid() to kern_uuid.c for use in the kernel (currently geom_gpt.c). o Rename the non-standard struct uuid in kern/kern_uuid.c to struct uuid_private and give it a slightly better definition for better byte-order handling. See below. o In sys/gpt.h, fix the broken uuid definitions to match the now compliant struct uuid definition. See below. o In usr.bin/uuidgen/uuidgen.c catch up with struct uuid change. A note about byte-order: The standard failed to provide a non-conflicting and unambiguous definition for the binary representation. My initial implementation always wrote the timestamp as a 64-bit little-endian (2s-complement) integral. The clock sequence was always written as a 16-bit big-endian (2s-complement) integral. After a good nights sleep and couple of Pan Galactic Gargle Blasters (not necessarily in that order :-) I reread the spec and came to the conclusion that the time fields are always written in the native by order, provided the the low, mid and hi chopping still occurs. The spec mentions that you "might need to swap bytes if you talk to a machine that has a different byte-order". The clock sequence is always written in big-endian order (as is the IEEE 802 address) because its division is resulting in bytes, making the ordering unambiguous.
OpenPOWER on IntegriCloud