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

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

[Noel Chiappa]

    > I noticed a place where I used R0 as a temp ... and was being bashed.
    > So I fixed it, and now the shell starts OK, but attempting to do any
    > command (e.g. "echo foo"), things hang

Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I had
to change for the /03 there was pushing the old PS, and that and the temp I
had to push got intermangled.)

Anyway, with that fixed, the /03 Mini-Unix works now. The old user command
binaries seem to work OK on the /03; not that I've tried the all, but the ones
I have tried (including the C compiler) all worked. They all should all work
(there's nothing in user code that's model-dependent). I have tweaked the
shell (to allow 'cd') and init (to get rid of the annoying long rights
message), but that's all.

The latest, greatest mch.s is uploaded:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s

Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor
changes (to remove direct rerferences to the PS; they now call getps() and
putps() for that), and main.c has minor changes to work when there's no KW11
or switch register, really the only file with significant changes for the /03
is mch.s. It's the only one where the object code is model-dependent; all the
other changed ones use the same object code for all CPU models.

I'll put up a Web page with details, links to sources, etc, 'soon'.


A couple of other things.

Mini-Unix has removed 'raw' devices (not sure why, probably seemed un-needed),
so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins. Minimal
tweaks needed, though; just remove the read and write routines, I think.

If there was a real use for 'raw' devices, they could probably be added back,
but physio() would have to be modified (simplified). Not sure if anything else
special would be needed; the process can't be swapped while raw I/O is
ongoing, and so on Mini-Unix no other process could run. Probably OK, but
needs to be checked.

I recommend that everyone trying to run Mini-Unix on a hardware /03 invest in
a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS
emulator out of the build, which will save some space, and allow more room for
device drivers. I added kernel printf() into the build, to help with
debugging, but it can be removed to save space.

You can change the system to use more room for the kernel (see the Mini-Unix
docs), but that involves re-linking _every single user command_, including the
shell and init. Not recommended.

      Noel

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

[Jay Logue]

On 10/10/2020 4:29 PM, Noel Chiappa wrote:

Great work, Noel!

 > The latest, greatest mch.s is uploaded:

Are your other changes available anywhere?  Also, I was wondering if it 
might be useful to have a github repo with these changes.  I'd be happy 
to help set this up.

--Jay

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

[Paul Riley]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

Noel,




*Mini-Unix has removed 'raw' devices (not sure why, probably seemed
un-needed),so other disk drivers (e.g. the RL11 driver) aren't straight
drop-ins. Minimaltweaks needed, though; just remove the read and write
routines, I think.*

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

Paul


*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Sun, 11 Oct 2020 at 07:31, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > I noticed a place where I used R0 as a temp ... and was being bashed.
>     > So I fixed it, and now the shell starts OK, but attempting to do any
>     > command (e.g. "echo foo"), things hang
>
> Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I
> had
> to change for the /03 there was pushing the old PS, and that and the temp I
> had to push got intermangled.)
>
> Anyway, with that fixed, the /03 Mini-Unix works now. The old user command
> binaries seem to work OK on the /03; not that I've tried the all, but the
> ones
> I have tried (including the C compiler) all worked. They all should all
> work
> (there's nothing in user code that's model-dependent). I have tweaked the
> shell (to allow 'cd') and init (to get rid of the annoying long rights
> message), but that's all.
>
> The latest, greatest mch.s is uploaded:
>
>   http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s
>
> Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor
> changes (to remove direct rerferences to the PS; they now call getps() and
> putps() for that), and main.c has minor changes to work when there's no
> KW11
> or switch register, really the only file with significant changes for the
> /03
> is mch.s. It's the only one where the object code is model-dependent; all
> the
> other changed ones use the same object code for all CPU models.
>
> I'll put up a Web page with details, links to sources, etc, 'soon'.
>
>
> A couple of other things.
>
> Mini-Unix has removed 'raw' devices (not sure why, probably seemed
> un-needed),
> so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins.
> Minimal
> tweaks needed, though; just remove the read and write routines, I think.
>
> If there was a real use for 'raw' devices, they could probably be added
> back,
> but physio() would have to be modified (simplified). Not sure if anything
> else
> special would be needed; the process can't be swapped while raw I/O is
> ongoing, and so on Mini-Unix no other process could run. Probably OK, but
> needs to be checked.
>
> I recommend that everyone trying to run Mini-Unix on a hardware /03 invest
> in
> a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS
> emulator out of the build, which will save some space, and allow more room
> for
> device drivers. I added kernel printf() into the build, to help with
> debugging, but it can be removed to save space.
>
> You can change the system to use more room for the kernel (see the
> Mini-Unix
> docs), but that involves re-linking _every single user command_, including
> the
> shell and init. Not recommended.
>
>       Noel
>

