The wag's rejoinder would naturally be, which Christmas? Well, if we
set our expectations reasonably then it is this Christmas, the one that
is 15 days away.
The latest Tux3 kernel patch is here:
http://tux3.org/patches/tux3-2.6.26.5-2
This includes many bug fixes, cleanups and additional functionality.
File and directory operations are nearly all there now. Rename support
was checked in yesterday by a developer (Michael Pattrick) as his very
first kernel patch. It functioned, and everybody pitched right away to
make it solid. This kind of thing is getting to be a regular event in
Tux3 land, and I must say, it is gratifying to be able to encourage new
Linux contributers this way, while providing pretty good sport for
experienced hacks too.
http://tux3.org/
irc.oftc.net #tux3
The big goals for Christmas (this Christmas!) are:
- SMP locking
- Atomic commit
- Posixly complete
- Rudimentary fsck
With atomic commit, we will progress from "buggy Ext2 equivalent with
missing features" to "buggy Ext3 equivalent with missing features".
Not a bad place to arrive at in five months, starting from scratch.
Does anybody out there still doubt that the community process works,
and is the best way to develop really complex software? Believe it.
Non-goals for Christmas include:
- Versioning
- Directory indexing (PHTree)
- fsck repair
These major features will all get underway early in the new year. As
usual, the invitation remains open for all interested parties to come
lend a hand. The atomic commit effort and some work we are doing with
deferred namespace operations offers interesting engagement for
developers at all skill levels.
The list of Tux3 contributors continues to grow, with first-time patches
from Benjamin Stuhl, Pranith Kumar, Jonas Fietz and Michael Pattrick.
Most Posix operations are supported now, with the exception of extended
attribute support, which is waiting for a fairly minor fix to the way
we handle file size in directory operations. I will not swear that
this code is bug-free, far from it. I will go as far as claiming that
this code is fun and convenient to work on. We are still able to do a
large part of the development in user space, and even the kernel code
is developed mostly in the comfortable environment of uml or kvm.
We supply 32 bit and 64 bit root filesystems for UML development:
http://tux3.org/downloads/tuxroot32.tar.bz2
Jonas Fietz prepared the 64 bit root filesystem, thankyou very much.
These are just 23 MB downloads that started life as Jeff Dike's
debian-small Potato filesystem (small potatoes, get it?) and were
upgraded over time with a modern libc and a few amenties such as the
Nano text editor. A brief guide to Tux3 development under UML is here:
http://lwn.net/Articles/308950/
We should be able to produce a guide for KVM development pretty soon as
well.
Thanks to Shapor Naghibzadeh for a spiffy new tabbed look to the tux3
home page, and for hosting it on a more capable machine than my home
server, which also happens to be my desktop and main Tux3 development
machine. It's true, I was often building UML kernels and browsing
Slashdot while serving up html to all the search bots and interested
people who were dropping in with increasing frequency. For the first
time, we have a fighting chance of withstanding a Slashdotting, whereas
last week the result would certainly have been a smoking black hole in
the internet.
Special thanks to Jon Corbet for explaining to us what we're actually
building in his own inimitable way:
http://lwn.net/SubscriberLink/309094/96a4d6980342ab7e/
and to show that these words of wisdom do not just vanish into thin air,
we have the "Jon Corbet" patch:
http://hg.tux3.org/tux3?cs=05354dc10bec
It is worth noting that the Tux3 project so far consists entirely of
volunteers contributing on their own time (yes, me too). Support from
interested people is always welcome, whether that be beer:
http://tux3.org/contribute.html
or something even more substantial. For example, a three way Phenom
machine or equivalent for SMP development would be welcome if somebody
happens to have one they can send.
Regards,
Daniel
...and Hirofumi Ogawa continues to check in beautiful, accurate kernel
patches at a furious rate, with 15,214 lines changed in 176 changesets
over the six weeks since he joined the project.
Mercurial churn statistics for all Tux3 contributers:
[email protected] 49937 ****************************************************************************************************************
[email protected] 14541 ********************************
[email protected] 5286 ***********
hirofumi at mail.parknet.co.jp (OGAWA Hirofumi) 673 *
[email protected] 279
Pranith Kumar 96
Michael Pattrick 78
Jonas Fietz 29
bobby@lappy 7
This is a little skewed by a few patches I applied before I knew about
hg commit --user, and a big move of all files from one directory to
another a while back, which Mercurial counts as changes. Somehow,
Conrad Meyer's significant contributions did not make it in the list.
This is where I want to be able to edit Mercurial's history, is there
a way to do that?
Over the last month we have:
[email protected] 14541 ************************************************************************************************************************************
[email protected] 4806 *******************************************
Pranith Kumar 96
Michael Pattrick 78
Jonas Fietz 29
bobby@lappy 7
So now I am playing catch up with Hirofumi, and I love that.
Regards,
Daniel
On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <[email protected]> wrote:
> The big goals for Christmas (this Christmas!) are:
>
> - SMP locking
> - Atomic commit
> - Posixly complete
> - Rudimentary fsck
>
> ...
>
> Non-goals for Christmas include:
>
> - Versioning
> - Directory indexing (PHTree)
> - fsck repair
If it is your intention to submit this for a mainline merge then I
would encourage you to stop feature work at the earliest reasonable
stage and then move into the document, submit, review, merge, fixfixfix
phase. That might take as long as several months.
Once things have stabilised and it's usable and performs respectably,
start thinking about features again.
Do NOT fall into the trap of adding more and more and more stuff to an
out-of-tree project. It just makes it harder and harder to get it
merged. There are many examples of this.
Also, don't feel that a merge would lock you into the current on-disk
layout. I think it would be acceptable to emit a big printk("the
format of this fs will change without notice. Do not yet store any
data on a tux3 fs") during mount(). For a while.
On Wednesday 10 December 2008 23:36, Andrew Morton wrote:
> On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <[email protected]> wrote:
>
> > The big goals for Christmas (this Christmas!) are:
> >
> > - SMP locking
> > - Atomic commit
> > - Posixly complete
> > - Rudimentary fsck
> >
> > ...
> >
> > Non-goals for Christmas include:
> >
> > - Versioning
> > - Directory indexing (PHTree)
> > - fsck repair
>
> If it is your intention to submit this for a mainline merge then I
> would encourage you to stop feature work at the earliest reasonable
> stage and then move into the document, submit, review, merge, fixfixfix
> phase. That might take as long as several months.
>
> Once things have stabilised and it's usable and performs respectably,
> start thinking about features again.
>
> Do NOT fall into the trap of adding more and more and more stuff to an
> out-of-tree project. It just makes it harder and harder to get it
> merged. There are many examples of this.
I think I was getting all geared up to be another example of that. Ok,
"usable" to me means with atomic commit and SMP locking, and doesn't
immediately oops. And put the versioning and directory index aside for
the moment, which is not a big question mark because we have done both
before.
> Also, don't feel that a merge would lock you into the current on-disk
> layout. I think it would be acceptable to emit a big printk("the
> format of this fs will change without notice. Do not yet store any
> data on a tux3 fs") during mount(). For a while.
Got it.
Regards,
Daniel
>>>>> "Andrew" == Andrew Morton <[email protected]> writes:
Andrew> On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <[email protected]> wrote:
>> The big goals for Christmas (this Christmas!) are:
Andrew> Also, don't feel that a merge would lock you into the current
Andrew> on-disk layout. I think it would be acceptable to emit a big
Andrew> printk("the format of this fs will change without notice. Do
Andrew> not yet store any data on a tux3 fs") during mount(). For a
Andrew> while.
Hear hear! I keep wanting to play with ext4,btrfs and tux3, but I
don't have the time to grab and play mix and match with git right
now.
Daniel, please start the push to merge!
John