Sometimes, when things go right, they are really beautiful to watch. Like adding a virtual (SCSI) drive to a running virtual machine freshly copied from ESXi 3.5 to vSphere 4, seeing that drive simply appear in the guest system in a hot-plug fashion, creating a ZFS pool on it and watching iostat as data is migrated from the old drive which has gotten to be too small (and uses UFS), to the new one on which the magic of ZFS will allow the file system to grow indefinitely (as the damn application is greedy in a stupid way), and seeing that "pausing" problems ZFS caused on ESXi 3.5 really are solved in 4.
Jeff Roberson is working on an addition to UFS softupdates which includes a tiny journal to keep track of things like free space and inode orphaning that were left to background fsck to deal with in the original implementation of softupdates. Basically, it's still the same old softupdates but without the need for (bg)fsck to be run for recovery!
I’ve just moved pefs and l2filter development to github. Hope it helps people follow development.
pefs repository (github.com/glk/pefs) can be used to to compile and run pefs without applying any patches.
* support running on msdosfs
* enable dircache only on file systems that are known to support it
* add man page
* add pefs getkey command
* intial implementation of pefs PAM module
l2filter repository (github.com/glk/l2filter) contains only patches. There is fresh patch against 8-STABLE with some minor improvements comparing to 7-STABLE version. 9-CURRENT patch is a bit outdated at the moment, as I’m waiting for Luigi Rizzo to finish ipfw refactoring work first.
Besides I’ve moved my blog to glebkurtsou.blogspot.com/
Please update your bookmarks. I do not intend to update blog freebsdish any more.
File Info: 16Min, 8MB.
Earlier tonight, on December 7 2009, a friend and me booked our flight tickets for FOSDEM 2010. I am really excited that I am going to attend another open source & free software conference. It has been a while since I had a chance to meet with other BSD people. The last time was in Milan, in EuroBSDCon 2006. It will certainly be tons of fun to meet in person with other free and open source fans, contributors and developers!
FOSDEM is an open conference, organized every year by volunteers to promote the widespread use of Free Software and Open Source Software. It takes place in the beautiful city of Brussels (Belgium). FOSDEM meetings are recognized as â€œThe best Free Software and Open Source events in Europeâ€?.
This yearâ€™s FOSDEM will take place on February 6-7 of 2010. The web page of the conference is already online at http://www.fosdem.org/2010/. Updates about the organization of the conference, transportation tips, accommodation options, the dev rooms and talks available this year, and any other bits that may be useful to attendees are often posted there by the organizing team. So if you are planning to attend, add this link to your bookmarks and keep up with the news until we meet in Brussels.
Thatâ€™s all for now. I will be posting more details about the conference and my trip to Belgium as they become available.
Posted in Computers, Conferences, Free software, FreeBSD, GNU/Linux, Open source, Programming, Software Tagged: Computers, Conferences, Free software, FreeBSD, GNU/Linux, hellug, Open source, Programming, Software
It is with sadness that we note the passing of long time FreeBSD committer, John Birrell. Many in the FreeBSD community had the opportunity to interact with John online and perhaps meet him in person at a BSDCan. He will be missed.
It is now possible to make a donation to the FreeBSD Foundation in memory of someone. Select the “in memory of” button on the donation page and type in the name of the person the donation is being made in memory of.
It is now possible to make a donation to the FreeBSD Foundation in memory of someone. Select the "in memory of" button on the donation page and type in the name of the person the donation is being made in memory of.
This WE I was told that FreeNAS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD version). One of the reasons seems to be a missing sensors framework.
As I was committing a port of the OpenBSD sensors framework (produced as part of the Google Summer of Code 2007) to FreeBSD and had to remove it afterwards because one committer complained very loudly, I was asked what the status of this is.
The short status is: Nobody is doing something about it.
Before I explain the long status, I give a short overview what this sensors framework is:
- a kernel API which allows to add sensors
- an interface for the userland to query the sensor data
- some basic userland code to show and log the sensor info
The API and the query interface are more or less independent. For the userland code it was more a logging infrastructure than a real monitoring solution. The reason was the real monitoring solutions already exist (Nagios, snmpd, …) and can be adapted to query the sensors. Ideally a query in userland should be handled by a library instead of directly accessing the sysctl interface, this way the kernel<->userland interface would be abstracted away (and could b replaced as needs arise). This was not done, it was something to be done later (Rome was not build in a day).
The userland interface also only cared about dumb sensors (those which you need to query manually to get the information), smart sensors (those which are able to send events themself) where not taken care about in the sense of really sending sensor-triggered events, but the kernel API allowed to add such sensors. The sysctl interface has no way of sending events, but FreeBSD already has an event interface (devd is taking care about it). It would have been not a problem to send events via this channel and let an userland library take care about the delivery together with other sensor-data in userland.
And now the long status is:
PHK complained loudly about it. First he said he did not look at it but he complained that is not good regardless. After a lot of nagging from me he had a look at it and was not happy about the time stuff in it (short: the FreeBSD timecounter code is better). This was not a problem in my opinion, we could have disabled this part without problems. After such an offer from me, he complained that the sensors framework uses the sysctl interface instead of an entry in /dev.
At this point in time already several userland utilities used the sysctl framework to query for status data in the kernel. So there was already precedence for such an use of it. Later some more such uses where added too (e.g. the procstat stuff by core team member Robert Watson).
I saved some of the corresponding mails (to public mailing lists) in a mbox file, read the mess yourself if you want.
The bottom line is: Several committers (even some which we could call high profile committers) told me that they do not see a problem in the use of the sysctl interface. They do not seem to want to tell it in public (nobody of them voiced their opinion in the thread, so do not ask me who those people are). I am not interested in investing more of my spare time into fighting windmills (it looks like this to me).
If someone tries it with a more recent FreeBSD, please drop me a note if it just applies fine, or a patch (or an URL to it) if it needs some modifications. Who knows, maybe in a future project it may be useful for me.
If there is enough interest by several people, I can even put up a wiki page where those people can coordinate, but that is most probably all I am willing to invest further into this (at least in my unpaid time).
The FreeBSD foundation is collecting donations for the next year! The Foundation is a regular sponsor of many events, funds trips (including mine) to FreeBSD conferences and occasionally funds projects for various enhancements to FreeBSD. It is an important factor in keeping FreeBSD going!
Yesterday I committed the v4l support into the linuxulator (in 9-current). Part of this was the import of the v4l header from linux. We have the permission to use it, it is not licensed via GPL. This means we can use it in FreeBSD native drivers, and they are even allowed to be compiled into GENERIC (but I doubt we have a driver which could provide the v4l interface in GENERIC).
If someone is willing to write the glue-code for the v4l2 interface please contact me. We have the permission to use the v4l2 header too, we just need someone doing the coding.
In a similar way, if someone is willing to add v4l2 interface support to FreeBSD native drivers (I do not know any FreeBSD driver which provides a v4l2 interface) , just tell me and I import the v4l2 header into FreeBSD.
And if someone wants to add v4l support to FreeBSD native drivers but does not know where to start, feel free to contact me too.
Regarding the code which is in FreeBSD ATM: it is not completely finished yet (some clipping related stuff is being worked on), but the not finished part can not even be tested, as we do not know about a FreeBSD device which provides this functionality.
There is no MFC planned yet, but the more success stories and test scenarios are being told about on the emulation or multimedia mailinglists, the more likely I will do a MFC sooner than later.
Recent benchmarks of FreeBSD 8 have provoked a discussion both on benchmark results themselves, on benchmark methodology in general and on upcoming improvements. One of the things mentioned is the small utility used internally in FreeBSD that was recently "blessed" into being a generally available part of the operating system - the ministat.
I am in the process of preparing the import of code which makes v4l devices usable in the linuxulator. Basically this means you can use your webcam in skype (tested by the submitter of the patch on amd64).
This is not a “apply patch and commit” thing, because the original videodev.h (with some modifications) is used. I was seeking the OK from core@ for this. As there is no license in the header, and the original author (Alan Cox, the linux one, not our FreeBSD one) gave permissions to use it, core@ is OK with the import.
I intent to do a vendor import of the linux header (prepared today, together with some readme which explains where it comes from and some stuff to show that we are on the safe side regarding legal stuff), and then I want to copy this over to the linuxulator as linux_videodev.h and commit the patch (probably a little bit modified in a few places). My plan is to commit it this week. People which already want to play around with it now can have a look at the emulation mailinglist, a link to the patch is posted there.
With the header being in a vendor branch, interested people could then start to submit new BSD licensed drivers or modify existing drivers which make use of the v4l interface, but I let the import of the header into the FreeBSD include directory up to the person which wants to commit the first native FreeBSD-v4l support.
When such native FreeBSD-v4l support is committed, the linuxulator code needs to be revised.