I didn’t think I was arguing. Quite the opposite. We (and others) agree zLinux should create the udev event for “reader ready” interrupts.
Enjoy the long weekend. 😀 On Sat, Sep 3, 2022 at 20:21 Alan Altmark <alan_altm...@us.ibm.com> wrote: > 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 <russell....@gmail.com> > 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 <alan_altm...@us.ibm.com> > 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) > >> alan_altm...@us.ibm.com > >> > >> From: WF Konynenberg <w...@konynenberg.org> > >> Sent: Thursday, September 1, 2022 10:10 AM > >> To: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>; Alan Altmark < > >> alan_altm...@us.ibm.com>; LINUX-390@VM.MARIST.EDU > >> 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
