> I think I'd rather see files created of the sort cp/diag/0, cp/diag/8, > cp/diag/24, and so on. Some of those files are r/w (8, 24), some are r/o > (0). Some are capable of async, some are not. You write the input record > (if appropriate) and read the output record.
OK, that makes sense for most of the DIAGs. Using this model, how would you handle a case where you may need different processes working independently with diagnoses (I'm thinking of something like DIAG 248, where you might need to pass a different ALET depending on what process was switching the address space around)...hmm. I suppose you could still control access to the pseudofile with semaphores or locks, or one could always assume that the /cp/diag/nnn entries would be opened exclusively to prevent race conditions. I guess you could also assume that in most cases, everybody in a single virtual machine would get the same response to the DIAG, so other than the few DIAGs that manipulate things like ALETs, most of the entries would be read-only. > In other words, I'd like the diagnose code to not be part of the data > stream. That just creates extra complexity without good reason. If you > want to dynamically supply the diag code, then you use sprintf() to > construct the file name. This provides the flexibility to let fopen() > create any buffers it requires based on diag number, with close() getting > rid of them. > The paradigm holds for user-user comms. E.g. fopen(/cp/iucv/altmarka) or > fopen(/cp/iucv/*MSG) establishes an IUCV connection immediately. How would you handle out of band information with this syntax? I would like to avoid having a bunch of cryptic ioctl magic to get stuff like the remote peer name, etc. If I allocate a connection, then tell it what to do with the connection, I can use a common structure and consistent pseudofile structure for any type of connection. Also, how could one handle a listen() analogue? Not discounting your comment, but trying to see how it would work without having to develop a API library around it. I'd really, REALLY like to avoid the general ugliness that socket programming imposes; it's not really a natural thing, and you'd have to write interface code to get old stuff to work with it. I really would like to be about to just use 'cat' to set up a network service...8-) (note: I don't want to open up the sockets vs streams wars again...)
