3087 libuuid has a lot of dependencies

Review Request #2434 — Created Nov. 4, 2019 and updated

Information
gwr
illumos-gate
3087
Reviewers
general 
3087 libuuid has a lot of dependencies


The "get my ARP entry" method is fragile (depends on hostname resolving to an external IP address) and not worth the trouble.  We can do just as well (and arguably better) by doing like most other libuuid implementations do and just use ioctl SIOCGIFCONF, SIOCGIFHWADDR (or similar).
Ran uuidgen as both root and a regular user, and examined truss outputs.
gwr
gwr
Review request changed

Change Summary:

Update the copyright.

Diff:

Revision 2 (+79 -116)

Show changes

usr/src/lib/libuuid/Makefile.com
usr/src/lib/libuuid/common/etheraddr.h
usr/src/lib/libuuid/common/etheraddr.c
mscheler
mscheler 
  1. Looks functionally correct
    

    Do I assume correctly (because of the license change) that you are incorporating an upstream change? Otherwise there are varios CStyle violation which should be fixed.
    1. Also, you may need a LICENSE file in this directory now as well if you're changing/reverting the license.
    2. I took code from https://github.com/cloudbase/libuuid/blob/master/gen_uuid.c
      
(as noted in the issue notes) and none of the old code remained after the change.
      
This is BSD 3-clause style.  Do we need THIRDPARTYLICENCE stuff for that?  I forget.
    3. Yes.
  2. 
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




rm




   

   





  

 



 

  


   

   

    
 
rm


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Have you tested this in cases where you don't have an IP interface plumbed at all? I suspect that this will cause a regression where by an interface that was not plumbed with IP (which can be common), will no longer have its MAC address discovered, where as it would have with the dlpi_walk() and the dlpi_get_physaddr() call.
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      Is there a functional system that has no interfaces plumbed?
      
If you could describe the configuration to test, I'll try it.
      

      Also remember that function IS allowed to fail.
      
 
      

      2. 



    2. 
 
 
      
 
      
  
 
      
 
      
  
      Yes, just set up a zone that only has loopback and zlogin.
      
 
      

      3. 



    3. 
 
 
      
 
      
  
 
      
 
      
  
      I should add, this will also be true at various points in time during the installer, etc. If it fails, it fills it with random numbers. Which, while a good fallback makes a v1 UUID kind of pointless.
      
 
      

      4. 



    4. 
 
 
      
 
      
  
 
      
 
      
  
      Yeah, if your only plumbed interface is lo0 then this uses random numbers.
      
If you consider that a show-stopper here, then probably the only path away
      
from the libdlpi quagmire is to implement a uuidgen system call...
      
Unfortunately I don't think I can take that on right now.
      
 
      

      5. 



    5. 
 
 
      
 
      
  
 
      
 
      
  
      Also remember that both methods of getting the ethernet address (DLPI, ioctl) fail if you're not root or privileged.
      
That's another thing that a syscall version of all this could improve upon.
      
 
      

      6. 



    6. 
 
 
      
 
      
  
 
      
 
      
  
      So, it seems like half dozen of one, half dozen of the other. Not being able to get information if your root, is definitely a pain. The other case seems kind of problematic as well to me, though it's more limited and probably less likely to use v1 UUIDs (I hope). I guess I don't see why using libdlpi in and of itself is a bad thing (which really isn't commentary on the ARP resolution path which has problems as you point out).
      

      Probably the system call like thing (or ioctl on a device) is a better path in the long run, but I guess the tradeoff of functionality is probably OK?
      
 
      

      7. 



    7. 
 
 
      
 
      
  
 
      
 
      
  
      Maybe it's better to just leave this alone until someone has time to implement a syscall to replace the libdlpi gunk.
      
 
      

      8. 


 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 









     

    

   

  

  

   
   Loading...