Hiten Pandya added support for “Allied Telesis SIC-AT” boards, merged from FreeBSD. A ‘SIC-AT’ appears to be a networking card from a Japanese company.
Bill Huey (hui) pointed out that the “RCU” Matt Dillon has been talking about in his recent epiphany is “Read-Copy-Update”, mentioned on this page.
Joerg Sonnenberger warned that his NEWCARD patch will go in Tuesday. Further driver work is needed, but nothing should break outright.
Joerg Sonnenberger committed a change to
mount that allows you to specify mounting options when doing ‘
mount -a. Chris Pressey put it together from FreeBSD code.
Matt Dillon was answering a question from Bosko Milekic that caused him to have a realization on how to improve token-handling in both single and multiple CPU situations, with apparently significant performance benefits. I’m pasting his post to .kernel here:
“Not entirely. First, please note that the current token implementation does not work very well… it’s a mess to use because cpu #B can steal away cpu #A’s token by sending cpu #A an IPI message requesting the token. This means cpu #A has to be in a critical section to ‘protect’ the token, and must re-acquire the token (in case it was lost) after it blocks.
After thinking about this quite a bit I have come up with a solution that, in a moment of enlightment, would make our tokens operate like self-contained little RCU implementations (superior to Linux’s implementation, in fact!).
I intend to fix our tokens by not allowing an IPI to steal a token until the owning cpu has gone through a thread switch, or by explicit release. This means that, once fixed, our token implementation will allow us to abstract RCU-like operations, which I think is very important. It is not what I originally intended tokens to be but it is turning out to be what they should be.
The nice thing about the revamp I intend to do on the token code is that the RCU abstraction will wind up being a lot better then Linux’s RCU abstraction, because it will be compartmentalized. Only cpus competing for the same token are effected rather then all cpus in the system. We would not have the serialization problem that Linux has.”
Amar Takhar put together a generated-from-SGML version of the DragonFly website, with a few bonus features like a site map.
Joerg Sonnenberger committed a patch by Hidetoshi Shimokawa; this patch syncs DragonFly and FreeBSD 5 Firewire support
Hiten Pandya asked that anyone (committers or not) working on a task for DragonFly mail him the following data:
(2) Owner (name and email address) — can be multiple
(3) Current status (work-in-progress, suspended, done)
(4) Description of the Task (300 chars is good!)
(5) Priority (if any) (If any)”
Send it to email@example.com with a subject of [TODO ITEM]. Will this show up online? I don’t know.
Robert Garrett <firstname.lastname@example.org> is working on the aforementioned OSL Beaver Challenge; if you are interested in participating for “Team DragonFly”, contact him
KDE 3.2 is out. It should be possible to compile at least the base parts on DragonFly thanks to Dave Leimbach.
Wouter Clarie posted about the OSU Beaver Lab Challenge, where the OSU Lab wants to benchmark a number of operating systems (Linux and BSD flavors) against each other, with teams for each operating system to tweak as needed. There’s no DragonFly team at this point, though it may not be useful to ‘compete’ before an inital release.
Matt Dillon is doing what he did with binutils-214 – He’s bringing in a prerelease version of gcc 3.3.3 to replace the FreeBSD 5 specific version of gcc 3.2 currently used. This version of gcc (and binutils) are straight from the vendor, which should mean staying in sync with new releases will be much easier.
Note: using gcc3 may/will lead to breakage right now…
Matt Dillon commited a number of files for AMD64 support; it is far from complete at this point. These files come from Peter Wemm’s work on FreeBSD 5. However, he noted that the PMAP/MMU/VM support will be from scratch.
Quoted here is his comments on how that will be done:
Continue reading “AMD64 work”
As part of the discussion about CVS and similar products, Garance A Drosihn pointed out that he was working on a C++ version of
cvsup, meaning that it wouldn’t require Modula-3 installed to build as it does now. He stopped work because these is apparently a C version in the works, which he hopes would be out by the time of FreeBSD 5.3’s release, somewhere in the next year. That’s good news for DragonFly, too, as
cvsup is the method for code updates for the foreseeable future.
Pedro F. Giffuni brought up the idea of using subversion instead of cvs for storing DragonFly source. Bakul Shah pointed out that subversion was not yet mature enough for a switch from cvs in his experience, and Matt said we are continuing with cvs.
binutils 2.14 is being added in by Matt Dillon, over the next few days.
Thanks to Jeroen Ruigrok, the version of autoconf now in CVS knows what a ‘DragonFly’ system is.
Eirik Nygaard and Robert Garrett have added 2 new scripts to
/etc/rc.d (they default to off):
resident: Any filenames/pathnames in
/etc/resident.conf are made resident – i.e. dynamic programs listed here will load faster.
varsym: Any variable definitions in
/etc/varsym.conf will turn into system wide varsyms.
Jeroen Ruigrok posted an interesting link about moving machine state between machine.