🚀 go-pugleaf

In article <O1HCFU@geminix.UUCP>, gemini@geminix.UUCP (Uwe Doering) writes:
> matthew@sunpix.East.Sun.COM ( Sun Visualization Products) writes:
> 
> >2) Pcomm does not handle dial-in/dial-out lines correctly.  It assumes that
> >   if it can get a LCK file for a device, that it owns the device.  This is
> >   partially correct.  An initial open() needs to be accomplished to test if
> >   the device is currently being used as an dial-in line.  If 'open()' returns
> >   and error code of 'EBUSY', the device is being used as a dial-in line, and
> >   should be handles as a LCK'd device. (my patch for GETPORT fixes this)
> 
> Matthew, your patch shouldn't rely on the error code `EBUSY' because this
> code is created by the driver itself and may therefor be vendor dependant.
> I think it is more common that a device driver returns an `EIO' error if
> it is already used as a dial-in line. At least the driver I posted recently
> does this (FAS 2.05). :-) As well as Microport's and Interactive's drivers
> do (I think, at least). Correct me if I'm wrong.

In Xenix, there is no return code as above.  However, the Pcomm author was
nice enough to include a function stub which allows the getty to be disabled
before a call is made and then re-enabled after the call is finished.  I have
added some code in this area which checks to see if there is a getty on the
line I want to use and if so, I attempt to disable it.  If I can't disable
it (or there is no getty there) then then line is in use and Pcomm won't use
the line.  There was one logic error in the original code where even if the
getty couldn't be disabled, he would still go on and attempt to use the line.

If anyone would like the specific code for Xenix V... mail me a message.

Andy
{your favorite backbone....}!codas!novavax!pinn!sysop