2016 003 Relaxed conformance for less traditional kernels

Proposal 2016-003

Relaxed conformance for less traditional kernels.

Author: matt rice
Managing editor: Some Editor
Last revised: September 15, 2016
Status: proposed
Discussion: issue #20

---

Synopsis

Some basis structures which are Required are problematic to implement under kernels which provide no mechanisms for their implementation.

This proposal is to create a new "conformance level", where signatures and structures which are required at one
conformance level can be optional at another conformance level.

signature TEXT_IO (* Optional(minimal) Required(full) *)
structure TextIO :> TEXT_IO
signature BIN_IO  (* Optional(minimal) Required(full) *)
structure BinIO :> BIN_IO

signature OS_FILE_SYS (* Optional(minimal) Required(full) *)
structure OS.FileSys :> OS_FILE_SYS

signature OS_PROCESS (* ?? *)
structure OS.Process :> OS_PROCESS

signature COMMAND_LINE (* Optional(minimal) Required(full) *)
structure CommandLine :> COMMAND_LINE

Some kernels differ significantly from the kernels the basis currently targets
seL4 in particular is the most active kernel of this sort at this time
although other kernels encounter the exact same issues.

I'll describe a "conforming" implementation of the problematic structures and their functions.

Description

* The TEXT_IO and BIN_IO signatures:
* `openIn file'<br/>
* `openOut file'<br/>
* `openAppend file'<br/>
Always raises Io.

Should basis provide signature and structure for open OS.IO.iodesc?

* OS_FILESYS signatures
Always raises SysErr.

* OS_PROCESS
* `system cmd'<br/>
Always raise SysErr.  This function is especially problematic because it is only the system function
which is problematic to implement.  The rest of the structure is useful and should be required.

Should basis provide a signature which is a subtype of the current OS_PROCESS which does not contain
the system function?

* COMMAND_LINE
The main entry point is described as main(void) rather than
the more traditional main(argc, argv), neither the language nor the basis defines an
entry point so this is fine however the CommandLine structure remains unfilled by main(void).

Discussion

In lieu of any kernel provided file naming or filesystem (which may be provided by user mode programs)
Those functions which accept a file name as a string, and perform some filesystem operation
are unimplementable and thus always raise an exception.

This is neither pretty nor helpful for portability, It merely allows one to conform to the standard
where the module is Required.

Impact

This should not affect existing implementations of the basis, as it only concerns only the minimal implementation required for conformance

Rationale

It would be nice to have a conforming implementation on these kernels where raise wasn't abused.

---

History

• [2016-09-15] Proposed

---