gemini@geminix.UUCP (Uwe Doering) (02/01/90)
matthew@sunpix.East.Sun.COM ( Sun Visualization Products) writes: > The following are a list of logic errors I have found in using Pcomm (1.2.8). >I have corrected some of the problems unofficially, (I posted them to >comp.sources.bugs last night), but others still need to be resolved, and >offical patches posted for all. > [some stuff deleted] >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. Actually, my INTRO(2) man page says that `EBUSY' has to do with re- or unmounting devices or resources. An open call is *no* mount operation. 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. Uwe -- Uwe Doering | Domain : gemini@netmbx.UUCP Berlin |--------------------------------------------------------------- West Germany | Bangpath : ...!uunet!unido!tmpmbx!netmbx!gemini
pim@cti-software.nl (Pim Zandbergen) (02/03/90)
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) Rather than relying on device driver dependent error codes, one could probably better use uugetty on this line. In that case, there *will* be a LCK file if the line is used as a dial-in line. -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
sysop@pinn.UUCP (System Operator) (02/04/90)
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
" Maynard) (02/05/90)
In article <1685@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes: >Rather than relying on device driver dependent error codes, >one could probably better use uugetty on this line. >In that case, there *will* be a LCK file if the line is used >as a dial-in line. Please don't throw me in that briar patch! Some vendors got dial-in/dial-out contention facilities right in their serial port drivers. Please let those of us who have such things make use of them instead of opening the uugetty can of worms... -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Free the DC-10!
guy@auspex.auspex.com (Guy Harris) (02/07/90)
>Rather than relying on device driver dependent error codes, >one could probably better use uugetty on this line. Rather than relying on "uugetty", which not all systems have, one could probably better set Pcomm up to handle all possible cases, including both "uugetty" and all the known "this device is being used for dial-in" error codes. (Handling "uugetty", of course, requires no extra effort, since *any* program doing dial-out has to check for a LCK.. file *anyway*.)