Xref: utzoo comp.unix.sysv386:7312 comp.unix.wizards:25122 comp.unix.internals:2635 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.unix.sysv386,comp.unix.wizards,comp.unix.internals Subject: Re: System V, B0, and DTR. Keywords: iNTeL SVID callback etc... Message-ID: Date: 25 Apr 91 14:42:34 GMT References: <1991Apr24.213344.21645@chinet.chi.il.us> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 39 I said: > >Any suggestions? (no, closing and opening the port doesn't appear to be > >an option in this case) What do you people think the Right Thing to do is? In article <1991Apr24.213344.21645@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > I don't quite understand that attitude either - if you've got the source > and a close/open makes it work why is there any question about doing it? Well, I'll give you a hypothetical example, and then the real reason. Either should be enough. They both come down to "close/open doesn't make it work". Hypothetical case: you have another application running that you don't have the source for and for some reason you can't terminate it and start over. This is a problem with terminal programs under AmigaDOS, where they need to keep the port open in a shared mode for things like serial networking. It is a potential problem under UNIX, which is why B0 is there. The real reason: it doens't work. There is a bug somewhere else in the driver that leaves us with no control terminal after we open the port. intel acknowledges that this is incorrect, but has not been able to reproduce it (they have a significantly different system configuration, too). We are using the same program, with the same options, and the same setup. Intel is willing to debug and fix this, at considerable cost to themselves, but is unwilling to make a 2-line change unless they can be sure it retains the correct semantics. Something about staying in sync with AT&T. That's why I'm asking this question on the net: to demonstrate that the behaviour we desire is the right thing to do. While it's frustrating in this case, this conservative approach *does* seem to be better than ISC's and SCO's habit of arbitrarily breaking stuff. > How about open/close on another fd following the ioctl restoring the > speed to non-zero while your current fd remains open? Doesn't work: DTR is only raised on first open and dropped on last close. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"