git is rapidly shaping up to be a wonderful source code control tool. I've been using it at the "bare metal" layer since it was created to do kernel work with, and played around with some of the other programs that use it to make it more "user friendly".

I'm using it to keep all of the different documentation I've written in the past (that used to be in a bk repository) and even use it to store my old, archived email tree (at 2.2Gb uncompressed, it isn't small). And I'm using it for my latest book work, as it makes working from any of my different computers a piece of cake (just update the tree and go.)

But for a lot of people, the way git handles branches is a bit strange. If you are one of them, take a look at this explanation from Linus on the git mailing list. It clears things up a lot and touches on the power that the different branch format contains within git itself.

It also shows the kind of support some open source projects can provide to just any user that happens to want to learn more and asks very good questions. Try doing that with a commercial product without spending a lot of money on support contracts...

Note. Please don't bombard me with things like, "but use distributed subversion", or "mecurial is so much better", or "arch is the only true way". That's fine, it's nice to see other SCMs get activly developed and get better, it's just that due to my kernel development work, I've grown to really like git as its workflow matches mine quite well.

posted Wed, 11 Jan 2006 in [/diary]

Third in a long series of complaints... See part 1 and part 2 and part 3 for previous atrocities.

It seems that some people are now worried that if I critique a patch a bit harshly, they will end up being mentioned here.

Now to be fair this patch does contain some obviously wrong things (wrong coding style, linewrapped patch, no tabs in sight, odd types created (sysfs_ref?), #define NULL, did not CC: the proper subsystem maintainer, etc.) that should have never escaped into public to see the light of day (come on, a STSM making such basic mistakes makes me really wonder...), but it doesn't deserve to make me or anyone else "pissed off".

In fact it's good that he posted the code, and the issues that are being raised are good ones, as people obviously try to subvert sysfs to do bad things at times, as they are just not that familiar with it and are used to path based filesystems like /proc where you can just say "give me a file named foo/baz/bar and it will be created automatically for you.

For the longest time, I felt that it would be good to be able to created subdirectories easier in sysfs, but after the ability to name attribute groups happened (you do know about sysfs attribute groups, right? Yeah, no one does it seems...), that need really went away.

For Xen, they want to move all of their /proc/xen files into sysfs easily, as they know it's not acceptable to add new files to /proc that do not deal with processes. Unfortunately, putting those files into sysfs isn't a simple api change. It requires you to usually rework your logic and create some kind of tree that can be properly represented. This patch was made with the goal to put a procfs like api on top of sysfs, and do this only for xen, both of which are not acceptable.

Well, the later is not acceptable at all, it remains to be seen if the former is really a good idea or not. But if it is, it should not be restricted to only Xen users, but available to all.

The main point here is, raising these types of questions, and doing it by providing a real example in code, is the absolute best way to do kernel development, and makes me, as a kernel subsystem maintainer, very happy to see.

That all being said, the Xen people really need to work on getting their stuff into mainline as they have been playing in their own repository for way to long and are not used to having anyone review their code. Hopefully some day they will learn and join the mainline kernel.

Until then, I expect to see more posts like this (there was another one recently on the linux-usb-devel mailing list that also ended with that developer having to go off and do some general work that everyone can benefit from), as the xen development group slowly learns the proper way to interact with the kernel developers.

This post is brought to you today by the letters I, B, and M.

posted Wed, 11 Jan 2006 in [/linux]