> 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
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
[-- 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 --]
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
[-- 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 --]
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.
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
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;
}
[-- 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 --]
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.