Greetings,
What's the canonical source for patches to 2.9BSD and 2.11BSD?
I see we have 2.11BSD patch 469 dated last month in the archive. Where does
it come from? Has anybody climbed the hill to import all the patches into a
git repo? I've found some mirrors, but moe.2bsd.org has been down for me
for ages... How does Warren keep things up to date?
I also have a (maybe faulty) memory of a similar series of patches to
2.9BSD because it was the last BSD to support non-split I&D space machines.
yet a quick google search turns up nothing other than a set of patches
dated August 1985 (also in our archive) and some changes for variants of
hardware (pro, mscp). Is that it?
Warner
I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
What's the current status of net/2?
I ask because I have a FreeBSD 1.1.5.1 CVS repo that I'd like to make
available. Some of the files in it are encumbered, though, and the
University of California has communicated that fact. But what does that
actually mean now that V7 has been released and that's what the files were
based on? Are they no longer encumbered?
Warner
> From: Paul Guertin
> I teach math in college ... Sometimes, during an exam, a student who
> forgot to bring their calculator will ask if they can borrow mine I
> always say "sure, but you'll regret it" and hand them the calculator
> After wasting one or two minutes, they give it back
Maybe I'm being clueless/over-asking, but to me it's appalling that any
college student (at least all who have _any_ math requirement at all; not sure
how many that is) doesn't know how an RPN calculator works. It's not exactly
rocket science, and any reasonably intelligent high-schooler should get it
extremely quickly; just tell them it's just a representational thing, number
number operator instead of number operator number. I know it's not a key
intellectual skill, but it does seem to me to be part of comon intellectual
heritage that everyone should know, like musical scales or poetry
rhyming. Have you ever considered taking two minutes (literally!) to cover it
briefly, just 'someone tried to borrow my RPN calculator, here's the basic
idea of how they work'?
Noel
There is an interesting paper that Dennis Ritchie and Dave Presotto wrote, “Interprocess Communication in the Ninth Edition Unix System” (https://www.bell-labs.com/usr/dmr/www/ipcpaper.html <https://www.bell-labs.com/usr/dmr/www/ipcpaper.html>).
This appears to be an update of a paper that they wrote in 1985, “Interprocess Communication in the Eighth Edition Unix System”. This earlier paper is hard to find.
Anybody on this list who has it on hand?
The C in v7 is, canonically, the language described in K&R, right?
I must be doing something dumb.
I am getting Webb Miller’s “s” editor built there, and I am down to one function.
/* chop_arg - chop a function's argument to a maximum length */
static chop_arg(fcn, arg, maxlen)
int (*fcn)();
int maxlen;
char *arg;
{
char save;
save = arg[maxlen];
arg[maxlen] = '\0';
fcn(arg);
arg[maxlen] = save;
}
This doesn’t like the function pointer.
$ cc -c choparg.c
choparg.c:11: Call of non-function
So, uh, what is the obvious thing I am missing? How am I supposed to be passing function pointers in the C compiler that comes with v7?
Adam
This time looking into non-blocking file access. I realise that the term has wider application, but right now my scope is “communication files” (tty’s, pipes, network connections).
As far as I can tell, prior to 1979 non-blocking access did not appear in the Spider lineage, nor did it appear in the NCP Unix lineage. First appearance of non-blocking behaviour seems to have been with Chesson’s multiplexed files where it is marked experimental (an experiment within an experiment, so to say) in 1979.
The first appearance resembling the modern form appears to have been with SysIII in 1980, where open() gains a O_NDELAY flag and appears to have had two uses: (i) when used on TTY devices it makes open() return without waiting for a carrier signal (and subsequent read() / write() calls on the descriptor return with 0, until the carrier/data is there); and (ii) on pipes and fifo’s, read() and write() will not block on an empty/full pipe, but return 0 instead. This behaviour seems to have continued into SysVR1, I’m not sure when EAGAIN came into use as a return value for this use case in the SysV lineage. Maybe with SysVR3 networking?
In the Research lineage, the above SysIII approach does not seem to exist, although the V8 manual page for open() says under BUGS "It should be possible [...] to optionally call open without the possibility of hanging waiting for carrier on communication lines.” In the same location for V10 it reads "It should be possible to call open without waiting for carrier on communication lines.”
The July 1981 design proposals for 4.2BSD note that SysIII non-blocking files are a useful feature and should be included in the new system. In Jan/Feb 1982 this appears to be coded up, although not all affected files are under SCCS tracking at that point in time. Non-blocking behaviour is changed from the SysIII semantics, in that EWOULDBLOCK is returned instead of 0 when progress is not possible. The non-blocking behaviour is extended beyond TTY’s and pipes to sockets, with additional errors (such as EINPROGRESS). At this time EWOULDBLOCK is not the same error number as EGAIN.
It would seem that the differences between the BSD and SysV lineages in this area persisted until around 2000 or so.
Is that a fair summary?
- - -
I’m not quite sure why the Research lineage did not include non-blocking behaviour, especially in view of the man page comments. Maybe it was seen as against the Unix philosophy, with select() offering sufficient mechanism to avoid blocking (with open() the hard corner case)?
In the SysIII code base, the FNDELAY flag is stored on the file pointer (i.e. with struct file). This has the effect that the flag is shared between processes using the same pointer, but can be changed in one process (using fcntl) without the knowledge of others. It seems more logical to me to have made it a per-process flag (i.e. with struct user) instead. In this aspect the SysIII semantics carry through to today’s Unix/Linux. Was this semantic a deliberate design choice, or simply an overlooked complication?
Does anybody have any good resources on the history of the popularity of C?
I'm looking for data to resolve a claim that C is so prolific and
influential because it's so easy to write a C compiler.
Tyler
