2012-07-06 19:50:00 +04:00
<?xml version='1.0'?> <!-- * - nxml - * -->
2019-03-14 16:40:58 +03:00
< !DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
2015-06-18 20:47:44 +03:00
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
2020-11-09 07:23:58 +03:00
<!-- SPDX - License - Identifier: LGPL - 2.1 - or - later -->
2012-07-06 19:50:00 +04:00
2014-02-21 07:39:26 +04:00
<refentry id= "sd-id128"
2015-02-04 05:14:13 +03:00
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo >
<title > sd-id128</title>
<productname > systemd</productname>
</refentryinfo>
<refmeta >
<refentrytitle > sd-id128</refentrytitle>
<manvolnum > 3</manvolnum>
</refmeta>
<refnamediv >
<refname > sd-id128</refname>
2021-04-19 16:33:09 +03:00
<refname > SD_ID128_ALLF</refname>
<refname > SD_ID128_CONST_STR</refname>
<refname > SD_ID128_FORMAT_STR</refname>
<refname > SD_ID128_FORMAT_VAL</refname>
2015-02-04 05:14:13 +03:00
<refname > SD_ID128_MAKE</refname>
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID
Embedding sd_id128_t's in constant strings was rather cumbersome. We had
SD_ID128_CONST_STR which returned a const char[], but it had two problems:
- it wasn't possible to statically concatanate this array with a normal string
- gcc wasn't really able to optimize this, and generated code to perform the
"conversion" at runtime.
Because of this, even our own code in coredumpctl wasn't using
SD_ID128_CONST_STR.
Add a new macro to generate a constant string: SD_ID128_MAKE_STR.
It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition
of the numbers, but in practice it is more convenient to use, and allows gcc
to generate smarter code:
$ size .libs/systemd{,-logind,-journald}{.old,}
text data bss dec hex filename
1265204 149564 4808 1419576 15a938 .libs/systemd.old
1260268 149564 4808 1414640 1595f0 .libs/systemd
246805 13852 209 260866 3fb02 .libs/systemd-logind.old
240973 13852 209 255034 3e43a .libs/systemd-logind
146839 4984 34 151857 25131 .libs/systemd-journald.old
146391 4984 34 151409 24f71 .libs/systemd-journald
It is also much easier to check if a certain binary uses a certain MESSAGE_ID:
$ strings .libs/systemd.old|grep MESSAGE_ID
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
$ strings .libs/systemd|grep MESSAGE_ID
MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27
MESSAGE_ID=b07a249cd024414a82dd00cd181378ff
MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7
MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f
MESSAGE_ID=d34d037fff1847e6ae669a370e694725
MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5
MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7
MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d
MESSAGE_ID=7b05ebc668384222baa8881179cfda54
MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 20:48:23 +03:00
<refname > SD_ID128_MAKE_STR</refname>
2016-08-31 13:23:27 +03:00
<refname > SD_ID128_NULL</refname>
2019-04-05 14:46:33 +03:00
<refname > SD_ID128_UUID_FORMAT_STR</refname>
2015-02-04 05:14:13 +03:00
<refname > sd_id128_equal</refname>
2021-04-19 16:36:10 +03:00
<refname > sd_id128_in_set</refname>
<refname > sd_id128_in_set_sentinel</refname>
<refname > sd_id128_in_setv</refname>
2021-04-19 16:33:09 +03:00
<refname > sd_id128_is_allf</refname>
2016-08-31 13:23:27 +03:00
<refname > sd_id128_is_null</refname>
2021-04-19 16:33:09 +03:00
<refname > sd_id128_t</refname>
2015-02-04 05:14:13 +03:00
<refpurpose > APIs for processing 128-bit IDs</refpurpose>
</refnamediv>
<refsynopsisdiv >
<funcsynopsis >
<funcsynopsisinfo > #include < systemd/sd-id128.h> </funcsynopsisinfo>
</funcsynopsis>
<cmdsynopsis >
<command > pkg-config --cflags --libs libsystemd</command>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1 >
<title > Description</title>
<para > <filename > sd-id128.h</filename> provides APIs to process and
generate 128-bit ID values. The 128-bit ID values processed and
generated by these APIs are a generalization of OSF UUIDs as
defined by <ulink url= "https://tools.ietf.org/html/rfc4122" > RFC
4122</ulink> but use a simpler string format. These functions
impose no structure on the used IDs, much unlike OSF UUIDs or
Microsoft GUIDs, but are fully compatible with those types of IDs.
</para>
<para > See
<citerefentry > <refentrytitle > sd_id128_to_string</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd_id128_randomize</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
and
<citerefentry > <refentrytitle > sd_id128_get_machine</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
for more information about the implemented functions.</para>
<para > A 128-bit ID is implemented as the following
union type:</para>
<programlisting > typedef union sd_id128 {
2021-04-19 16:09:22 +03:00
uint8_t bytes[16];
uint64_t qwords[2];
2012-07-06 19:50:00 +04:00
} sd_id128_t;</programlisting>
2015-02-04 05:14:13 +03:00
<para > This union type allows accessing the 128-bit ID as 16
separate bytes or two 64-bit words. It is generally safer to
access the ID components by their 8-bit array to avoid endianness
issues. This union is intended to be passed call-by-value (as
opposed to call-by-reference) and may be directly manipulated by
clients.</para>
<para > A couple of macros are defined to denote and decode 128-bit
IDs:</para>
<para > <function > SD_ID128_MAKE()</function> may be used to denote a
constant 128-bit ID in source code. A commonly used idiom is to
assign a name to a 128-bit ID using this macro:</para>
<programlisting > #define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)</programlisting>
2021-04-19 16:33:09 +03:00
<para > <constant > SD_ID128_NULL</constant> may be used to refer to the 128-bit ID consisting of only
2020-11-12 10:58:00 +03:00
<constant > NUL</constant> bytes.</para>
2016-08-31 13:23:27 +03:00
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID
Embedding sd_id128_t's in constant strings was rather cumbersome. We had
SD_ID128_CONST_STR which returned a const char[], but it had two problems:
- it wasn't possible to statically concatanate this array with a normal string
- gcc wasn't really able to optimize this, and generated code to perform the
"conversion" at runtime.
Because of this, even our own code in coredumpctl wasn't using
SD_ID128_CONST_STR.
Add a new macro to generate a constant string: SD_ID128_MAKE_STR.
It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition
of the numbers, but in practice it is more convenient to use, and allows gcc
to generate smarter code:
$ size .libs/systemd{,-logind,-journald}{.old,}
text data bss dec hex filename
1265204 149564 4808 1419576 15a938 .libs/systemd.old
1260268 149564 4808 1414640 1595f0 .libs/systemd
246805 13852 209 260866 3fb02 .libs/systemd-logind.old
240973 13852 209 255034 3e43a .libs/systemd-logind
146839 4984 34 151857 25131 .libs/systemd-journald.old
146391 4984 34 151409 24f71 .libs/systemd-journald
It is also much easier to check if a certain binary uses a certain MESSAGE_ID:
$ strings .libs/systemd.old|grep MESSAGE_ID
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
$ strings .libs/systemd|grep MESSAGE_ID
MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27
MESSAGE_ID=b07a249cd024414a82dd00cd181378ff
MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7
MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f
MESSAGE_ID=d34d037fff1847e6ae669a370e694725
MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5
MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7
MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d
MESSAGE_ID=7b05ebc668384222baa8881179cfda54
MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 20:48:23 +03:00
<para > <function > SD_ID128_MAKE_STR()</function> is similar to <function > SD_ID128_MAKE()</function> , but creates a
<type > const char*</type> expression that can be conveniently used in message formats and such:</para>
<programlisting > #include < stdio.h>
#define SD_MESSAGE_COREDUMP_STR SD_ID128_MAKE_STR(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)
int main(int argc, char **argv) {
2021-04-19 16:09:22 +03:00
puts("Match for coredumps: MESSAGE_ID=" SD_MESSAGE_COREDUMP_STR);
tree-wide: add SD_ID128_MAKE_STR, remove LOG_MESSAGE_ID
Embedding sd_id128_t's in constant strings was rather cumbersome. We had
SD_ID128_CONST_STR which returned a const char[], but it had two problems:
- it wasn't possible to statically concatanate this array with a normal string
- gcc wasn't really able to optimize this, and generated code to perform the
"conversion" at runtime.
Because of this, even our own code in coredumpctl wasn't using
SD_ID128_CONST_STR.
Add a new macro to generate a constant string: SD_ID128_MAKE_STR.
It is not as elegant as SD_ID128_CONST_STR, because it requires a repetition
of the numbers, but in practice it is more convenient to use, and allows gcc
to generate smarter code:
$ size .libs/systemd{,-logind,-journald}{.old,}
text data bss dec hex filename
1265204 149564 4808 1419576 15a938 .libs/systemd.old
1260268 149564 4808 1414640 1595f0 .libs/systemd
246805 13852 209 260866 3fb02 .libs/systemd-logind.old
240973 13852 209 255034 3e43a .libs/systemd-logind
146839 4984 34 151857 25131 .libs/systemd-journald.old
146391 4984 34 151409 24f71 .libs/systemd-journald
It is also much easier to check if a certain binary uses a certain MESSAGE_ID:
$ strings .libs/systemd.old|grep MESSAGE_ID
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
MESSAGE_ID=%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x
$ strings .libs/systemd|grep MESSAGE_ID
MESSAGE_ID=c7a787079b354eaaa9e77b371893cd27
MESSAGE_ID=b07a249cd024414a82dd00cd181378ff
MESSAGE_ID=641257651c1b4ec9a8624d7a40a9e1e7
MESSAGE_ID=de5b426a63be47a7b6ac3eaac82e2f6f
MESSAGE_ID=d34d037fff1847e6ae669a370e694725
MESSAGE_ID=7d4958e842da4a758f6c1cdc7b36dcc5
MESSAGE_ID=1dee0369c7fc4736b7099b38ecb46ee7
MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
MESSAGE_ID=be02cf6855d2428ba40df7e9d022f03d
MESSAGE_ID=7b05ebc668384222baa8881179cfda54
MESSAGE_ID=9d1aaa27d60140bd96365438aad20286
2016-11-06 20:48:23 +03:00
}
</programlisting>
2015-02-04 05:14:13 +03:00
<para > <function > SD_ID128_CONST_STR()</function> may be used to
convert constant 128-bit IDs into constant strings for output. The
following example code will output the string
"fc2e22bc6ee647b6b90729ab34a250b1":</para>
<programlisting > int main(int argc, char *argv[]) {
2021-04-19 16:09:22 +03:00
puts("Match for coredumps: %s", SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP));
2012-10-16 19:02:51 +04:00
}</programlisting>
2020-11-10 00:38:36 +03:00
<para > <constant > SD_ID128_FORMAT_STR</constant> and <function > SD_ID128_FORMAT_VAL()</function> may
be used to format a 128-bit ID in a
2015-02-04 05:14:13 +03:00
<citerefentry project= 'man-pages' > <refentrytitle > printf</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry>
format string, as shown in the following example:</para>
<programlisting > int main(int argc, char *argv[]) {
2021-04-19 16:09:22 +03:00
sd_id128_t id;
id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id));
return 0;
2012-07-06 19:50:00 +04:00
}</programlisting>
2020-11-10 00:38:36 +03:00
<para > <constant > SD_ID128_UUID_FORMAT_STR</constant> is similar to
<constant > SD_ID128_FORMAT_STR</constant> but includes separating hyphens to conform to the
2019-04-05 14:46:33 +03:00
"<ulink url= "https://en.wikipedia.org/wiki/Universally_unique_identifier#Format" > canonical representation</ulink> ".
</para>
2015-02-04 05:14:13 +03:00
<para > Use <function > sd_id128_equal()</function> to compare two 128-bit IDs:</para>
2012-07-06 19:50:00 +04:00
2015-02-04 05:14:13 +03:00
<programlisting > int main(int argc, char *argv[]) {
2021-04-19 16:09:22 +03:00
sd_id128_t a, b, c;
a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e);
c = a;
assert(sd_id128_equal(a, c));
assert(!sd_id128_equal(a, b));
return 0;
2016-08-31 13:23:27 +03:00
}</programlisting>
2021-04-19 16:33:09 +03:00
<para > Use <function > sd_id128_is_null()</function> to check if an 128-bit ID consists of only
2020-11-12 10:58:00 +03:00
<constant > NUL</constant> bytes:</para>
2016-08-31 13:23:27 +03:00
2021-04-19 16:33:09 +03:00
<programlisting > assert(sd_id128_is_null(SD_ID128_NULL));</programlisting>
<para > Similarly, use <function > sd_id128_is_allf()</function> to check if an 128-bit ID consists of only
<constant > 0xFF</constant> bytes (all bits on):</para>
<programlisting > assert(sd_id128_is_allf(SD_ID128_ALLF));</programlisting>
2012-07-06 19:50:00 +04:00
2021-04-19 16:36:10 +03:00
<para > For convenience, <function > sd_id128_in_set()</function> takes a list of IDs and
returns true if any are equal to the first argument:</para>
<programlisting > int main(int argc, char *argv[]) {
sd_id12_t a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
assert(sd_id128_in_set(a, a));
assert(sd_id128_in_set(a, a, a));
assert(!sd_id128_in_set(a));
assert(!sd_id128_in_set(a,
SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e)
SD_ID128_MAKE(2f,88,28,5f,9c,44,09,9d,d7,15,77,04,bc,85,7e,e3)
SD_ID128_ALLF));
return 0;
}
</programlisting>
<para > <function > sd_id128_in_set()</function> is defined as a macro over
<function > sd_id128_in_set_sentinel()</function> , adding the <constant > SD_ID128_NULL</constant>
sentinel. Since <function > sd_id128_in_set_sentinel()</function> uses <constant > SD_ID128_NULL</constant>
as the sentinel, <constant > SD_ID128_NULL</constant> cannot be otherwise placed in the argument list.
</para>
<para > <function > sd_id128_in_setv()</function> is similar to
<function > sd_id128_in_set_sentinel()</function> , but takes a <structname > struct varargs</structname>
argument.</para>
2015-02-04 05:14:13 +03:00
<para > Note that new, randomized IDs may be generated with
2018-10-02 17:43:54 +03:00
<citerefentry > <refentrytitle > systemd-id128</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> 's
<command > new</command> command.</para>
2015-02-04 05:14:13 +03:00
</refsect1>
<xi:include href= "libsystemd-pkgconfig.xml" />
<refsect1 >
<title > See Also</title>
<para >
<citerefentry > <refentrytitle > systemd</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd_id128_to_string</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd_id128_randomize</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd_id128_get_machine</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry project= 'man-pages' > <refentrytitle > printf</refentrytitle> <manvolnum > 3</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > journalctl</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > sd-journal</refentrytitle> <manvolnum > 7</manvolnum> </citerefentry> ,
<citerefentry project= 'die-net' > <refentrytitle > pkg-config</refentrytitle> <manvolnum > 1</manvolnum> </citerefentry> ,
<citerefentry > <refentrytitle > machine-id</refentrytitle> <manvolnum > 5</manvolnum> </citerefentry>
</para>
</refsect1>
2012-07-06 19:50:00 +04:00
</refentry>