keithp and I have just pushed the support code for the 965GM (laptop graphics chipset that will be available soon) to mesa, drm, and xf86-video-intel. The remaining piece is agpgart, which we just haven't done the lkml submission for yet, but if you check the patches for those 3 projects, you can probably guess what the agpgart diff looks like. It wouldn't seem like a very big addition, since it was something like 100 lines total, but there's something cool and new here: We've managed to get the ability to push the code before the chipset launch. Previously, chipset support like this has been released early only to distributions, who then try to have packages ready to go for that day (often with bugs or integration issues due to only having received old snapshots), but this still meant that you couldn't just grab a released distro CD and pop it in your machine and go. Now, there's a much better chance of this happening, depending on how your distro's release cycle aligns with ours.
Getting even little policy changes like this really gives me hope that we can fix hardware vendors to do the right thing with open source software. Ultimately, it's in their interests.
Monthly Archive for March, 2007
CVS. When updating a checkout from a local, NFS mounted repository, mind your fingers. If you hit a Ctrl+C in an attempt to terminate the process early, cvs will go down in flames and leave a cute cvs.core file behind.
Now this has annoyed us at pointyhat for too long! First lad to get me a patch fixing this issue will get $4 from my Paypal account. And a chocolate badge on top of that, if collected in person at my place.
Meanwhile, ehaupt boldly went to face the xmms avalanche mentioned yesterday. Thanks!
The number of non-resolved ports related PRs dropped under 700 first in a long time – actually, since January. Whee! Kudos especially to miwi, who’s been killing PRs at ungodly rates. He’s the new pav, definitely. The total PR number is at 5085.
In the meantime, I’ve been whacking on never-ending avalanche of objformat fallout. Currently, there’s xmms plugins raining.
Currently looking on http://www.scps.org
Why am I doing this? To figure out if it could be usable for Ham Radio instead of tcp/ip over ax.25.
Presenting GNOME 2.18 for FreeBSD. GNOME 2.18 is a
departure from recent GNOME releases in that it focuses more
on stability and functionality than on new features. Not that
it doesn't have its share of new and exciting items. Check
out the
http://www.gnome.org/start/2.18/
for all the goodies in this release.GNOME 2.18 for FreeBSD would not have been possible
without the hard work of the
../gnome/contact.html
and our intrepid band of testers including J. W. Ballantine,
Pawel Worach, Yasuda Keisuke, Pascal Hofstee, miwi, Yoshihiro
Ota, Vladimir Grebenschikov, Jukka A. Ukkonen, Phillip
Neumann, Franz Klammer, and Neal Delmonico.
The ZFS file system is nicely integrated with Solaris’ zones. It came to my mind a long ago that will be very cool to integrate ZFS with FreeBSD jails.
People are talking for a long time about making jails more feature full, but mostly on networking front – my multiple IPs in jail patch, Marko Zec vimage, etc., but they forget about storage.
Unfortunately we can’t allow jail’s administrators to access raw disks/partitions (GEOM providers), create file systems on them and mount those file systems. The reason is that we can’t handle corrupted file system metadata, which will allow someone from within a jail to write some garbage to file system partition and panic entire system.
And here comes ZFS. ZFS can very nicely be used for such needs, because we operate on raw disks only when we operate on pools. When we operate on file systems, we don’t have access to raw disks anymore.
The basic idea is to allow pool management only from outside a jail, and assign ZFS file systems to the jails.
For example:
main# zfs create tank/jail
main# zfs set jailed=on tank/jail
main# zfs jail 1 tank/jail
Now from within a jail we can:
jail# zfs create tank/jail/home
jail# zfs create tank/jail/home/pjd
jail# zfs create tank/jail/home/pawel
jail# zfs snapshot tank/jail/home/pjd@backup
jail# zfs destroy tank/jail/home/pawel
jail# zfs rollback tank/jail/home/pjd@backup
jail# zfs set compression=on tank/jail/home/pjd
I’ll use this slot to keep list of dataset names accessable inside the jail.Good, now we need to allow for mounting/unmounting file systems from within a jail.
I added security.jail.mount_allowed sysctl, which when set to 1, grants PRIV_VFS_MOUNT and PRIV_VFS_UNMOUNT privileges to jailed root. I’m not really happy with this sysctl, because currently it allows to mount file systems like devfs and procfs from within a jail, which is very wrong, especially for devfs.
We also need to set security.jail.enforce_statfs to 0, so zfs command can see mounted file systems.
What is described to this point is already implemented and work.
I’d also like to add ‘jails’ property, which tells to which jails the given dataset is attached.
