Dunno why you’re arguing with me, Don. I was presenting the hardware-based rationale for Linux to generate a UDEV event when it receives a an unsolicited DE on RDR or tape devices.
Doing it for DASD would be a discussion for another day, as that’s a zebra of another hue. Regards, Alan Alan Altmark Senior Managing z/VM Consultant IBM Technology Services Endicott, NY USA > On Sep 3, 2022, at 6:41 PM, Donald Russell <[email protected]> wrote: > > All of that sounds very similar to how WAKEUP works. If the reader isn’t > spooled class * then WAKEUP won’t wake up unless the correct class file > arrives. I’d hazard a guess that’s a CP thing and not a CMS thing. That is, > CP won’t present the “ready” interrupt unless the arriving file matches the > spooled class of the reader. (vs WAKEUP checking then going back to sleep > because of the class mismatch) > > That’s fine, that’s all under user (root user sysadmin) control. > > I guess this is where you say to be careful. Yes, I’m not interested in the > arrival of a spool file, I’m interested in the arrival of a spool *I can > read. * > > My point earlier was that if CP presents the “device ready” interrupt to a > virtual machine running zLinux, then zLinux ought to do something > constructive with it. i.e. create a udev event so an *application* can do > something with it. > > You said “UDEV was meant to reflect physical device events to user space.” > > We’ll, the arrival of a “card deck” is a physical device event. > > Yes, Linux code could poll the reader every 9 seconds. (An interval meant > to be sarcastic) That’s a terrible design for virtual machines. > > >> On Fri, Sep 2, 2022 at 06:50 Alan Altmark <[email protected]> wrote: >> >> 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 >> > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
