The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-10 23:29 Noel Chiappa
  2020-10-11  2:30 ` Jay Logue
  2020-10-11 23:24 ` Paul Riley
  0 siblings, 2 replies; 10+ messages in thread
From: Noel Chiappa @ 2020-10-10 23:29 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
@ 2020-10-11  2:30 ` Jay Logue
  2020-10-11 23:24 ` Paul Riley
  1 sibling, 0 replies; 10+ messages in thread
From: Jay Logue @ 2020-10-11  2:30 UTC (permalink / raw)
  To: tuhs

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
  2020-10-11  2:30 ` Jay Logue
@ 2020-10-11 23:24 ` Paul Riley
  2020-10-12  0:53   ` Dave Horsfall
  1 sibling, 1 reply; 10+ messages in thread
From: Paul Riley @ 2020-10-11 23:24 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-11 23:24 ` Paul Riley
@ 2020-10-12  0:53   ` Dave Horsfall
  2020-10-12  1:56     ` Warner Losh
  2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff
  0 siblings, 2 replies; 10+ messages in thread
From: Dave Horsfall @ 2020-10-12  0:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  0:53   ` Dave Horsfall
@ 2020-10-12  1:56     ` Warner Losh
  2020-10-12  2:09       ` Andrew Warkentin
  2020-10-12 16:57       ` Arthur Krewat
  2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff
  1 sibling, 2 replies; 10+ messages in thread
From: Warner Losh @ 2020-10-12  1:56 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  1:56     ` Warner Losh
@ 2020-10-12  2:09       ` Andrew Warkentin
  2020-10-12 16:57       ` Arthur Krewat
  1 sibling, 0 replies; 10+ messages in thread
From: Andrew Warkentin @ 2020-10-12  2:09 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  1:56     ` Warner Losh
  2020-10-12  2:09       ` Andrew Warkentin
@ 2020-10-12 16:57       ` Arthur Krewat
  2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
  1 sibling, 1 reply; 10+ messages in thread
From: Arthur Krewat @ 2020-10-12 16:57 UTC (permalink / raw)
  To: tuhs

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12 16:57       ` Arthur Krewat
@ 2020-10-12 17:46         ` Bakul Shah
  2020-10-12 17:54           ` Warner Losh
  0 siblings, 1 reply; 10+ messages in thread
From: Bakul Shah @ 2020-10-12 17:46 UTC (permalink / raw)
  To: tuhs

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;
}


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
@ 2020-10-12 17:54           ` Warner Losh
  0 siblings, 0 replies; 10+ messages in thread
From: Warner Losh @ 2020-10-12 17:54 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- 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 --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  0:53   ` Dave Horsfall
  2020-10-12  1:56     ` Warner Losh
@ 2020-10-18 20:42     ` Michael Huff
  1 sibling, 0 replies; 10+ messages in thread
From: Michael Huff @ 2020-10-18 20:42 UTC (permalink / raw)
  To: tuhs


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.




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-10-18 20:43 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
2020-10-11  2:30 ` Jay Logue
2020-10-11 23:24 ` Paul Riley
2020-10-12  0:53   ` Dave Horsfall
2020-10-12  1:56     ` Warner Losh
2020-10-12  2:09       ` Andrew Warkentin
2020-10-12 16:57       ` Arthur Krewat
2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
2020-10-12 17:54           ` Warner Losh
2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git