From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 18-DEC-1992 13:26:07.05
To:	uunet!"macro32%wkuvx1.bitnet@cunyvm.cuny.edu"
CC:	
Subj:	Re: call for half baked ideas

A new VMS filesystem and I/O call standard needs to have a number
of things.
1. ODS-2 and the $qio service need to be supported as is, but possibly
by compatibility routines and not necessarily on all volumes. I would
be very unsurprised to see ODS-2 occupy the same position eventually
in a new system as ODS-1 does on VAX-VMS...usable, supported, but
not commonly used except for communication. The system should be able
to support different file structures at least as well as can now
be done by ACPs and XQPs. Ultimately it should be much easier to
support them this way; I would love to see such capabilities for
support offered that would understand such file systems as:
  * BSD Unix
  * MSDOS
  * RT-11 (limited, but for some realtime applications it is a very
                fast performer.)
in addition to such newer ones as become available.

2. The filesystem code needs to look at work going on in unixoid
systems with journalling filesystems and file systems where file
locations are not strongly bound to physical locations but can
migrate around networks. This implies that remote access methods
are well understood by the I/O system so that the complications of
files being open or not don't produce so much pain as they now
do and so file physical location can be altered to handle traffic
patterns, new I/O devices and techniques, and so on, without having
to shut things off/down first as presently.

3. Access monitoring needs to be reconsidered. The ACLs we have in
VMS are very nice, but if you think a bit you conclude that there
are many more questions you can ask about whether person A should be
able to access object/file B. For starters consider things like
login terminal checks in unix, or file passwords in MVS as asking
additional questions like "where's this user coming from now?" or
"Can I be EXTRA sure he is who I think he is?". These kinds of
questions should be extensible; some files that are very critical
to a business ought to have better protection than others.

4. For sequential file access, users should have something as easy
to use as the TOPS-10 open/read/write/close services. I approve of
having a standard ISAM facility and so on, but would like a
smaller facility and would prefer to usually have and need no metadata
in my files, as variable record length has now. (This would also get
rid of some of the artifacts like 32767-byte maximum record size
which we now have.)

5. There should be plenty of places where an I/O service has
defined interfaces, as now, so that extra functions can be added
as needed; nobody will think of all such from the beginning.

6. The $qio model is not a bad one to have, and I am comfortable with
it. Extensions (which had better be asynchronous in nature) might
do well to have facilities for easier use as bidirectional and
partly externally directed streams, and maybe one should think
of an I/O service in terms of "connect to datastreams". It may be
unwise to replace $qio with another service able to set a bit to
open the back door or mow the lawn, though, but just stick with
$qio and itemlists, adding some functions where needed to the driver
interface. A simplified service for sequential activities where
not much variability exists would however be a real good thing.
Such a service could have many less arguments for the exec to
check, which ought to make it a bit faster. Since such a service
could be new, maybe one should have a variant that allows things
like input from outside always into the same buffer space (once
you know the buffer is legal, no rechecks) or queue. If the buffer
to use were system allocated (remember RSX block mode I/O with
"location mode"?) lots of DMA setup operations might be avoided
in such a case. You'd still need something as general as $qio for
really peculiar devices, and there'd need to be some notion of a
common driver interface, but user mode code would be much easier.

7. That said, I'm still uncomfortable with all the things the
terminal driver has to do. It might be time to rethink that
interface and ask whether something simpler could be used
with user callouts to let the complex stuff be handled outside the
main driver stream. This might mean you'd have areas mapped to
an exec as well as a user process or some similarly weird
thing, but in a 64 bit address space that should not be too hard
to manage.
  Maybe it would be possible to think about adding at least some
rudimentary data scrambling between network terminal multiplexors
and CPUs this time, to defeat at least the simple minded PC based
network monitors which can now pick passwords etc. off ethernet lat
streams so readily. Promiscuous mode Ethernet is like a hardware
assisted wiretep...but it's gotten so you almost have to use Ethernet
to get into a VMS box. Even a simple xor with some bitstream that
could be altered once in a while would be just fine to keep most
of the curious out, and in big companies, it's usually infeasible to
keep PC, workstation, or mac taps off the common ethernets. We do
NOT need some superstrong algorithm...but some bit of scrambling
would help a lot in the real world.
   Obviously we're not about to get the standards for Telnet changed,
and I don't intend to suggest such...merely that a start anywhere
we can start will be good. LAT might be something to consider...it
does get bridged wide area in many places...

So much for my half-baked ideas about this...
Glenn Everhart
Everhart@Raxco.com