Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!mit-amt!snorkelwacker!ira.uka.de!smurf!gopnbg!tmpmbx!einoed!geminix!gemini From: gemini@geminix.UUCP (Uwe Doering) Newsgroups: comp.sources.d Subject: Re: Bugs in Pcomm 1.2(.8) Keywords: bugs, logic errors Message-ID: Date: 1 Feb 90 11:47:46 GMT References: <1101@trancb.East.Sun.COM> Reply-To: gemini@netmbx.UUCP Organization: Private UNIX Site Lines: 30 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