illumos gate

libuuid is not the problem, libdlpi (and others) are, as you point out. Fix them, if anything.

Rich Lowe wrote:

libuuid is not the problem, libdlpi (and others) are, as you point out. Fix them, if anything.

I think libuuid should not depend on libdlpi.

The UUID spec requires us to know things that require libdlpi, if I recall correctly.

But look, the root of the problem is is not libuuid! it's not libdlpi!

The real problem library is libdladm, because of the complete misarchitecture of that library.

Here's a much more useful bit of output, for any given library:

$ elfdump -d /lib/libuuid.so.1 |grep NEEDED
       [1]  NEEDED            0x355               libsocket.so.1
       [3]  NEEDED            0x36d               libnsl.so.1
       [4]  NEEDED            0x379               libc.so.1
       [6]  NEEDED            0x3b7               libdlpi.so.1

$ elfdump -d /lib/libdlpi.so.1 |grep NEEDED
       [0]  NEEDED            0x41e               libc.so.1
       [2]  NEEDED            0x447               libinetutil.so.1
       [4]  NEEDED            0x468               libdladm.so.1

$ elfdump -d /lib/libdladm.so.1 |grep NEEDED
       [1]  NEEDED            0x3989              libdevinfo.so.1
       [2]  NEEDED            0x39a2              libc.so.1
       [4]  NEEDED            0x39e8              libinetutil.so.1
       [6]  NEEDED            0x39f9              libsocket.so.1
       [8]  NEEDED            0x3a21              libscf.so.1
      [10]  NEEDED            0x3a2d              librcm.so.1
      [12]  NEEDED            0x3a39              libnvpair.so.1
      [14]  NEEDED            0x3a48              libexacct.so.1
      [16]  NEEDED            0x3a60              libnsl.so.1
      [18]  NEEDED            0x3a75              libkstat.so.1
      [20]  NEEDED            0x3a83              libcurses.so.1
      [22]  NEEDED            0x3a92              libpool.so.1

Yeah, libdladm looks bad.

Maybe try to make libdlapi not depend on libdladm?

libdlpi is probably trying to do "pure" DLPI. Which is actually a pretty evil way of getting MAC addresses... its old STREAMs stuff.

Right now libdlpi is using libdladm to find/iterate over all data link interfaces. It also (bizarrely) uses libdladm to verify that the link is not a style 1 provider. (This is one of the more stupid things I've seen. There is no reason to restrict style 1 -- in fact style 1 interfaces are IMO far preferable to style 2.... style 2 has the old race with dynamic reconfiguration for example.)

Both of those could easily be replaced -- probably with just an hour or so of coding.

But my bigger question is this: why do you care? libdladm (and hence its dependents) are necessary for a regular working system. You can't configure certain types of networking without it. So why would you ever not want to have it on your system?

Actually reading libuuid, it tries to get the ethernet address via arp first. Which is far better.

libdlpi interfaces are only available to root (or users with appropriate rights to access low level devices directly). Whoever thought wiring this in this way was a good idea was nuts.

This is only used in generating version 1 UUIDs. Version 4 work differently.

A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.

Garrett D'Amore wrote:

Actually reading libuuid, ...
...
A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.

please bear in mind that there a still a number of pre, or non compliant, SMBIOS 2.3 X86 systems out there

~$ smbios 
smbios: failed to load SMBIOS: System does not export an SMBIOS table

BTW, the pkgsrc version of libuuid (which I believe is base upon linux libuuid) has these dependencies:

richard@devzone:~/src/pkgsrc/devel/libuuid$ ldd -d /opt/pkg/lib/libuuid.so
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libgcc_s.so.1 =>         /opt/pkg/gcc47/lib/amd64/libgcc_s.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libm.so.2 =>     /lib/64/libm.so.2

> A probably better way to generate these would be to take the SMBIOS UUID information, and parse out the ethernet/MAC address from it. This is just copying certain bytes from the SMBIOS UUID. On SPARC we can't use SMBIOS, but could instead use the hostid which is pretty much guaranteed to be unique without having to resort to grunging through all mac addresses.

You shouldn't use smbios on x86 either. A pretty large number of systems have badly implemented SMBIOS with non-unique UUIDs (and wide, and varied, further amounts of breakage).

-- Rich

Actually, there's a much, much simpler way to fix this, which is to use code like almost all the other libuuid implementations do, using ioctl calls to get the list of interfaces and the h/w address for each. For example, this code:
https://github.com/cloudbase/libuuid/blob/master/gen_uuid.c

There's really no need to link with libdlpi, and no need to get fancy trying to get a unique system ID.
See the comments in get_ethernet_address about why it's OK for that to fail.