Matt Dillon has brought in ATAng from FreeBSD 4 except for “the dma chipset changes and the busdma changes”, while retaining the apparently better DragonFly MPIPE version.
Spam filters have been turned on for the various DragonFly lists: (Taken from Matt Dillon’s post explaining this)
- Matches against certain really annoying viruses
- With a MIME Content-Type header of text/html
- With a MIME Content-Type header of multipart/alternative
- Without a working reverse DNS lookup
- Without a FQDN formatted HELO line
- With an invalid envelope sender. The spam filter does a realtime
connect back to the SMTP server associated with the envelope sender
and attempts to RCPT to it. If this fails the mail will be rejected.
Matt Dillon’s updated the DragonFly site diary.
Xin Li pointed out a race condition in FreeBSD that exists in DragonFly too. Matt Dillon, on further inspection, found a deeper problem. I’m pasting his description here because he’s speaking another language – I don’t even recognize the acronyms he’s using.
Alan Cox responded with a link to the CMU Mach algorithm on this page as an example of a correct implementation.
Continue reading “Greek to me”
Joerg Sonnenberger’s been going on a change rampage lately, adding “__DragonFly__” to a large number of files so that DragonFly-specific compilation can be done.
Several more people have reported successful GENERIC kernel builds – and boots – using gcc3. I wonder how/if this changes performance?
Emiel Kollof’s most recent changes (committed by Matt Dillon) to the NVIDIA binary driver are in.
Robert Garrett posted that using gcc3 (set your environment var CCVER to gcc3) to buildworld will now succeed.
There’s been a slight conversation about threading, where Jeroen Ruigrok van der Werven mentioned he would want hybrid, or M:N threading. Miguel Mendez chimed in that 1:1 threading, while not as spiffy, is easier to implement and Sten Spans posted a link to this PDF describing 1:1 threading in Linux. (I assume – haven’t read it yet) Matt Dillon brought up a larger issue: asynchronous syscall messaging support is needed before any of this thread work can be done.
Joerg Sonnenberger has introduced NEWCARD, taken from FreeBSD 5 (mostly) in November 2002.
David Rhodus has updated OpenSSL to 0.9.7c, and Emiel Kollof (committed by Robert Garrett) brought in an override port for libusb, needed for software like SANE.
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.
Hiten Pandya has completed the previously-mentioned To-Do list for contributors; an XML version is available if your browser can handle straight XML.
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:
“(1) Name
(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 hmp@backplane.com with a subject of [TODO ITEM]. Will this show up online? I don’t know.