> We've been doing some thinking about a more general way
> to enable access to CP system services from Linux, ...
This is a great idea, Dave!
We did have at one time a "FreeVM-L" list
specifically for discussing generic hypervisor concepts.
The intent was to be vendor-neutral, platform agnostic,
and not necessarily create *code* but rather a *spec*.
> One of the useful ideas in Plan 9 ...
> ... is the idea of representing
> *everything* as a filesystem-like structure (much along the lines of
> the way /proc is done) ...
Yes.
Shades of /proc.
One can only imagine that Plan 9 had some influence on /proc.
What's nice about that whole approach is that it is closer to
defining a protocol than to defining an API. That's good!
There is way too much defining of APIs and way too little of
defining protocols.
Layer it like this:
1) Define a protocol.
(like a TCP conversation even if it is local)
2) Build a reference API on that protocol
but don't paint yourself into a corner.
That is, if your reference API is in and for C,
don't do anything that prevents another API for REXX.
3) Build a sample application on that API.
It might only be used for testing. That's okay.
4) Build production applications as command-line tools.
Allow for scripting, with or without an embedded interp.
5) Build GUI and/or web on the command-line suite.
> a) does this sound like a usable paradigm?
Usable, yes.
But it's a little foreign (the "clone" semantics).
Simple queueing of sessions could be done a bit more elegantly.
(I'm thinking sockets, I suppose.) Let Plan 9 be Plan 9
and implement this idea from the 30000 ft level.
> b) is it worth implementing?
Of course!
But you should dig a little deeper. Get more fundamental.
(And "soar a little higher".)
Instead of two pseudofiles (ctl and data), I would suggest
using a combination of read()/write() and ioctl().
Think of it as a stream. Provide access to the "out of band" data.
(More below; discussion of multi-stream internet protocols.)
Gaack ... this leads to DASD thoughts.
COUNT and KEY are "out of band", while DATA is data.
Hmmm... ioctl() for DASD ... hmmm... hint, hint, grumble mumble.
But good use of fstat(). Very good!
> c) what am I missing?
You're somewhat Linux-centric here. Don't be.
In the case of IUCV, consider something compatible with CMS Sockets.
I mean, Linux should have an AF_IUCV like CMS does.
(Wasn't someone working on that?) ;-)
But seriously, all self-promotion aside,
think of interoperability first. Make that your goal.
Don't paint yourself into a Linux corner, nor a z/VM corner.
IUCV is rather unique to z/VM.
DIAGnose is coded for z/VM and zSeries,
but most of what it is used for can be generalized.
This is where the FreeVM-L discussion would have helped.
"8,CP QUERY USERID" is just waaay too platform specific.
Looks like a REXX coder trying to force a familiar model onto Linux.
Would be better to have a constant QUERY_USERID supplied to some call.
The z/VM console command processor is just one protocol to use.
DIAG 8 is simply its handle. Nothing magic about DIAG (8 or other).
Nothing sacred about the CP command suite. (Apologies to Endicott.)
It's nice that there is an
hcp commands
command to return the list of available commands and DIAGs.
Not unlike some of the newer internet protocols, what can you do?
Let the model be capability based.
Talking about multi-stream protocols,
I have always found FTP terribly annoying.
It is just downright trivial to handle control and data in the
same stream (if you have just one, like for an internet based service).
You have split "TERMINATE" and other controls into one vein and data
into another. Much easier to have the module look for a
"DATA" command along with other controls. RSCS and IMAP
both have examples of this, from what little I know of them.
> I haven't started implementing yet, but I'd like to get
> as many reactions as possible. Discuss...8-)
Well ... enjoy!
-- R;
