Alexander Leidinger

Yeah! Finally I got time to finish my work to put a desktop environment (in this case GNOME) into a jail. At least I have a proof of concept (I write this with firefox running in my “deskjail”). No, I don’t do this for additional security (there’s more security than in a non-jailed setup, but less security than in an ordinary jail, as you have to allow access to a lot more devices than in an ordinary jail), I do this for additional flexibility: Moving my desktop is now only the install of FreeBSD on a new machine and rsyncing the jail over to it. As the machine will also be a host of several jails where I have some common users with the same UID in each jail, I don’t pollute the jail-host with the desktop stuff and I have everything nicely separated.

Without a kernel patch and good devfs rules you will not get Xorg up and running in a jail (at least I didn’t managed to let it recognize my graphic card without the kernel patch). Now I have to beef up the patch a little bit and ask for review (it weakens up the security a little bit like the sysctl security.jail.sysvipc_allowed=1 or security.jail.allow_raw_sockets=1).

But first I have to finish the move of all my services I use at home to the jail-host now.

We got a lot of good proposals. Google is willing to give us a very nice amount of students. We didn’t expected this much. Thanks!

Now we need to rate the student applications and find suitable mentors… not that easy. It’s easy for the strongest proposals, but for the rest I expect that there will be some shuffling around until the very end.

The linuxulator is synced on amd64 with i386 (since a while). This means TLS is working now and we have the same (a little bit buggy) futexes.

Roman is slowly working on the *at() commands. He also applied for the GSoC this year again. Kib is willing to mentor (in case Roman gets a free seat in the SoC). I rejected the mentoring position this time, as I don’t know if I will have enough time this summer, but I hope I will be around.

I stumbled about a text which describes why it is beneficial to disclose hardware programming docs and why it doesn’t help in keeping this information away from the competition. I don’t repeat it here, so go and read it.

It’s a little bit old (last modified in 2003), but IMO still up-to-date. If someone approaches a company for hardware docs, please provide this link to them!

Unfortunately it fails to mention that it would even be nice to get docs for obsolete or not supported anymore hardware (if your competition learns even stuff from your hardware which is 3-4 generations old, it is not really a competition and you most probably are leading because of innovation, if not you either are too expensive and opening the docs would be a reason to buy regardless, or your software development is not good enough and opening the docs would allow users to fix this problem themselves). This could be a first step for a company to “test the water”. It would be an investment without any money in return (the company doesn’t sell such hardware anymore), but it would show the company how it affects their image, how much they have to invest and what they can get in return (when people do creative things with your obsolete hardware you haven’t imagined before, you can bet they can do the same with your current hardware too… you may get an entirely new market “for free”).

If you apply some more thoughts about this topic and for example graphic cards, you even notice that any information the competition may get by looking at freely available hardware docs for graphic cards (instead of reverse engineering it), can only be used 2-3 innovation cycles later. This is caused by the short turn around times between new graphic cards. When a new graphic card hits the market, a development team already works at the second next generation (and the next generation is most probably not only in feature freeze but at the bug fixing and performance enhancement step). Now, how much value does the competition gain from this? I would say only the money needed for the reverse engineering. At the same time you gain money from hardware sales from those people which use (the result of) your hardware docs. And the competition is required to open their docs too (see below for the “computer freaks” part), so you can safe the money for the reverse engineering later too.

For soundcards this is a little bit different. There you don’t have such short cycles, but currently there you have a published standard (HDA) and you have Creative with no docs at all on the other side. Hey, Creative, if you stumble upon this, what about kicking Microsoft in the ass by providing your hardware documentation to anyone and benefiting from a lot of people which are pissed off because their shiny Creative-gear doesn’t work on Vista? I’m sure a lot of people are willing to spend their free time to find a way to make your hardware useable on Vista (and on other OS’) without getting money from you. And I’m sure people will find a way to get stuff out of your hardware which makes your eyes fall out of your head (and increases hardware sales). Oh… yes… hey, VIA, what about the docs for your soundgear too? There’s no market for selling hardware docs, but a huge market to sell sound hardware. And those people which play around with non-mainstream software are those people (computer freaks) which recommend hardware to people (mom, dad, neighbors, friends) which don’t play around but just use mainstream software. Those “ordinary” people may not depend on your hardware docs, but the computer freaks will more likely recommend stuff which works not only on the mainstream stuff (just in case someone wants to try some non-mainstream stuff).

The same (computer freaks recommending hardware) is true for cable TV / satellite TV / ... stuff.

Today I committed the updated linux aio stuff to p4. It’s a module now, so it can be loaded as needed. I also updated the p4 diff in the wiki, so anyone can download and test it (please do it!).

Major features in the p4 diff are futexes and TLS for amd64. So if you own an amd64 system please download the patch and give it a try. I’m interested in reports for linux-firefox, skype, realplayer and acroread on amd64.

There’s one known bug with the mmap behavior on amd64 (even in current). I don’t know if this only affects the LTP tests or real world applications, but because there’s much time between the mmap commits and the report, I think it’s only a problem for the regression tests and not a problem which shows up in typical usage scenarios.

After the call for public testing we got some reports about LORs and a panic. This happened after an extensive parallel compiling session of linux stuff on a SMP system for several hours. Roman redid some of the locking and the fixes are in the tree. Intermediate patches already showed promising results. We’re waiting for the test of the committed solution now.

Yesterday we also got reports about segfaults with linux Java 5 and 6. This is under investigation (any debugging help would be appreciated, Java is a large beast).

I also noticed that we don’t have the results of a LTP run of a native Linux system in the wiki. It would be very nice to have this, as it would allow us to see broken test cases (Roman thinks the openat tests are flawed) or at least we see where it doesn’t matter much that we don’t PASS.

Apart from Konstantin (envy24* driver author) I also got a p4 account for Yuriy (emu10kx driver author). Let’s cross fingers for a lot of collaboration in //depot/projects/soundsystem/ now…

Since my call for testing the extended linuxulator in FreeBSD-current we got not much negative responses. Ping doesn’t work on the linux side (fixed in p4), ordinary network connections (e.g. downloading some stuff) works fine. There seems to be a deadlock on SMP systems when compiling a lot of stuff in parallel (e.g. using emerge in a gentoo-chroot with MAKEFLAGS=-j4), this is being under investigation by Roman. Compiling stuff serially on an UP system works just fine so far.

I’m wondering if the lack of responses means that everything is running just fine, or that nobody is giving it a try. So far the daily use of linux programs (acroread, linux-firefox, ...) with 2.6.16 compatibility seems to just work fine on UP and SMP systems and currently I don’t see a reason to not switch the default in i386 in a week.

Jung-uk Kim is working on the linux-TLS on amd64 part. ATM he is chasing bugs. It looks we can get feature parity between i386/linux and amd64/linux32 soon.

Intron did send in a patch for the linux-aio stuff. Now I just need to get time to have a look at it.

Ryan got permission to extend the work he did in the SoC as part of a class at university. He wants to push down the new mixer stuff to the driver level now. He does it in the emu10kx driver (because he has such a card) and maybe in another driver. This will allow to use a lot more of the features a card offers. Yuriy (author of the emu10kx driver) has some work in the driver scheduled too, so I offered him a p4 account so that they can collaborate. As of this writting it is up to the p4 admins to grant an account.

And while I’m at it: Konstantin (env24* driver author) got his p4 account already. He tries to get some time to commit his work in progress there.

Shaun had some unrelated software problems so he wasn’t able to do the paperwork requested by Real. Those problems seem to be fixed and he expects to get some time to do the paperwork “soon”. Real is looking forward to this as the FreeBSD build is much better now.