On Monday, 12/06/2010 at 10:50 EST, Eddie Chen <[email protected]> wrote:
> Over the weekend I took a look at VMUR.CCP source to insert "FD_ZERO(),
> FD_SET() and select()". I thought adding would be trivial.
> However, when I took a look at the device driver VMUR.C on the internet,
I
> found that the OPEN calls diag_read_next_file and if there
> are no data(no reader file) it will returns ENODATA(No data). That means
when I
> open the "/dev/00c" to get the file descriptor it will come back
> "NO data" thus no file descriptor for the select(). Also I notice that
it does
> not allow OPEN in "write" mode as well.
ENODATA? IMO, that's not appropriate for open() for precisely the reason
you discovered. Open() is not a data detection mechanism; it is a way to
determine the existence of an object and the program's access rights to
it. Assuming 00C is a virtual rdr, open('/dev/00c') should always return
an fd. It could *block*, but only if 00C was in a NOTREADY condition.
Alan Altmark
z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
[email protected]
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
