Brian F. G. Bidulock wrote:
SVR 4.2 STREAMS modules do no return negative error numbers, they
return MODOPENFAIL, which is translated to ENXIO when returned to
the opening process. LiS does not comply to SVR 4.2 because it
does not accept a positive error code. Almost everywhere you point
LiS has an error. This is just an example where someone happened
to point.
Does SVR 4.2 Streams say that MODOPENFAIL is a postive number?
Your Streams programer's guide is a little more up to date than
mine (System V/3.2). Mine indicates that >= 0 should be returned
for success and OPENFAIL (must therefore be a negative number)
for error. In my modules, I return OPENFAIL but as evidenced by
the IBM modules, not everyone does that.
The other references I have at hand are Solaris and UnixWare.
Solaris docs indicate that "The return value from open is 0 for
success and an error number for failure". UnixWare does likewise
but specifically lists error codes (eg EACCESS, EADDRINUSE)
which, on Linux, translate to negative numbers.
If something other than OPENFAIL is coming out of the open
routine, it's the module that's doing that, not LiS.
In my opinion, Dave made a good choice in looking for _any_
negative number. It could be strict about making sure that
the driver returned OPENFAIL/MODOPENFAIL, but that would break
drivers being ported from other OSes. And it begs the question
about what Streams would do if the driver returned neither >= 0
nor OPENFAIL/MODOPENFAIL. Indicate a error back to the app
(which is what the driver is trying to do)?
Steve
------------------------------------------------------------------------
Steve Schefter phone: +1 705 725 9999 x26
The Software Group Limited fax: +1 705 725 9666
642 Welham Road, email: [EMAIL PROTECTED]
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com
_______________________________________________
Linux-streams mailing list
[email protected]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
