> Despite the feeble stabs at reuse, this just is _not_ DLPI, and bears > no actual relationship to DLPI. > > I'm unhappy with the way libdlpi is being contorted to support the > confusion present in a non-DLPI user, and that it seems just as likely > to me that someone else will replicate this new stuff and thus make it > even harder to remove.
I agree it's a wart, but I think "contort" is blowing it out of proportion -- it's a single consolidation-private flag to dlpi_open(), and three tests of this flag -- in 1400 lines of code) to short-circuit some logic the libdlpi implementation. The libdlpi API and implementation is in no way damaged by this wart -- and I certainly prefer the 11 additional lines of code in libdlpi to the 200+ lines of gnarly getmsg()/putmsg() logic we'd have to dump back into the sync* commands. If someone wants to reimplement the serial stuff to not use DL_ATTACH_REQ, I would certainly welcome it -- and would gladly remove DLPI_SERIAL. But that's not this project. > The hackish way to fix this is to look at the real node, readlink(), > and parse out the actual instance number, then use that for > DL_ATTACH_REQ. The right way to fix it is to get rid of the pseudo > node junk. Agreed. Doing the readlink() crud though is not made appreciably harder by libdlpi though -- you'd just do that prior to calling dlpi_open(), and adjust the "linkname" accordingly. -- meem _______________________________________________ networking-discuss mailing list [email protected]
