system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-07-22 18:56:38 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
freebsd-src/lib/libsys/uuidgen.2

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

141 lines
5 KiB
Groff
Raw Normal View History

Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.\" Copyright (c) 2002 Marcel Moolenaar
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\"
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.\"
.Dd May 26, 2002
.Dt UUIDGEN 2
.Os
.Sh NAME
.Nm uuidgen
.Nd generate universally unique identifiers
.Sh LIBRARY
.Lb libc
.Sh SYNOPSIS
.In sys/uuid.h
.Ft int
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
.Fn uuidgen "struct uuid *store" "int count"
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.Sh DESCRIPTION
The
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
system call generates
.Fa count
universally unique identifiers (UUIDs) and writes them to the buffer
pointed to by
.Fa store .
The identifiers are generated according to the syntax and semantics of the
mdoc(7) police: kill hard sentence break.
2002-05-30 12:04:36 +00:00
DCE version 1 variant of universally unique identifiers.
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
See below for a more in-depth description of the identifiers.
mdoc(7) police: kill hard sentence break.
2002-05-30 12:04:36 +00:00
When no IEEE 802
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
address is available for the node field, a random multicast address is
generated for each invocation of the system call.
According to the algorithm of generating time-based UUIDs, this will also
Fix all the spelling mistakes I could find in the man pages for words that have at least 3 characters. MFC after: 1 week Thanks to: Music band ``Chingon'' for keeping me company while searching for these.
2005-07-31 03:30:48 +00:00
force a new random clock sequence, thereby increasing the likelihood for
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
the identifier to be unique.
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.Pp
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
When multiple identifiers are to be generated, the
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
system call will generate a set of identifiers that is dense in such a way
that there is no identifier that is larger than the smallest identifier in the
set and smaller than the largest identifier in the set and that is not already
in the set.
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.Pp
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
Universally unique identifiers, also known as globally unique identifiers
(GUIDs), have a binary representation of 128-bits.
The grouping and meaning of these bits is described by the following
structure and its description of the fields that follow it:
.Bd -literal
struct uuid {
uint32_t time_low;
uint16_t time_mid;
uint16_t time_hi_and_version;
uint8_t clock_seq_hi_and_reserved;
uint8_t clock_seq_low;
uint8_t node[_UUID_NODE_LEN];
};
.Ed
mdoc(7) police: formatting nits. Approved by: re
2002-11-29 15:57:50 +00:00
.Bl -tag -width ".Va clock_seq_hi_and_reserved"
.It Va time_low
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The least significant 32 bits of a 60-bit timestamp.
This field is stored in the native byte-order.
mdoc(7) police: formatting nits. Approved by: re
2002-11-29 15:57:50 +00:00
.It Va time_mid
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The least significant 16 bits of the most significant 28 bits of the 60-bit
timestamp.
This field is stored in the native byte-order.
Correct a misspelled name of time_hi_and_version.
2003-06-27 13:41:29 +00:00
.It Va time_hi_and_version
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The most significant 12 bits of the 60-bit timestamp multiplexed with a 4-bit
version number.
The version number is stored in the most significant 4 bits of the 16-bit
field.
This field is stored in the native byte-order.
mdoc(7) police: formatting nits. Approved by: re
2002-11-29 15:57:50 +00:00
.It Va clock_seq_hi_and_reserved
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The most significant 6 bits of a 14-bit sequence number multiplexed with a
2-bit variant value.
Note that the width of the variant value is determined by the variant itself.
Identifiers generated by the
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
system call have variant value 10b.
the variant value is stored in the most significant bits of the field.
mdoc(7) police: formatting nits. Approved by: re
2002-11-29 15:57:50 +00:00
.It Va clock_seq_low
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The least significant 8 bits of a 14-bit sequence number.
mdoc(7) police: formatting nits. Approved by: re
2002-11-29 15:57:50 +00:00
.It Va node
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
The 6-byte IEEE 802 (MAC) address of one of the interfaces of the node.
If no such interface exists, a random multi-cast address is used instead.
.El
.Pp
The binary representation is sensitive to byte ordering.
Any multi-byte field is to be stored in the local or native byte-order and
identifiers must be converted when transmitted to hosts that do not agree
on the byte-order.
The specification does not however document what this means in concrete
terms and is otherwise beyond the scope of this system call.
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.Sh RETURN VALUES
.Rv -std
.Sh ERRORS
The
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
system call can fail with:
.Bl -tag -width Er
.It Bq Er EFAULT
The buffer pointed to by
.Fa store
could not be written to for any or all identifiers.
.It Bq Er EINVAL
The
.Fa count
mdoc(7) police: "The .Fa argument.".
2002-12-19 09:40:28 +00:00
argument is less than 1 or larger than the hard upper limit of 2048.
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.El
.Sh SEE ALSO
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
.Xr uuidgen 1 ,
.Xr uuid 3
.Sh STANDARDS
The identifiers are represented and generated in conformance with the DCE 1.1
RPC specification.
The
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Given that we have 3 places to document UUID related information, namely uuidgen(1), uuidgen(2) and uuid(3), the following division has been choosen: uuidgen(1) A description of the command line utility, and other user oriented UUID information. uuidgen(2) A mostly technical description of UUIDs. uuid(3) A description of the functions and other programmer oriented UUID information. According to the division: add more technical contents. Contributed by: Hiten Pandya <hiten@uk.FreeBSD.org> Edited and enhanced: marcel
2002-11-11 00:29:01 +00:00
system call is itself not part of the specification.
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
.Sh HISTORY
The
mdoc(7) police: Tidy up the syscall language. Stop calling system calls "function calls". Use "The .Fn system call" a-la "The .Nm utility". When referring to a non-BSD implementation in the HISTORY section, call syscall a function, to be safe.
2002-12-18 09:22:32 +00:00
.Fn uuidgen
Add uuidgen(2) and uuidgen(1). 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.
2002-05-28 06:16:08 +00:00
system call first appeared in
.Fx 5.0 .
Reference in a new issue Copy permalink