> David Boyes wrote: > > There seems to be a clear customer requirement for making access to > > DIAG function available. > > The question we're debating is how, not why. The why is a foregone > > conclusion. > Maybe I missed that part of the thread, but would you mind > showing me the requirement? I mean, couple of diagnoses _are_ > exported, and for others I fail to see what they could be > useful for in a Linux application.
Pardon my increasing frustration here... We out here in the outer darkness (very far away from Martin's office) see an architectural use for them, which, to me, constitutes a requirement for someone to fullfill. This may or may not be an IBM task. > Big mistake. You don't get CPs architectured interfaces in > Linux userland, Wrong. That's exactly what we are talking about -- how to surface CP interfaces in a useful way for Linux. For some functions, CMS utilities call CP interfaces to do things. Those interfaces are clearly defined and accessible by the methods we are discussing. If we no longer have CMS, we need access to those CP interfaces from Linux in order to write replacements for those tasks and utilities that CMS enables. > Running a CMS application requires _porting_ it to the new > interface scheme, which also means reworking its logic to fit > that quite different programming model. No one is promoting running CMS application modules as is. Grant me that I do know that much, please. We need to be able to access the same interfaces in CP that CMS uses in order to write replacements for the CMS utilities in Linux. We are discussing how to present those services to a Linux application in a useful and consistent way. Is that clear enough? If I want to write a replacement for DIRMAINT, then I need to be able to call the CP interface to update a directory entry or update in place. If I want to write a better tn3270 function, I need the ability to determine device characteristics. Etc, etc, etc. You don't have to anticipate every possible use or even whether they will be useful, because I'll think of some way to use them that you never even dreamed of. Count on it. > > Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the > > paperwork already, OK?). IUCV function is in a usable state > from us. > > DIAG function is next. APPC/C-PIC probably next after that. > IUCV functionality seems useful to me, because that's a > network protocol family which is used in z/VM today. As for > the others, I don't know what they do. IUCV is *not* innately a network protocol -- I don't know why everyone assumes it is. It can be used for carrying network traffic, but IUCV at the low level has the semantics of a point-to-point connection. It is a point-to-point message pipe between two virtual machines, possibly on more than one physical machine via ISFC or TSAF using distributed IUCV. > DIAG nn interface > This is troublesome as pointed out before: What if your > script that has aquired the lock crashes? How is that different from any other important locked file if the process crashes? You clear the lock and continue. > > > /sysfs/zvm/diag/nn/instance - for DIAGs that could > > logically have multiple sessions > > (not really applicable to > > DIAG 8, but would be a useful generic to have) > > open of the > 'instance' file > > would generate a session or instance of the > > desired DIAG, and > read from > > the file would return the path of the instance to > > communicate with. If the > > DIAG does not rationally support multiple > > sessions, always return a > > fixed string. > Not needed. Oh, nonsense. What about DIAG 250? > > /sysfs/zvm/diag/8/cmdstring - the command to be executed > > /sysfs/zvm/diag/8/cprc - the CP return code > Not safe for multiple parallel sessions, and does'nt fit > sysfs purpose. Wrong. Perfectly safe if the conventions described above are obeyed, and if properly implemented to check for the lock specified by being writable only by the process with the lock. I'll defer to others on whether it contravenes the purpose of sysfs -- I would interpret it as appropriate in that it is a system control function. > I really feel uncomfortable with that approach because it > does not fit the unix model at all. Given that the "Unix model" is incorporating useful concepts from Plan 9 and other systems as fast as it can absorb them, I'd say it anticipates the direction things are going rather nicely. Where do you think the idea behind pseudo-filesystems like proc and sysfs came from? It certainly didn't originate in Unix, you can be certain of that. > Also the overall idea of > running CMS applications in Linux instead of porting them > seems queer for me. As said before, that's not what I'm proposing. I'm proposing to make it possible to write replacements. To do that, I need to be able to connect to -- and use -- the CP services that effect the necessary changes. That's what we're trying to discuss. ---------------------------------------------------------------------- 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
