Everything GCC3 is new again

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…

Source control system followup

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.

There was discussion some time ago of using rsync for updates, which is certainly possible… Binary updates would be nice, too.

Short subversion discussion

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.

varsym and resident rc.d

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.

AMD64 work starting

Matt Dillon’s planning to work on AMD64 support for February. He listed these steps:

“* build support and cross compilation work
* kernel build
* boot 64-bit kernel almost to single user
* 32 bit userland support
* boot kernel to single user
* basic device driver and filesystem testing
* boot kernel to multi user (fully working system at this point)
* everyone w/ 64 bit boxes start banging on it, fixing additional
device drivers, get 64 bit buildworlds working, and so forth.”

Systimer stuff

Matt Dillon’s been working on this patch, described as so:

“These are dyamic[sic] interrupt-driven timers. They replace the old fixed periodic ‘hardclock’ interrupt that exists now and allow per-cpu multiple periodic or one-shot timer interrupts to be registered with the system. Systimers operate outside the MP lock, so any code developed to use it has to be MP safe. Systimers are intended to be able to make use of per-cpu timers (e.g. LAPIC), when available, and will eventually be augmented to use them.”

It also has the added bonus of making nanosleep() very accurate.

gcc 3 going on

Joerg Sonnenberger has added gcc 3.3 to the base system. You can set ‘CCVER=gcc3’ to use it, even to do a buildworld/buildkernel, though that is “not recommended”. Andreas Hauser already reported a successful build and boot doing it, though.

xl expanded

Matt Dillon has made some changes to the xl driver that apparently solves a mysterious bug; I’m quoting from his changelog message below:

“Turn off hardware assisted transmit checksums by default. In buildworld loop tests this has been conclusively shown to corrupt transmit packets about one out of every million packets. The receive will not know the the packet is bad because hardware assist also apples the correct checksum to the corrupted packet. The result are random failures or corruption of network data in certain situations. On DragonFly, for some reason, doing a ‘resident /usr/bin/*’ seems to bring the problem out every few buildworlds with (primarily) mkdep’s cpp complaining about odd errors trying to open non-existant header files (during a header file search), such as EPROTONOSUPPORT. A tcpdump on both NFS client and server showed the client transmitting an access RPC and the server seeing a corrupted access RPC on its end, and then responding with EPROTONOSUPPORT. Other uncaught errors are also almost certainly occuring. mkdep is more likely to catch them because it actually checks the errno of a failed open() and does a huge number of open()’s (and as an NFS client this generates a huge amount of packet traffic).”