On Tuesday, 12/07/2010 at 09:07 EST, Malcolm Beattie <[email protected]> wrote: > Indeed, the interface to unit record devices (whether via channel > programs or via DIAG) is not a blocking one: you try a read from the > device and it either gives you data or it comes back immediately with > "no there's no data". Hence why I wanted to add an asynchronous > notification that a new file has appeared in the reader. > > The I/O model is that when this happens, CP (presumably modelling what > would happen with real hardware) presents an unsolicited interrupt to > the driver. I've looked at two ways in which that could conveniently > be sent through to userland. First of all, I've added an "arrived" > attribute to ur devices which gets incremented each time a file > arrives so > cat /sys/bus/ccw/drivers/vmur/0.0.000c/arrived > contains a number checkable by scripts or programs (useful in case of > wakeups or restarts of an app so it can check if anything really > happened).
But you're not opening a spool file, you're opening a special character device. The only thing open() of a UR device should be sensitive to is the READY/NOTREADY state of the device. According to POSIX, open() of a char special file is supposed to block until the device is "ready or available". Think of a tty device. It can be opened without the user having previously pressed a key. The point is that you can reasonably expect read()/write() to complete. If a virtual punch or printer is NOTREADY, there's probably no spool space and you can't expect to write() to succeed (ENOSPC). If the device supports a non-blocking open (optional), then you can choose to wait for the problem to resolve itself. Once you make more spool space available and then CP READY 00D (or 00E), then the open would complete. As for virtual RDRs, I don't think many people use "CP READY/NOTREADY 00C", and I don't know of any condition that causes CP to put virtual rdrs in NOTREADY state. (Maybe no spool extents online at all?) But non-blocking support for open() isn't required, in which case it would give back ENOSPC (prt/pun) or ENODATA (rdr) immediately and the app must poll (eeeewwwww, gag, choke, die). For RDRs, EOF (unit exception) indicates the end of the spool file. The next read() would read the next spool file, if present, or block, if not (unit check). For non-blocking, select() would wake up when a spool file arrives (device end). For punches & printers, select() wakes up when the device goes READY as mentioned above (device end). For a reader, iotcl() could reasonably return the metadata from diag 0xbc, providing consistency between spool file attributes and contents. The effect of SPOOL 00C CONT would create an issue w.r.t ioctl() since no per-file EOF would be given and the app would have no idea that is it reading multiple files. (I guess if it hurts, don't do it, eh?) 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/
