path: root/sys/sys/uuid.h
Commit message (Collapse)AuthorAgeFilesLines
* validate_uuid: absorb the rest of parse_uuid with a flags argKyle Evans2020-04-151-12/+10
| | | | | | | | | | This makes the naming annoyance (validate_uuid vs. parse_uuid) less of an issue and centralizes all of the functionality into the new KPI while still making the extra validation optional. The end-result is all the same as far as hostuuid validation-only goes. Notes: svn path=/head/; revision=359980
* kern uuid: break format validation out into a separate KPIKyle Evans2020-04-151-0/+15
| | | | | | | | | | | | | | | | | | | This new KPI, validate_uuid, strictly validates the formatting of the input UUID and, optionally, populates a given struct uuid. As noted in the header, the key differences are that the new KPI won't recognize an empty string as a nil UUID and it won't do any kind of semantic validation on it. Also key is that populating a struct uuid is optional, so the caller doesn't necessarily need to allocate a bogus one on the stack just to validate the string. This KPI has specifically been broken out in support of D24288, which will preload /etc/hostid in loader so that early boot hostuuid users (e.g. anything that calls ether_gen_addr) can have a valid hostuuid to work with once it's been stashed in /etc/hostid. Notes: svn path=/head/; revision=359953
* sys/sys: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-271-0/+2
| | | | | | | | | | | | | | | Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Notes: svn path=/head/; revision=326256
* Add a helper function for comparing struct uuids.Mark Johnston2017-06-121-0/+1
| | | | | | | | | Submitted by: Domagoj Stolfa <domagoj.stolfa@gmail.com> MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D11138 Notes: svn path=/head/; revision=319868
* Decouple the UUID generator from network interfaces by having MACMarcel Moolenaar2013-07-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | addresses added to the UUID generator using uuid_ether_add(). The UUID generator keeps an arbitrary number of MAC addresses, under the assumption that they are rarely removed (= uuid_ether_del()). This achieves the following: 1. It brings up closer to having the network stack as a loadable module. 2. It allows the UUID generator to filter MAC addresses for best results (= highest chance of uniqeness). 3. MAC addresses can come from anywhere, irrespactive of whether it's used for an interface or not. A side-effect of the change is that when no MAC addresses have been added, a random multicast MAC address is created once and re-used if needed. Previusly, when a random MAC address was needed, it was created for every call. Thus, a change in behaviour is introduced for when no MAC addresses exist. Obtained from: Juniper Networks, Inc. Notes: svn path=/head/; revision=253590
* Add parse_uuid() that creates a binary representation of an UUID fromMarcel Moolenaar2005-10-071-0/+2
| | | | | | | a string representation. Notes: svn path=/head/; revision=151059
* Move the UUID generator into its own function, called kern_uuidgen(),Marcel Moolenaar2005-09-181-0/+2
| | | | | | | | | so that UUIDs can be generated from within the kernel. The uuidgen(2) syscall now allocates kernel memory, calls the generator, and does a copyout() for the whole UUID store. This change is in support of GPT. Notes: svn path=/head/; revision=150303
* /* -> /*- for license, minor formatting changesWarner Losh2005-01-071-1/+1
| | | | Notes: svn path=/head/; revision=139825
* Introduce {be,le}_uuid_{enc,dec}() functions for explicitly encodingPoul-Henning Kamp2003-05-311-0/+4
| | | | | | | and decoding UUID's in big endian and little endian binary format. Notes: svn path=/head/; revision=115459
* Wrap function prototype declarations in __BEGIN_DECLS to do the right thingJuli Mallett2002-11-051-0/+4
| | | | | | | | | | | | with them in non-C cases, outside of the kernel. Include <sys/cdefs.h> for __BEGIN_DECLS/__END_DECLS as other headers seem to do in this area. Requested by: Patrick Hartling <patrick@137.org> Notes: svn path=/head/; revision=106454
* Add uuidgen(2) and uuidgen(1).Marcel Moolenaar2002-05-281-0/+70
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. Notes: svn path=/head/; revision=97372