Eddie Chen writes:
> 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.
(Subject line changed to clarify thread contents.)
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).
One of the notification methods is via a sysfs KOBJ_CHANGE uevent
which can be caught by the udev subsystem. I added this on Friday and
it seems to work nicely. In practice, it means you can either have a
script which sits waiting for a file to appear by doing udevmonitor
(or udevadm monitor depending on kernel) to wait for such events
or you can add a udev rule to /etc/udev/rules.d with something like
BUS="ccw", DRIVERS="vmur", ACTION="change", RUN+="/do/something"
to trigger a program to run when a file arrives. There's a fancy
netlink API to uevents too if scripting doesn't appeal.
The other notification method is indeed via a blocking I/O but not
for the device itself. The good news is that sysfs *now* allows a
drivers to "wake up" readers of a sysfs attribute by triggering
poll() to see a POLLPRI condition. I can add that easily to the
"arrived" attribute meaning that something roughly like
fd = open("/sys/bus/ccw/drivers/vmur/0.0.000c/arrived", O_RDONLY);
struct pollfd pi = { .fd = fd, .events = POLLLPRI };
rc = poll(&pi, 1, 0, 0);
will block nicely and wake up with POLLPRI in pi.revents when a
new spool file arrives. The only annoyance is that when I say
*now*, I mean in modern kernels because that API (sysfs_notify and
in, even easier, sysfs_notify_dirent) is not in kernels of SLES10 SP2
era. I need to think about how best to ensure that people with older
kernels can distinguish clearly what's available and what isn't
(depending on how much backporting various people want to do).
Of course, nothing here should be taken as meaning that IBM is
committing to add this functionality and I'm only here talking about
what I tried on my own test system.
--Malcolm
--
Malcolm Beattie
Mainframe Systems and Software Business, Europe
IBM UK
----------------------------------------------------------------------
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/
