Peter Memishian writes: > > > Porting it (and worse, polluting the library with special modes to > > handle it) doesn't make sense to me. > > Umm, it was already using libdlpi (prior to Sagun's changes).
I know. I'm suggesting severing that relationship. > > It's just a single #define and data structure ripped off from one > > module and used elsewhere for no apparent reason at all. The fact > > that this was done does not mean that the rip-off-er should adopt the > > support libraries of the rip-off-ee. > > The serial drivers do correctly use the DL_ATTACH_REQ primitive as per the > DLPI specification -- they even use the kernel DLPI routines to reply. It > does not seem unreasonable to share that code to me. Sigh. I still think it obscures the problem. 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. But, if you insist, I guess I can be consoled by the fact that the hardware that actually supports sync is disappearing. > > Plus, the proposed changes don't fix the original problem cited here. > > Yes, I don't know why Sagun listed that as a fix. At least that needs to be removed. > > They may actually make it somewhat harder to fix by burying the name > > parsing bits in the library. > > I don't really understand that bug well enough to comment -- if it's > really true that no DL_ATTACH_REQ is needed and that the non-clone node > can be directly opened, then I agree we can rip out this code and have > the sync* commands just call open(). They can, except for brokenness in the drivers that needs to be fixed as well. The drivers currently return EBUSY for no good reason at all if reopened. Thus, forcing it to use the ordinary device node (which is the right answer) without fixing the drivers means that it wouldn't work when an application is running on the port. Rather than using UNIX standard tty conventions, the sync designers tried to make the driver enforce exclusive access all the time. In doing so, they forced these utilities to need a separate node for administrative access, and they chose to create a single pseudo node for that, with DL_ATTACH_REQ randomly chosen as a way to access the real driver instance. The bug that's at issue here relates to this nonsense. They assumed that the /dev/se_hdlc<n> instance number would be the same as the actual driver instance number. It is sometimes, but not all the time. When it's not, it fails. 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. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
