Xref: utzoo comp.sys.att:5447 comp.unix.wizards:14547
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!dougm
From: dougm@ico.ISC.COM (Doug McCallum)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: how to tell if a descriptor is a streams device ??
Keywords: streams, SVR3.2
Message-ID: <14422@ico.ISC.COM>
Date: 5 Feb 89 23:03:44 GMT
References: <290@hsi86.hsi.UUCP>
Reply-To: dougm@ico.isc.com (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 30

In article <290@hsi86.hsi.UUCP> stevens@hsi.UUCP (Richard Stevens) writes:
>Is there a "best" way to tell if a given descriptor refers to
>a streams device ??
...
>streams device.  The getmsg(2) system call does give you the right
>error, but you may not want to get a message.  
...

getmsg/putmsg appear to be the only way to get that particular error
message (ENOSR).  You could always ask to "get" zero bytes of data but
this may not give predictable results in some modes.  It is probably
safest to do an ioctl such as I_NREAD or I_PEEK and assume it is not a
STREAMS device if the EINVAL error is returned.  If it had been a
STREAMS device it would have been valid.

The only place I found the ENOSTR in the kernel was in a check for
valid send or receive on a STREAM.

As far as a "stat" is concerned, a STREAM is just a character device.
The stat structure would have no indication of it.  The difference is
detected on an open in that the cdevsw structure has a streams
information structure pointer and no open, close, etc. in the entry.

Sorry to not be of much help, but if I were to need to detect whether
it was a STREAM descriptor I would probably just assume it was if one
of the safe ioctl's failed.

		Doug McCallum
		Interactive Systems Corp.
		dougm@ico.isc.com