> already 20 years ago I met a guy (masters degree, university) who never freed dynamically allocated memory. He told me he is 'instantiating a object', but had no idea what an heap is, and what dynamically allocated memory means.
Years ago, I had an new programmer who I just couldn't teach. He never understood the difference between an array and pointer, and apparently couldn't be bothered to learn.
After string him along for three months, I was on my way into his office to fire him when I found out he had quit, but not before he checked a bunch of drek into our source code control system.
I thought I backed all his commits out at the time.
Years later I was running "purify" on our product looking for memory leaks. I found this small utility function that predated the source code control system leaking. This, I thought was odd, as it had been there FOREVER and was well tested. I brought up the source code system and checked it anyhow and found the afore mentioned programmer had checked in one change: he deleted the "free" call in it.
I KNOW what happened. He did something else to corrupt the malloc heap in his code and often this causes a core dump in a subsequent malloc/free call. Apparently this was the place it struck him, so he just deleted the free call there.
So, in:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/mv.c
what's the point of this piece of code:
p = place;
p1 = p;
while(*p++ = *argp3++);
p2 = p;
while(*p++ = *argp4++);
execl("/bin/cp","cp", p1, p2, 0);
I mean, I get that it's copying the two strings pointed to by 'argp3' and
'argp4' into a temporary buffer at 'place', and leaving 'p1' and 'p2' as
pointers to the copies of said strings, but... why is it doing that?
I at first thought that maybe the execl() call was smashing the stack (and
thus the copies pointed to by 'argp3' and 'argp4'), or something, but I don't
think it does that. So why couldn't the code have just been:
execl("/bin/cp","cp", argp3, argp4, 0);
Is this code maybe just a left-over from some previous variant?
Noel
> From: Dave Horsfall <dave(a)horsfall.org>
> I'd like to see it handle "JSR PC,@(SP)+"...
Heh!
But that does point out that the general concept is kind of confused - at
least, if you hope to get a fully working program out the far end. The only
way to do that is build (effectively) a simulator, one that _exactly_
re-creates the effects on the memory and registers of the original program.
Only instead of reading binary machine code, this one's going to read in the
machine language source, and produce a custom simulator, one that can run only
one program - the one fed into it.
Think of it as a 'simulator compiler'! :-)
Noel
>> I was wondering what it would take to convert the v6/v7 basic program
>> into something that can be run today.
>
> Hmmm... If it were C-generated then it would be (somewhat) easy, but it's
> hand-written and hand-optimised... You'd have to do some functional
> analysis on it e.g. what does this routine do, etc.
>
>> Its 2128 lines. It doesn't have that fun instruction in it :)
>
> I know! Say ~2,000 lines, say ~100 people on this list, distributed
> computing to the rescue! That's only 20 lines each, so it ought to be a
> piece of cake :-)
I'm up for that! However, only if the resulting C program can be compiled/run
on a V6/PDP11 again.
Let's assume that reverse engineering a subroutine of 20 lines takes
an hour. That then makes for 100 hours. If 10 people participate and
contribute one hour/routine per week, it will be done by May.
However, the initial analysis of the code architecture is a (time) hurdle.
Paul
PS: the Fortran66 of V6 is also assembler only...
IMO:
1) It kinda did catch on, in the form of macOS, but there was a time
when it was nearly dead as the major vendors moved to System V. For
some reason, Sun was the last major vendor to make the move, but they
caught most of the flack.
2) I think the main reason BSD nearly died, was the AT&T lawsuit. At
the time, Linux appeared to be a safer bet legally.
3) Linux got a reputation as an OS you had to be an expert to install,
so lots of people started it to install it to "prove themselves".
This was sort of true back when Linux came as 2 floppy images, but
didn't remain true for very long.
4) I believe the SCO lawsuit "against Linux" was too little, too late
to kill Linux's first mover advantage in the opensource *ix
department.
5) I think FreeBSD's ports and similar huge-source-tree approaches
didn't work out as well Linux developers contributing their changes
upstream.
Hi all,
Would anyone here be able to help me troubleshoot my qd32 controller? I
have a pdp11/73 that's mostly working, boots 2.11 from rl02 okay, but I
need my big disk to work so I can load the rest of the distro.
I've been following the manual for the qd32 to enter the geometry of my
real working m2333 (jumpered correctly according to the manuals), but when
I load the special command into the qd32's SP register that's supposed to
load the geometry table from the pdp11 memory to the novram, I get a bad
status value from the qd32's SP register and it remains unresponsive when I
try to store the geometry. If I go ahead and try the built-in qd32 format
command, it responds similarly. When I pull in mkfs from tape (vtserver)
and try anyway, despite the failures, to run mkfs on the m2333, I get an
!online error from the standalone unix mkfs. The disk does respond (the
select light flashes and I can hear heads actuating), but without geometry
and format, I'm obviously dead in the water.
Any suggestions on how to proceed?
thx
jake
> Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway?
Symmetry. You unmount what you mount.
A competing model is that of links. Link makes an old file available
under a new name. But you unlink by the new name. Necessarily so,
because there may be many new names for one old file.
This is reminiscent of Don Norman's screed about the unnaturalness
of Unix. He didn't like strcpy because the arguments come in the
opposite order to those of cp. But stcpy is part of C, and in
C the destination of assignment comes before the source. But Norman
didn't rail at C. You pays your money and takes your choice.
Doug
these were in by the time I can along but I was wondering when they got it.
They've also always felt a bit like a thing that did not fit to me. I'm
pretty sure I was not alone, given that the Unix authors worked out a way
to get rid of them in later efforts. I know what came after, in Plan 9;
what came before, in Unix, that led to special files?
We lost computer pioneer John von Neumann on this day in 1957; the "von
Neumann" architecture (stored program etc) is the basis of all modern
computers, and he almost certainly borrowed it from Charles Babbage.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Greg Lehey
>> V3 and earlier still *called* them special files, but it seems they
>> were essentially just magic inode numbers (there was no physical file
>> on disk, just any directory entry with the given inode would be the
>> special file).
> Isn't that still the case?
>From reading the manual page (URL sent earlier), in V3 and before it really
was just an inode _number_ (less than 50, IIRC). The first inode, in the
first disk block after the super-block, was inode #51. This is of course
different from later Versions, where there is an _inode_ for devices, but
still no actual _file_.
Noel
Co-inventor of Unix, he was born on this day in 1943. Just think: without
those two, we'd all be running M$ Windoze and thinking that it's
wonderful (I know, it's an exaggeration, but think about it).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> My experience is that the problems involved in making a program faster are
> often quite interesting and fun to work on. But the problems making things
> fit in a small space are, IMHO, really deadly.
First make things "as simple as possible, but no simpler" (Einstein). Ken and
Dennis not only cut out fat, they also found generalizations that combined
traditionally disparate features, so the new whole was smaller (and more
comprehensible) than the sum of the old parts. The going gets tough in the
presence of constraints on space or time. Steve's perception, I think, is
colored by the experience of facing hard limits on space, but not on time.
Describing one complication of hard time constraints, John Kelly used to
say that the Packard Bell 250 was "the only machine I ever used where
you transfer to a time of day rather than a memory location". (The delay-
line memory had two instruction formats: one was operation + address-of-
next-instruction, the other was just the operation--the next instruction
being whatever came out of the delay line when the operation ended. The
latter mode minimized both execution time and code space, but the attention
one had to pay to time was, to borrow Steve's phrase, "really deadly".)
Design tradeoffs for efficiency pose an almost moral conundrum:
whether to make things fast or make them easy. For example, the
classic Unix kernel typically did table lookup by linear search,
whereas Linux (when I last looked) typically used binary search.
The price of Linux's choice is that one must take care to keep
the tables sorted. Heavy discipline has to be imposed on making
entries and deletions.
Doug
What do you mean plan9 is dead? It's even possible make a facebook post
from inside plan9 nowadays!
https://twitter.com/bigatojj/status/949838932841201664
See vmx(1)
Em 3 de fev de 2018 23:25, "Steve Simon" <steve(a)quintile.net> escreveu:
Hi,
I have to take issue with the “plan9 is dead” statement,
I agree it seems on a downward spiral, but are a few who fight on.
[sent from my plan9]
-Steve
You can use make as much as you like; Go just doesn't need it. You can use
Go to fetch code from internet if you like, or you can do it yourself if
you prefer.
Regarding the "hardwired" directories, you can change it through an
environment variable.
Em 3 de fev de 2018 23:20, "Lyndon Nerenberg" <lyndon(a)orthanc.ca> escreveu:
That's the second endorsement I've seen for Go; I guess I should learn it.
>
In the scheme of "current" languages, Go is pretty good. With two major
caveats, IMO:
1) The build system. It doesn't work with make(1). That makes it a
non-starter for anything other than trivial projects at $WORK. While I
appreciate the arguments for the apparent simplicity of the "go" command,
that doesn't work for us. Which would have been fine, but for the entirely
antagonistic bent they have taken against being able to build Go programs
with make(1). Our build environment entirely precludes Go's promiscuous
insistence on unfettered internet access, and hardwired directory paths.
2) Hardwired directory paths for the development/build environment (see
above).
It seems they have unlearned all the UNIX lessons. Sad, really. I would
love to toss out Python, Ruby, PHP, Perl, et al. And could make the
argument for it, I think. But the build environment will never work in our
shop, therefore Go won't either.
And that ... sucks.
Hi,
Interested in some perspective here since the list has influential Linux
people like Ted Tso.
Linux has been described as influenced by Minix and System V. The Minix
connection is well discussed. The SysV connection something something
Linus had access to a spec manual. But I’d guess reality would be more
gradual — new contributors that liked CSRG BSD would have mostly gravitated
to the continuations in 386/BSDi/Net/Free that were concurrent to early and
formative Linux development.. so there’d be an implicit vacuum of BSD
people for Linux development.
What I am curious about is the continuing ignorance of BSD ideas. Linux
isn’t exactly insular; a lot of critical people and components came much
later on from other SysV flavors (lvm, jfs, xfs, RCU)
The kinds of BSD things I am talking about are ufs, kqueue, jails, pf,
Capsicum. Linux has grown alternatives, but with sometimes willful
ignorance of other technology. It seems clear epoll was not a good design
from the start. Despite jails not being taken to the logical conclusion of
modern containers like zones, the architecture is fundamentally closer
aligned to how people want to securely use containers versus namespaces and
cgroups. And Google ported Capscicum to Linux but it’s basically been
ignored in lieu of nebulous concepts like seccomp. And then there seems to
be outright hostility toward other platforms from the postmodern generation
with things like systemd.
This seems strange to me as BSD people are generally open to other /ideas/,
we have to be careful with Linux code due to license incompatibility, but
the converse is does not seem true either in interest in other ideas or
license hampering code flow.
The history of UNIX is spectacularly successful because different groups
got together at the table and agreeed on the ideas. Is there room for that
in the modern era where Linux is the monopoly OS? The Austin Group is
still a thing but it’s not clear people in any of the Freenix communities
really care about evolving the standards. I get that, but not so much
completely burrying ones head in the sand to what other OSes are doing. Is
there any future for UNIX as an “open system” in this climate or are people
going to go there separate ways?
Regards,
Kevin
We gained John von Neumann on this day in 1903, and if you haven't heard
of him then you are barely human... As computer science goes, he's right
up there with Alan Turing. There is speculation that he knew of Babbage's
work; see
https://cstheory.stackexchange.com/questions/10828/the-relation-between-bab… .
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Sergio Pedraja
> I am very interested in your work exactly for the reasons you explain
We will generally be sending messages about it to the CCTalk list (for
collectors of 'classic' computers), so if you want to be notified about it,
sign up there.
We currently have only wire-wrap prototypes (the FPGA is on an off-the-shelf
daughter-card); we're hoping to produce PCB production versions 'soon'. We do
have the technology for getting PCB's, which we have used for doing 'indicator
panels':
http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html
We have those working (they've been a big help in debugging, actually :-), and
they'll be available too. I don't personally have one of them yet, I'm
_really_ looking forward to watching the lights blink as UNIX boots... :-)
> The only difference is that my PDP-11 is one 23/PLUS. There are some
> differences between this one and the PDP-11/23 and perhaps your emulator
> woudln't work in this PDP-11 model.
No, AFAIK the /23 and /23-PLUS are effectively identical, as far as the QBUS
goes. (Obviously the -PLUS has devices, etc, the plain /23 doesn't, but they
don't enter into whether our board will work with one.)
We also plan at UNIBUS version; the two busses are similar enough that we'll
probably start with a PCB version for that one.
> I will test the working state of my PDP. If all is fine perhaps I could
> help doing with some tests on it.
Sure; use CCTalk.
Noel
As I mentioned recently, Dave Bridgham and I are doing an RK11 emulator (and
soon an RP11, which just will take editing the Verilog a tiny bit) using an
SD card for storage, for heritage computer collectors who want to run their
PDP-11's but don't want to risk a head crash (since replacement heads are now
un-obtainium) - and also for people who have an -11, but no mass storage.
So the last stage was bringing up V6 on a hardware PDP-11/23, using the
emulated RK11, and we were having an issue (which turned out to be partial
block reads/writes not working properly; this has since been fixed, and we
have successfullly booted V6 on the -11/23 with only an SD card).
In the process of debugging that issue, I added logging to the RK driver, and
noticed that in the process of attempting to boot single-user, the system was
trying to do some swapping - two writes, and two reads - before it even tried
doing the fork() to create the shell process, followed by opening /dev/tty8
and doing the exec() of /bin/sh.
This confused me, since both newproc() and expand() have code which uses a
memory-memory copy if there is enough free memory - and on first booting,
there definitely was. Why was it swapping?
So I added some more logging, and the cause turned out that at one point, I
had re-compiled /etc/init - and without thinking about it too hard, had made
it a pure-text program.
And that's what did it: in exec() (called when process 1 tries to exec()
/etc/init), it calls xalloc(), which i) if the text was not already
available, gets together the pure text, and puts a copy on the swap device,
and ii) if the text is not already in core, swaps the rest of the process
out, because, as the code explains:
* if the calling process
* is misplaced in core the text image might not fit.
* Quite possibly the code after "out:" could check to
* see if the text does fit and simply swap it in.
If you're looking at the code, the process doesn't have a data segment at
that point, just the U area; the data will be set up later in the exec()
code, after the call to xalloc() returns, after the process is swapped back
in.
In fact, the process will _never_ have anything other than a U area when in
this code; the only call to xalloc() in the system is immediately preceeded
by an "expand(USIZE)" which throws away everything except the U area.
So I'm contemplating doing what the comment suggests - adding code to check
to see if there's enough memory available to hold the pure text, and if so,
avoiding the swap-out/in of the process' U-only data segment.
If done 'right', it should also be possible to allow avoiding the reading-in
of the text from the swap device, when first exec'ing a pure text...
Probably not as interesting a project as doing the splice() system call was,
but no doubt it will teach me about a corner of the system I don't know very
well (back in the day, doing networking stuff, I was mostly looking at I/O
code).
Although there is potentially a certain amount of amusement in an additional
enhancement, which is trying to make sure there's enough room for both the
text and the data; immediately upon the return from xalloc(), the process is
expanded to have room for the data. Which might involve _another_ swap-out/in
sequence... So perhaps the U area should simply be moved out of the way via a
direct memory-memory copy, rather than swapping it out/in, just before doing
it again!
You are not expected to understand this... :-)
I guess I should first take a look at the PWB1 pure text code, which is
heavily modified from the stock V6, to see what it does - this all may have
already been done there.
Noel
For a while I had been wondering about the origins of a modification to the V6 kernel that places the kernel buffers in a separately mapped area, freeing up space for other things. It is used in some of the early networking code, i.e. both the UoI code and the V6 BBN code (as available on the TUHS Unix Tree).
I came across the following reference in https://www.osti.gov/scitech/servlets/purl/12130675:
“One widely distributed (though undocumented) solution to this hardware limit on the model 40 was a version of Unix by Robert Sidebotham, Faculty of Environmental Design, University of Calgary. His solution was to move the I/O buffers out of kernel space.”
This would explain the modifications being bracketed with "#ifdef UCBUFMOD”.
Some questions for the old hands:
- Was this patch indeed widely known / distributed?
- Widely distributed is not the same as widely used: was it?
Born on this day in 1925, he was a pioneer in human/computer interaction,
and invented the mouse; it wasn't exactly ergonomic, being just a square
box with a button.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
