[TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Oct 13 08:43:26 AEST 2020


    > From: Paul Riley

    > port Mini-Unix will create some demand for device drivers on the /03
    > systems, so may be worthwhile to implement RAW device.

I'm not sure I understand this ("worthwhile to implement RAW device"); let me
explain what the removal of 'raw' I/O devices from MINI-UNIX really means, and
then ask what it is that you are after.


Early Unix (no idea about later ones) supports two classes of devices; 'block'
devices, which can be used to hold file-systems, and 'character' devices,
which cannot. (I seem to recall a paper, perhaps from the Unix BSTJ issue,
which talks about them in some detail.)

The former are those where the underlying physical device has restricted
semantics; they are block-addressable mass storage devices. All access to them
is via the system's block buffer pool, so reads/writes by the user of
arbitrary size and location are possible. 'Character' devices are everything
else.

'Raw' devices are an interface to the devices of 'block' devices which does
not go through the system's buffer pool; I/O operations to them perform DMA
directly to the user process' memory. They are 'character' devices, in the
Unix device taxonomy. The only semantics available are those supported by the
hardware - e.g. seeks only to block boundaries.

So when I say that MINI-UNIX doesn't have 'raw' devices, it just means that
e.g. the RK disk controller device _only_ talks to the Unix block buffer
system; if a user program wants to look at the disk contents, it has to go
via that system.


So, with that in hand, what exactly is the need you forsee for raw devices
in MINI-UNIX?

Also, I've started to work on getting the V6 RL driver to work in MINI-UNIX;
it should have been easy (just delete the charater device interface), but
for some reason it didn't work when I tried it. I'll look at it in more
detail 'soon'.

       Noel


More information about the TUHS mailing list