I won’t pretend to be an expert in UDEV architecture, but the research I’ve done showed me that UDEV was meant to reflect physical device events to user space.
Having refreshed my memory by re-reading “IBM 2821 Control Unit Component Description”, I think the arrival of a card deck in a card reader is equivalent to a USB stick appearing in a USB port. When you press the START key on a 2540 card reader, the device transitions from NOT-READY to READY, causing an unsolicited interrupt (Alert+Device End) that tells the OS to start reading. Once EOF is reached (no more cards in the hopper and the EOF button was pressed), the 2540 signals a Unit Exception, failing the outstanding READ operation that’s waiting for next card. From that the OS knows that the file is complete. Once, the UE is sent, the 2540 returns to the NOT-READY state. In VM, the arrival of a RDR file effectively pushes the START button on the virtual RDR. [I’m not looking to start a retrospective on the 2540 or its modes of operation that differed from the above description. I’m just trying to make a point.] But be careful. While we think we’re interested in the arrival of spool files, we’re not. Rather, we’re interested in knowing that if we start reading from the card reader, there are cards in the hopper to be read. I.e. If a spool file arrives with class Q, but your RDR is spooled class Z, you won’t be able to read the spool file. That’s why seeing the device transition to READY is so important. That only happens if an *eligible* file arrives in you RDR. (Anyone who has written a non-blocking socket application will appreciate that subtle difference.) Cards, tapes, disks. They all had removeable media and they all signaled the host the same way. Even a terminal would generate an unsolicited DE when you turned it on; that’s how the OS knew it was ok to write a logo to it. (I guess the human was the removable media!) This is not to be confused with changes in I/O configuration where subchannels are added to or deleted from the I/O configuration. That’s a whole different kettle of fish. Regards, Alan Alan Altmark Senior Managing z/VM Consultant IBM Technology Services 1 607 321 7556 (Mobile) [email protected] From: WF Konynenberg <[email protected]> Sent: Thursday, September 1, 2022 10:10 AM To: Linux on 390 Port <[email protected]>; Alan Altmark <[email protected]>; [email protected] Subject: [EXTERNAL] Re: Can zLinux detect when files arrive in the virtual reader? I would be inclined to suggest that use of udev for user I would be inclined to suggest that use of udev for user functionality like this likely constitutes abuse of the udev design. It might be better to find an approach that fits in the canonical Unix/Linux model of handling various device quirks. Steal ideas from, say, the magnetic tape driver interface and tooling, the tty subsystem, etc. Don't go out of your way to design something new that is completely unique to zlinux. I wouldn't be surprised if the rdr device driver needs a wee bit of fixing to make it properly support a classic style Unix/Linux device usage. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
