It seems my HOWTO create a new linux_base port was not too bad. There is now a PR for a CentOS 6 based linux_base port. I had a quick look at it and it seems that it is nearly usable to include into the Ports Collection (the SRPMs need to be added, but that can be done within some minutes).
When FreeBSD 8.3 is released and the Ports Collection open for sweeping commits again, I will ask portmgr to do a repo-copy for the new port and commit it. This is just the linux_base port, not the complete infrastructure which is needed to completely replace the current default linuxulatoruserland. This is just a start. The process of switching to a more recent linux_base port is a long process, and in this case depends upon enough support in the supported FreeBSD releases.
Attention: Anyone installing the port from the PR should be aware that using it is a highly experimental task. You need to change the linuxulator to impersonate himself as a linux 2.6.18 kernel (described in the pkg-message of the port), and the code in FreeBSD is far from supporting this. Anyone who wants to try it is welcome, but you have to run FreeBSD-current as of at least the last weekend, and watch out for kernel messages about unsupported syscalls. Reports to [email protected] please, not here on the webpage.
From this morning's joint press release:
Deployment Adds Enterprise-Grade Redundancy for Improved Reliability, Reduced Latency, High-Speed Backups and Other EfficienciesBOULDER, CO, August 10, 2010 — The FreeBSD Foundation, a 501(c)(3) non-profit organization dedicated to supporting the FreeBSD Project and community, today announced that NYI, a New York City-based, mission-critical data services provider, will be mirroring key West coast infrastructure at NYI's 999 Frontier Road data center in Bridgewater, New Jersey, a recently opened 4
Hans Petter Selasky submitted a bug against the rather poor error handling of device_get_children a while ago. When the usb4bsd stuff he's trying to get into the tree was posted for review, one of the issues was with device_get_children() as it related to device_delete_children().
This reminded me of original issue. I've gone through the tree and done an audit of the device_get_children calls. I think that the issues have been resolved. However, it looks like there's a lot of code in the tree looking for siblings and such. This suggests a close review of the code to pull out common routines into subr_bus might be in order. Each of these hand-rolled routines had slightly different bugs in the error handling...