> On Apr 20, 2016, at 2:01 PM, Sampsa Laine <[email protected]> wrote:
>
>
>> On 20 Apr 2016, at 20:45, Ken Cornetet <[email protected]>
>> wrote:
>>
>> Other than the OS on the old Atari 800 family of computers, I don’t know of
>> any OS that supports a device to which you can supply a file name and then
>> read or write data.
>>
>> Most OSes view disk devices as a collection of blocks.
>
> You’re missing my point - the guest OS would not be mounting this as a block
> device, but would have some kind of file transfer utility to talk to the host
> OS’s file system.
Let me flesh this out a bit, I think I understand your idea and it's a pretty
straightforward one. It vaguely looks like a pseudo device implementation of
the GDB remote stub file access setup. Or, I suppose, vaguely like FTP
requests; they two are the same thing at a sufficiently superficial level. :-)
Consider a new type of device exposed to the guest software. You can send it
commands: read a file, write a file. After that command, you read from the
device to get the file data, or write to it to send file data. End of file is
an I/O status code (for read) or some special device operation (for write).
From the application point of view this isn't all that different from guest OS
file read/write calls, except that (a) it's sequential only I assume, (b) the
operations are represented as device operations rather than being handled as OS
calls.
What you need for this to work is a way to talk to a raw device. That means
directly, if the OS allows it, or if you don't have one. Or via a very simple
device driver if one is required. For example, on RT11, or an IBM 1620, you
could do the I/O directly. On RSTS you'd either need a driver (which is a
pain) or do it through a sequence of "peek" and "poke" operations (not too bad).
Yes, that seems like a notion that could be interesting. It would be good to
do an existence proof, on some not too difficult machine. Perhaps a PDP11 or
PDP8, with the "direct to the device" approach.
paul
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
