[Simh] MOP header specs?

[Timothe Litt]

On 23-Feb-18 19:56, Paul Koning wrote:
>
>> On Feb 23, 2018, at 5:28 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> ...
>>> That's why a MOP load normally consists of asking for a program - which is the secondary loader.  It's the secondary (or tertiary) loader that knows how to unpack an image and make additional requests.
>> Hum. Well, that might be, but both will be served through MOP, so it don't make much difference if it's the primary or secondary boot. They are served the same way. 
> Almost.  A secondary loader response carries the entire secondary loader in a single message, so the bootstrap only needs to handle one message.  Tertiary and OS loads are expected to take multiple messages.
Yes.
>
> Either way, though, the MOP protocol spec only describes bits on the wire.  How those bits are derived from files on the serving host is a host matter.  
Yes
> Since multiple host types support loading various devices such as routers or terminal servers, it seems likely that they share an on-disk format, but if they do, that's a packaging convenience question, not something the MOP spec addresses.  
Yes.

The server doesn't need to understand the file format.  It MAY, but
needn't.  It can simply serve bytes (mapping file offset 0 to memory
offset 0).  This is the trivial answer: load program has the secondary
loader at offset 0; the secondary loader adds its length (typically
rounded up to a disk block) to subsequent load addresses, doing the same
for any tertiary loader.  This puts everything in one file.  Or the
server can decode a complex header.  In any case, the server CAN just
serve bytes.

Alternatively, the server can read a complex file format (a.out, VMS
image header) and send responses that expand demand zero pages, or
decompress an LZW-encoded stream, or keep the loaders in separate files,
- or whatever.

It can access and/or serve different file formats based on the request.

There are lots of variations.  MOP carries bytes (octets) on the wire. 
The server supplies (or in the case, of dump, sinks) the bits. 
Packaging can be very simple, but involve a contract between the
embedded loader(s) and the rest of the data file.  Or the MOP server can
have deep knowledge of the file format, and present it in a canonical
format that the client loader understands.  Or any combination.

Again, (call this violent agreement), MOP carries bits on the wire. 
That's all.  There is no MOP header.  No semantics are associated with
the bits at the MOP level.  There are packaging conventions that involve
contracts with the server and/or the secondary loaders (which may or may
not be embedded).  These are all decisions that are outside the scope of
the MOP protocol, usually to optimize external factors. 

> You can think of MOP as a simple data transfer protocol; the fact that clients use it to load executable bits into memory is not required.  The same is true for TFTP, and there the name of the protocol makes the point explicit.  MOP doesn't say it quite so clearly but it is just as true there.

Yes, MOP is a data transfer protocol.  It's also more: "Maintenance
operation" - we've talked about the data transfer aspects, but it also
has built in the concepts of programs, loaders, selective loads,
providing time, loopback, redundant servers via multicast, even a remote
console service.  It's designed to allow a remote diskless node to be
managed as if it were local: trigger boot, trigger dump, remote console,
complex load and dump sequences.  Even a nod or two to security (as
understood at the time.)  All with heterogeneous architectures.  It is a
fairly complete solution to "I'm in Hawaii, the target is at the north
pole - I need to load/dump/diagnose it without getting cold".

TFTP is a different animal.  It is designed to move files between
hosts.  It's a file (or in a case of true weirdness, an e-mail
destination).  But TFTP really IS Trivial.  It moves a file by name. 
Period.  All you get is "read, write, data, ack and error".   A file is
opened, and data is processed sequentially to EOF.  It has no provision
for transfer address, much less providing time, non-sequential access, 
or the many other luxuries that MOP allows for.  Loading an executable
into memory with TFTP and having it run is not specified in the
protocol.  In fact, anything nontrivial built on TFTP requires the
client to have a more involved contract with the server.  (effectively,
private protocol extensions)  However, TFTP DOES specify a "mode" in the
read/write command, which can cause the bits on the wire to be
translated or repacked.  This is not a critique; while TFTP is often
abused ("extended"), it does do exactly what it sets out to do. 
barebones file transfer, with no optimizations for security or
performance. 

> 	paul
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180223/63c65b45/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180223/63c65b45/attachment-0001.bin>