David Boyes wrote: >>I agree with Martin that its not feasible to support a diag >>pass-through. > > > 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. > > Making a "generic" /dev/diag is not practical. Presenting DIAG function in > another way is. See below. > > >> In most cases I have no idea, why >>do you need this diagnose in Linux. So lets go one step >>further and find out: >> >>"What problems or scenarios do we want to solve WITHIN linux?" > > > Please, let's not get bogged down in scenario thrashing. We get enough of > that from IBM SWG. At a high level, what we're trying to accomplish is: > > If we are to no longer receive management (or any) function added to CMS, we > need the ability to perform the tasks CMS has traditionally performed within > the Linux environment. The fundamental problem is to enable all the existing > architected communication paths between the guest OS and CP in a natural and > usable manner in Linux. > I think that's a big "if".....I don't believe that IBM has ever made the statement that CMS is "functionally stabilized", although I may have missed it. We are getting new CMS-based management tools and features from IBM now (e.g., Operations Manager, Archiver), and CMS PIPELINES is certainly being enhanced and extended now.
While I am in favor of integrating, where possible, virtual Linux guests more closely to both CP and CMS, I don't want to see the (limited?) resources IBM has available spent on reinventing the CMS wheel in Linux. We don't need all the features that CMS now offers to be re-invented in the Linux environment; we need the unique features that Linux brings to the table built upon and expanded. As we've seen with the recent DIAG discussion, some problems are more easily solved in the (simpler, single user) CMS environment than in the more complex Linux one. As Rob van der Heij comments in another post, we don't need the ability in Linux to be able to write a CP directory management product....... > 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. > Even though VMCF has been displaced by the newer and more efficient IUCV function, it still has its uses. As David says, c'mon Malcolm, go talk to the lawyers.....:-) > For DIAG support, I suggest: > > Each DIAG we choose to provide be implemented as a individual driver in > /dev, with control interfaces presented in /sysfs/zvm/diag/nn/. Example: > /dev/diag8, with control interface in /sysfs/zvm/diag/8. > > Suggestion, using DIAG 8 as an example: > > Implemented in all DIAG drivers: > > /sysfs/zvm/diag/nn/lock - semaphore to use as a > reserve/release flag. Processes > attempt to flock() this file. > Success indicates acquisition of the > DIAG nn interface > /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. > > Specific to DIAG 8: > > /sysfs/zvm/diag/8/cmdstring - the command to be executed > /sysfs/zvm/diag/8/cprc - the CP return code > > If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then > write CP command into cmdstring to prepare for call. Once parameters are > loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the > preloaded command. Result of command is read from /dev/diag8 to EOF. Process > should close /dev/diag8 on EOF. Process can then load a new command into > /sysfs/zvm/diag/8/cmdstring and repeat, or release the lock. When process is > finished with the DIAG 8 interface, funlock /sysfs/zvm/diag/8/lock. > > Individual DIAGs can have their own variables in /sysfs/zvm/diag/nn as > appropriate. The lock mechanism is simple to implement in arbitrary > languages (works trivially in Fortran -- my favorite test), and is general > enough to accommodate arbitrary DIAGs. > > Once that basic structure is in place, then generating the individual > /dev/diag<nn> drivers are a plug-n-chug problem. > > APPC is harder. I've got code for it, but I don't think I'll be giving it > away. > Isn't the APPC protocol proprietary to IBM? > -- db > > ---------------------------------------------------------------------- > 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 -- Dave Jones V/Soft Software, Inc. Houston 281.578.7544 ---------------------------------------------------------------------- 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
