I am sure I remember a machine which had this (which would have been running a BSD 4.2 port). Is my memory right, and what was it for (something related to swap?)?
It is stupidly hard to search for (or, alternatively, there are just no hits and the memory is false).
--tim
> From: Dave Horsfall <dave(a)horsfall.org>
> I am constantly bemused by the number of "setuid root" commands, when a
> simple "setgid whatever" will achieve the same task.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys4.c
/*
* Unlink system call.
*/
unlink()
{ ...
if((ip->i_mode&IFMT)==IFDIR && !suser())
goto out;
For many things, yes. Not in this particular case.
Noel
Hello all,
I recently wrote a 3B2/400 simulator on the SIMH platform. It emulates the core system board and peripherals quite well, but I am now turning my attention to the emulating the 3B2 IO expansion boards. The first board I've emulated is the PORTS 4-port serial card, which came together fairly easily because I have the full source code for the SVR3 driver.
Other cards, though, are more challenging because I do not have source code for them. I would like to emulate the following two cards:
* The CTC cartridge tape controller
* The NI 10base5 Ethernet controller
Of these two, I have partial source code for the CTC driver (ct.c, ct.h, ct_lla.h, ct_deps.h), but I am missing a core file (ct_lla.c) that would greatly help explain what's going on. And I have NO source code at all for the NI driver.
There was a source code package for the NI driver called "nisrc", probably distributed on tape or floppy, but I have never seen it.
If you or anyone you know happens to have these source packages and a way to get at them, could you please let me know? I would be grateful.
-Seth
--
Seth Morabito
web(a)loomcom.com
> Google didn't seem to turn up much on TML
Perhaps because there was no TML. I suspect you mean TMG,
which I implemented from scratch, based on Bob McClure's
original, on both PDP 8 and PDP 11 Unix. Bob Morris and
I used it to make EPL, the "early PL/I" compiler for
Multics.
Off topic, but TMG on the GE 635, usedto buld Multics
got there via quite an Odyssey. Bob McClure created it
for the CDC 1604. He tranliterated it by hand from 1604
assembly language to IBM 7090 and sent the green coding
sheets to me. Debugging it was an unusual exercise: I
knew the logic was right; allI had to do was ferret
out mistranslations. The most prevalant problem was
confusion between CLA (signed load) and CAL (unsigned).
When we decided to do EPL, Clem Pease mechanically
reproduced a 7090 inside a Ge 635, by defining 7090
instructions as macros--sometimes quite hairy, but
they worked.
Doug
On 2018-04-25 16:39, Tom Ivar Helbekkmo<tih(a)hamartun.priv.no> wrote:
>
> Ron Natalie<ron(a)ronnatalie.com> writes:
>
>> RK05’s were 4872 blocks. Don’t know why that number has stuck with
>> me, too many invocations of mkfs I guess. Oddly, DEC software for
>> some reason never used the last 72 blocks.
> I guess that's because they implemented DEC Standard 144, known as
> bad144 in BSD Unix. It's a system of remapping bad sectors to spares at
> the end of the disk. I had fun implementing that for the wd (ST506)
> disk driver in NetBSD, once upon a time...
Uh... DEC STD 144 does not have anything to do with remapping bad blocks
to replacement good blocks. DEC STD 144 describes how a media stores
known bad blocks on a disk, so that file system initialization can then
take whatever action needed to that these blocks are not used by
anything. In RSX (and VMS), they will be included in a file called
BADBLK.SYS, and thus be perceived as "used".
bad144 in NetBSD will keep the a table in memory for such disks, and
"skip" blocks listed in the list as bad, meaning all other blocks gets
shifted. So it sortof do a remapping to good blocks by extending the
used blocks, and does not allocate anything at the end of the disk per
se. However, that is a Unix specific solution. OS/8 had a similar
solution for RL01 and RL02 drives, but not RK05 (as RK05 disks don't
follow DEC STD 144.)
I don't know exactly why DEC left the last three tracks unused. Might
have been for diagnostic tools to have a scratch area to play with.
Might have been that those tracks were found to be less reliable. Or
maybe something completely different. But it was not for bad block
replacement, as DEC didn't even do that on RK05 (or more or less in
general at all before MSCP. MSCP, by the way, does not use DEC STD 144.)
Something Unix and other implementations usually miss with DEC STD 144
is that there are actually two tables with bad blocks defined by the
standard. There is the manufacturer defined bad blocks, which all
software seems to know and deal with, and there are the user defined bad
blocks, which are supposed to be where all bad blocks that develop after
manufacture are supposed to be placed. Lots of software does not deal
with this second list. In addition, you also have the pack serial number
and some stuff defined by DEC STD 144, which is also recorded on the
last track, where the bad block lists also are stored.
Note that this information is supposed to be on the last track, meaning
you cannot use the scheme Unix uses to remap bad blocks, unless you keep
some blocks before the last track unallocated.
The ultimate irony was when I discovered that bad144 under NetBSD was
only built for x86 machine, and not being built for VAX, which is the
only architecture supported which actually have real disks which follow
the DEC STD 144. But that was corrected about 20 years ago now (time flies).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Johnny Billquist
> if you hadn't had the ability for them to be less than 8K, you wouldn't
> even try that argument.
Well, the 1972 edition of the -11/45 processor handbook called them segments.. :-)
I figure some marketing droid found out that 'paging' was the new buzzword, and
changed the name... :-) :-)
Noel
On 2018-04-26 00:55, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote:
> > From: Johnny Billquist
>
> > PDP-11 have 8K pages.
>
> Segments.:-) (This is an old argument between Johnny and me, I'm not trying
> to re-open it, just yanking his chain...:-)
:-)
And if you hadn't had the ability for them to be less than 8K, you
wouldn't even try that argument. But just because the hardware gives you
some extra capabilities, you suddenly want to associate them with a
technology that really gives you much less capabilities.
Either way, the next page always start at the next 8K boundary.
> > On a PDP-11, all your virtual memory was always there when the process
> > was on the CPU
>
> In theory, at least (I don't know of an OS that made use of this), didn't the
> memory management hardware allow the possibility to do demand-paging? I note
> that Access Control Field value 0 is "non-resident".
Oh yes. You definitely could do demand paging based on the hardware
capabilities.
> Unix kinda-sorta used this stuff, to automatically extend the stack when the
> user ran off the end of it (causing a trap).
Ah. Good point. The same is also true for brk, even though that is an
explicit request to grow your memory space at the other side.
DEC OSes had the brk part as well, but stack was not automatically
extended if needed. DEC liked to have the stack at the low end of
address space, and have hardware that trapped if the stack grew below
400 (octal).
> > you normally did not have demand paging, since that was not really
> > gaining you much on a PDP-11
>
> Especially on the later machines, with more than 256KB of hardware main
> memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).
Yeah, it would actually probably have been more useful on an 11/45.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Johnny Billquist
> PDP-11 have 8K pages.
Segments. :-) (This is an old argument between Johnny and me, I'm not trying
to re-open it, just yanking his chain... :-)
> On a PDP-11, all your virtual memory was always there when the process
> was on the CPU
In theory, at least (I don't know of an OS that made use of this), didn't the
memory management hardware allow the possibility to do demand-paging? I note
that Access Control Field value 0 is "non-resident".
Unix kinda-sorta used this stuff, to automatically extend the stack when the
user ran off the end of it (causing a trap).
> you normally did not have demand paging, since that was not really
> gaining you much on a PDP-11
Especially on the later machines, with more than 256KB of hardware main
memory. Maybe it might have been useful on the earlier ones (e.g. the -11/45).
Noel
On 2018-04-25 23:14, Paul Winalski <paul.winalski(a)gmail.com> wrote:
> On 4/25/18, Ronald Natalie
> <ron(a)ronnatalie.com> wrote:
>> The fun argument is what is Virtual Memory. Typically, people align that
>> with paging but you can stretch the definition to cover paging.
>> This was a point of contention in the early VAX Unix days as the ATT (System
>> III, even V?) didn’t support paging on the VAX where as BSD did.
> In my book, virtual memory is any addressing scheme where the
> addresses that the program uses are different from the physical memory
> addresses. Nowadays most OSes use a scheme where each process has its
> own virtual address space, and virtual memory is demand-paged from
> backing store on disk. But there have been other schemes.
Yeah...
> Some PDP-11 models had a virtual addressing feature called PLAS
> (Program Logical Address Space). The PDP-11 had 16-bit addressing,
> allowing for at most 64K per process. To take advantage of physical
> memory larger than 64K, PLAS allowed multiple 64K virtual address
> spaces to be mapped to the larger physical memory. Sort of the
> reverse of the usual virtual addressing scheme, where there is more
> virtual memory than physical memory.
Note that PLAS is not a PDP-11 hardware thing. PLAS was the name for the
mechanism provided by the OS for applications to be able to access more
than 64K of memory while still be limited by the virtual address space
limit of 64K.
PLAS is in one way very similar to mmap, except that it's not backed by
a file. But you create a memory region though the OS (giving it a name
and a size, which can be more than 64K), and then you can map to it,
specifying the offset into it and window size, as well as where to map
to in your virtual address space.
This is realized by just using the pages of the MMU of the PDP-11 map to
different parts and things.
Any OS that had the PLAS capability by necessity had to have an MMU,
which was the hardware part that allowed this to be implemented.
So, all PDP-11s with an MMU could allow the OS running on it to provide
the PLAS capabilities.
A PDP-11 in general is "reversed" in that the physical address space is
much larger than the virtual one. Although, the same was also true on
the VAX in the last iteration where the NVAX implementation allowed for
a 34 bit physical address, while the virtual address space was still
only 32 bits.
But that doesn't make the virtual memory any less virtual.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
> From: Johnny Billquist
> I don't know exactly why DEC left the last three tracks unused. Might
> have been for diagnostic tools to have a scratch area to play with.
> Might have been that those tracks were found to be less reliable. Or
> maybe something completely different. But it was not for bad block
> replacement, as DEC didn't even do that on RK05
The "pdp11 peripherals handbook" (1975 edition at least, I can't be bothered
to check them all) says, for the RK11:
"Tracks/surface: 200+3 spare"
and for the RP11:
"Tracks/surface: 400 (plus 6 spares)"
which sounds like it could be for bad block replacement, but the RP11-C
Maintenance Manual says (pg. 3-10) "the inner-most cylinders 400-405 are only
used for maintenance".
Unix blithely ignored all that, and used every block available on both the
RK11 and RP11.
Noel