[-- Attachment #2: Type: text/html, Size: 4357 bytes --]

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

[Dave Horsfall]

On Mon, 12 Oct 2020, Paul Riley wrote:

> Mini-Unix has removed 'raw' devices (not sure why, probably seemed 
> un-needed),

If it's relevant FreeBSD hasn't had raw devices for ages (not needed?); I 
don't know about Penguin/OS because my Debian box is off the air right 
now (and my Ubuntu box's video is beyond repair).

-- Dave

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

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Sun, Oct 11, 2020, 6:55 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 12 Oct 2020, Paul Riley wrote:
>
> > Mini-Unix has removed 'raw' devices (not sure why, probably seemed
> > un-needed),
>
> If it's relevant FreeBSD hasn't had raw devices for ages (not needed?);


No longer needed. Phk removed the need for different types of devices for
disks as part of the geom work. It required, though, that unaligned I/O on
the block device worked...

I
> don't know about Penguin/OS because my Debian box is off the air right
> now (and my Ubuntu box's video is beyond repair).
>

Last I checked, linux still had both.

Warner

>

[-- Attachment #2: Type: text/html, Size: 1467 bytes --]

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

[Andrew Warkentin]

On 10/11/20, Warner Losh <imp@bsdimp.com> wrote:
>
> Last I checked, linux still had both.
>
I don't think I've ever seen a Linux distribution with separate raw
block device files.

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

[Arthur Krewat]

On 10/11/2020 9:56 PM, Warner Losh wrote:
> unaligned I/O on the block device
Sorry, I have to laugh... isn't that an oxymoron? ;)

But then, I'm more of a BLKI/BLKO kinda guy (TOPS-10).

ak

[TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems

[Bakul Shah]

On Oct 12, 2020, at 9:57 AM, Arthur Krewat <krewat@kilonet.net> wrote:
> 
> On 10/11/2020 9:56 PM, Warner Losh wrote:
>> unaligned I/O on the block device
> Sorry, I have to laugh... isn't that an oxymoron? ;)

Actually there are no *block* devices in FreeBSD.
And while raw device files such as /dev/r<blkdev>
no longer exist, it is the block devices (with
their buffering etc.) that are gone. Only raw devices
exist now.

And FreeBSD raw disk device drivers don't allow
unaligned I/O access. Nor should they paper over
what is not allowed by the underlying device. Try

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

unsigned char buf[1024];

int main(int c, char**v) {
        char* a = c > 1? v[1] : "1";
        off_t off = (off_t)strtoull(a, 0, 0);
        ssize_t r = pread(0, buf, sizeof buf, off);
        if (r < 0) { perror("read"); return 1; }
        for (int i = 0; i < 4; i++) printf(" %02x", buf[i]);
        printf("\n");
        return 0;
}

Re: [TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Mon, Oct 12, 2020 at 11:47 AM Bakul Shah <bakul@iitbombay.org> wrote:

> On Oct 12, 2020, at 9:57 AM, Arthur Krewat <krewat@kilonet.net> wrote:
> >
> > On 10/11/2020 9:56 PM, Warner Losh wrote:
> >> unaligned I/O on the block device
> > Sorry, I have to laugh... isn't that an oxymoron? ;)
>
> Actually there are no *block* devices in FreeBSD.
> And while raw device files such as /dev/r<blkdev>
> no longer exist, it is the block devices (with
> their buffering etc.) that are gone. Only raw devices
> exist now.
>

There's still the buffer cache that does do buffering on the devices... but
it's a different kind of buffering than traditional kernels.  but you're
right, only the cdevs are plumbed down, not the bdevs.


> And FreeBSD raw disk device drivers don't allow
> unaligned I/O access. Nor should they paper over
> what is not allowed by the underlying device. Try
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> unsigned char buf[1024];
>
> int main(int c, char**v) {
>         char* a = c > 1? v[1] : "1";
>         off_t off = (off_t)strtoull(a, 0, 0);
>         ssize_t r = pread(0, buf, sizeof buf, off);
>         if (r < 0) { perror("read"); return 1; }
>         for (int i = 0; i < 4; i++) printf(" %02x", buf[i]);
>         printf("\n");
>         return 0;
> }
>

I meant something different about 'unaligned' access. I mean that the
buffers you read the data into needn't be page aligned. That causes a fair
amount of hair in the lower layers where I spend much of my time...

You are correct you have to read them on an LBA boundary.

Warner

[-- Attachment #2: Type: text/html, Size: 2440 bytes --]

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

[Michael Huff]

On 10/11/2020 4:53 PM, Dave Horsfall wrote:
> On Mon, 12 Oct 2020, Paul Riley wrote:
>
>> Mini-Unix has removed 'raw' devices (not sure why, probably seemed 
>> un-needed),
>
> If it's relevant FreeBSD hasn't had raw devices for ages (not 
> needed?); I don't know about Penguin/OS because my Debian box is off 
> the air right now (and my Ubuntu box's video is beyond repair).
>
> -- Dave

I suspect it's really irrelevant, but NetBSD (as of version 9) still 
uses raw devices; at least for fsck (I have no idea about anywhere else).

I haven't tried; but it wouldn't surprise me to find that OpenBSD uses 
raw devices too.