MSFBUFs made

Matt Dillon committed the MSFBUF API. His commit note sums it up nicely so I’ll repaste:

” Add the MSFBUF API. MSFBUFs are like SFBUFs but they manage ephermal multi-page mappings instead of single-page mappings. MSFBUFs have the same caching and page invalidation optimizations that SFBUFs have and are considered to be SMP-friendly.

Whereas XIO manages pure page lists, MSFBUFs manage KVA mappings of pure page lists.

This initial commit just gets the basic API operational. The roadmap for future work includes things like better interactions with third-party XIOs, mapping user buffers into the kernel (extending the xio_init_ubuf() API into the MSFBUF API), and allowing higher level subsystems to pass previously released MSFBUFs as a hint to speed-up regeneration. We also need to come up with a way to overload additional sets of MSFBUFs representing smaller chunks of memory on top of the same KVA space in order to efficiently use our KVA reservation when dealing with subsystems like the buffer cache.

MSFBUFs will eventually replace the KVA management in the BUF/BIO, PIPE, and other subsystems which create fake linear mappings with pbufs. The general idea for BUF/BIO will be to use XIO and MSFBUFs to avoid KVA mapping file data through the nominal I/O path. XIO will be the primary I/O buffer mechanism while MSFBUFs will be used when things like UFS decide they need a temporary mapping.

This is a collaborative work between Hiten Pandya and Matthew Dillon .”

ehci Ejection

Matt Dillon noted that removing ‘device ehci’ from your kernel configuration will cause the USB 2.0 ports to switch down to USB 1.1. This may be needed to make certain USB chipsets work.

Java rumors

Sun is reportedly thinking about open-sourcing Java. There’s no timeline or specific commitment, so it all could be rumors. While Java for FreeBSD works on DragonFly (or so I’ve heard), it’d be nice to have it work officially, without jumping through license hoops.

Doc to do

Thomas Belian made a post to asking if a translation of the documentation to German would help. I made a reply that is probably worth repeating:

“It would be nice to have; you may want to wait until the documentation is more “settled”, probably after the 1.0 release. If you’d like to write original documentation, that would help too, and that can be done right

We could use an extended section on networking setup, and a section on ports. If you check out the cvs target ‘doc‘, you can base it off the files there. Specifically, copy one of the chapter.sgml files in a directory under /doc/en/books/userguide/ and start working. If you are unfamiliar with the markup, you can read up on it at

Ports link, refreshed

Discussion of an improved/replaced ‘ports’ system ran on for a bit on dragonfly.kernel, and Eirik Nygaard reposted an important link: Simon ‘corecode’ Schubert’s extensive writeup.

(Watch for subtle hint!) It’s good enough to serve as a task outline for anyone contemplating ports work. (end hint)

Why not apt-get?

Matt Dillon mentioned that he’s considering using apt-get combined with VFS to create a sort of ‘per-user’ port visibility. Quoting his examples:

“So the ‘apache user’ might only have 10 ports installed (and only access to those 10) while a GUI user might have 50 ports installed (and only access to those 50). Overlaps would be allowed… the environments would be considered independant.

Such environments would also enforce basic isolation/separation/security features such as “/usr is read-only except for /usr/local”, and would be stackable, but instead of trying to use them on a per-package basis we would use them on a per-user basis (or something like that).

This gives us the best of both worlds in my view.

This would mean a new ‘port’ system would have to wait until VFS is finished, though using apt-get without the per-user separation would be achieveable almost immediately.