Tux3 report: Tux3 by Christmas?

Tux3 report: Tux3 by Christmas?

[Daniel Phillips]

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

Re: [Tux3] Tux3 report: Tux3 by Christmas?

[Daniel Phillips]

...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:

daniel@moonbase.phunq.net                        49937 ****************************************************************************************************************
hirofumi@mail.parknet.co.jp                      14541 ********************************
shapor@yzf.shapor.com                             5286 ***********
hirofumi at mail.parknet.co.jp (OGAWA Hirofumi)    673 *
tero.roponen@gmail.com                             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:

hirofumi@mail.parknet.co.jp  14541 ************************************************************************************************************************************
daniel@moonbase.phunq.net     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

Re: Tux3 report: Tux3 by Christmas?

[Andrew Morton]

On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <phillips@phunq.net> 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.

Re: Tux3 report: Tux3 by Christmas?

[Daniel Phillips]

On Wednesday 10 December 2008 23:36, Andrew Morton wrote:
> On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <phillips@phunq.net> 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

Re: Tux3 report: Tux3 by Christmas?

[John Stoffel]

>>>>> "Andrew" == Andrew Morton <akpm@linux-foundation.org> writes:

Andrew> On Wed, 10 Dec 2008 14:35:39 -0800 Daniel Phillips <phillips@phunq.net> 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