Subject: Mini-snapshot report
To: None <current-users@NetBSD.ORG>
From: Alistair G. Crooks <firstname.lastname@example.org>
Date: 10/23/1995 04:30:42
I don't have time for a Snapshot Report, but there seems to be a lot
that's happened recently, so I thought I'd try to commit these thoughts
whilst I was still semi-coherent. Apologies for the tardiness of this,
especially in run-up-to-release mode.
1. The domestic.tar.gz files are being made in
where it's very easy for non-US access to just grab the domestic files.
The old ftp.netbsd.org used to put domestic in a different directory.
Could something be done about this one, please?
2. Kudos to the importers of the timezone info, and anyone who has
anything to do with it. The British clocks changed back from daylight
savings time yesterday. This is written on a NeXTstation, and NeXTSTEP 3.3
has predicatably not changed its clock. Solaris 2.4 has also failed
to change its clock. However, the two NetBSD/i386s (both 1.1_ALPHAs)
are the only machines on this network that now show the correct time.
3. The sources for vat have now been released. These are alpha sources,
though. Anyway, more info follows:
> From: email@example.com (Steven McCanne)
> Message-Id: <199510192053.NAA08825@ell.ee.lbl.gov>
> To: firstname.lastname@example.org
> Subject: vat-4.0 alpha test
> Date: Thu, 19 Oct 95 13:53:17 PDT
> A source release of version 4.0 of the LBNL audio tool, vat,
> is available for alpha-test. This version of vat conforms to
> the final (RTP-7) Internet Draft for the IETF AVT Real Time
> Transport protocol. We've made vat-4 upwards compatible
> with vat-3; i.e., it is a drop-in replacement for vat-3 and
> by default will come up speaking the old vat protocol.
> However, vat-4 accepts a "-r" flag or "Vat.sessionType: rtp"
> Xresource to support sessions using the RTP protocol. RTP is
> far superior to the original vat protocol and we hope it will
> soon become the default but in the interim we have to figure
> out the right sequence of tool deployment and sd/sdr changes to
> coordinate an orderly transition between the two protocols.
> This alpha-test is intended for sites who are interested in fielding
> these new releases and are willing to debug and report problems.
> Vat's internal architecture has changed substantially in the last
> few weeks (leveraging off the RTPv2 and tcl/c++ framework from vic),
> and we expect that it will be a few more weeks before the release
> If you're interested, pointers to ftp directories etc. can be found in:
> URL http://www-nrg.ee.lbl.gov/vat/alpha-test.html
> Installation and overview material on vat is in:
> URL http://www-nrg.ee.lbl.gov/vat/
> Please direct vat-related correspondence to email@example.com (which includes
> only the developers and is not distributed beyond our site), and thanks
> for any help with the alpha-test.
> Steven McCanne (firstname.lastname@example.org)
> Van Jacobson (email@example.com)
> Network Research Group (URL http://www-nrg.ee.lbl.gov/)
> Lawerence Berkeley National Laboratory
4. There's a whole lot of discussion going on on the FreeBSD hacker's
list with respect to kernel threads, and implementations of Plan9's
rfork mechanism (upon which the smart money seems to be betting).
> From: "Ron G. Minnich" <rminnich@Sarnoff.COM>
> Date: Fri, 20 Oct 1995 09:10:43 -0400 (EDT)
> Subject: Re: NetBSD/FreeBSD (pthreads)
> I implemented a simple version of plan9 rfork() a little while ago (well,
> a year ago). You could rfork and end up with shared data space and file
> table. I also implemented a very simple lock/unlock primitive that was
> far more efficient than system v semaphores, since in the common case
> (no contention for a lock) there's no jump to the kernel to wake up
> other procs when you acquire or free a lock. Between these two things you
> can do a lot: share data, share locked structures, share open files, etc.
> I can do all of what i commonly do with kernel threads on, e.g., Irix. In
> fact I implemented a simple user-space distributed shared memory with
> these basic parts: on sgi's i used their kernel threads/kernel mutex
> code, on freebsd i used rfork/lock code i built.
> For my money this is about as good as kernel threads. There's not the
> additional complexity in the kernel (have you ever seen what LWP did to
> sunos? No? good.).
> This code has been available gratis for a year. I can't convince anyone
> to pull it into core for netbsd or freebsd, but I'll make the offer
> again: you want it, let me know. The code, btw, is less than 100 lines
> for each change. In fact the fastlock code is something like 25 lines.
> I've implemented them as LKMs and directly as part of the kernel.
> Ron Minnich |Like a knife through Daddy's heart:
> firstname.lastname@example.org |"Don't make fun of Windows, daddy! It takes care
> (609)-734-3120 | of all my files and it's reliable and I like it".
[The Plan 9 folks report that rfork is a win - there are very rarely
two occurences of rfork in their code with the same resource flags.
For more information on the Plan9 stuff, see
And if you're interested in Plan9, there's an interesting effort
called VSTa, that does a lot of Plan9y things. GPLed, though. If
you're interested, mail me for more info. -agc ]
5. Speaking of FreeBSD, there's now FreeBSD compatibility for the -i386
folks. I've compiled it into a kernel, but haven't yet tested it, mainly
because I don't have any FreeBSD binaries that I desperately need. That
may change if I have my brain removed, and start to use Motif, but I'm
saving that dubious pleasure for my retirement.
6. There's a new parallel make environment now. Unfortunately, the
latest tar_files I picked up don't have the changes in them (are they
for post-1.1 use only?), but I'd like to try to use them when they're
there and working. Typically, top during a build of a kernel shows
rather a lot of idle time, so it'd be nice to use those cycles.
7. -sparc people, pk's fixed a bug in usleep, that may have consequences
for you - if you were getting core-dumps from such programs as your
X server, you'd be advised to get -current now.
8. If you're behind on -current, the new regime at netbsd.warped.com
makes daily tar_files of all the sources. Thanks, guys - this is
9. Someone asked that the timeout be upped for slower SCSI devices
like M-O discs. I'd just like to second this - can't we do something
with the SCSI_DELAY config option, which could be used to multiply
the timeout value, and, if not set, takes the value 1?
10. For the -i386 people, can someone tell me if 1.1 will have separate
kcaha and kcbt floppies, or has the co-existence problem been solved?
And what's happening about the PCMCIA stuff, and bounce-buffers?
I know everyone's busy, but you've got a team of able testers out here.
11. What are the long-term plans for NetBSD? Are we going to see a
merged VM/buffer cache?
12. I'm planning to be out in the Bay Area at the end of January 1996.
If anyone's interested in getting together, please drop me mail.
13. It's official - the upgrade instructions no longer work for the
latest tar_files. The main problem seems to be bootstrapping make, as
the old make can't understand the new /usr/share/mk/sys.mk conditionally
set rules (CFLAGS?= -O etc). I've upgraded a Gateway 2000 laptop over the
last week, and found the best way is to use a binary snapshot, and then
compile the source. Bummer, but 1.1 seems just around the corner, so
it's not that bad.
Alistair G. Crooks (email@example.com) +44 125 234 6377
Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK.
[These are only my opinions, and certainly not those of Amdahl Corporation]