Peter Memishian wrote: > > Joanna helps me to find a case that the "fallback-after-ENOENT" logic > cannot > > solve: > > > > assume a system with a bge0 device, and one renamed it to become net0, > then > > opening bge0 or bge1000 should fail. But because opening /dev/net/bge0 or > > /dev/net/bge1000 returns ENOENT, it falls back to open the one in /dev, > and > > it succeeds. > > > > It seems that we have to use strcmp() unless someone have better idea. > > Seems like the fallback to /dev should only occur if the device is not > known to the UV framework. That is: > > * Search for <link> in /dev/net/; if it's found, we're done. > * Check if <link> matches a device name known to linkmgmtd (or > wherever this information is stored). If so, fail with ENOENT > (since if the device had a link matching that name, it would've > already been found). > * Otherwise, fallback to a scan of /dev. > > But maybe I'm missing something. > So who will do the second step? libdlpi? Or part of /dev/net/<name> lookup? I feel both are hacky.
- Cathy
