[Tux3] Tux3 Report: Kernel development moved to Git mainline

[pradeep singh rautela]

On Tue, Jan 27, 2009 at 10:28 AM, Daniel Phillips <phillips at phunq.net> wrote:
> Tux3 kernel development is now tracking Linus mainline, and will no
> longer maintain compatibility with older kernels.  With the arrival of
> delayed allocation, Tux3 now compiles only on kernels newer than
> 2.6.28.  A patch against v2.6.29-rc1 is here:
>
>   http://tux3.org/patches/tux3-v2.6.29-rc1
>
> Tux3 user space development remains in Mercurial:
>
>   http://hg.tux3.org/tux3/
>
> The Mercurial tree contains a complete, current copy of the fs/tux3
> kernel files.  Our normal development mode is to add new functionality
> and unit tests in user space, then port to kernel.  Sometimes it goes
> the other way, with kernel changes backported to userspace.  In any
> case, I use rsync to keep the Git and Mercurial kernel files in sync:
>
>   rsync -t .../hg/tux3/user/kernel/* fs/tux3/ && make CONFIG_TUX3=y
>
> There will be a public git tree soon.  For today, there is a patch
> against Linus's tagged revision v2.6.29-rc1, the most recent one that
> builds UML without a patch.  (I still do the majority of my Tux3 kernel
> development on UML, while Hirofumi uses KVM and real machines, and
> others use Xen.)


Daniel,

Is this method capable of building a nice to boot uml linux binary?

I get this -
#./linux ubda=tuxroot
[...]
ubda:unknown partition table.
[...]
Setting the System Clock using the Hardware Clock as reference...
IRQ 13/xterm: IRQF_DISABLED is not guaranteed on shared IRQs
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?

I am baffled, why is partition table on tuxroot suddenly not readable
by linux binary?
Any clues?

Thanks,
    --Pradeep

>
> Status
>
> Tux3 now uses delayed allocation, which is not just a performance hack
> but a step in the direction of atomic commit.  Tux3 now keeps its
> metadata blocks in a normal inode->mapping owned by the filesystem,
> rather than the blockdev mapping, which has a different superblock than
> the fs.  This sounds like a big change, but it was actually pretty
> easy and not much code.  We made this change because block_dev.c is
> dependent on buffer_head, and has its own ideas how metadata flushing
> should be done.  Rather than fight with it, we switched.  It is nice to
> be able to find our own superblock, given a buffer.  We will eventually
> replace buffers entirely, with a new mechanism called block handles
> that provides the block state we need with 16 bytes per page instead of
> the 192 bytes worth of circular buffer list you get now with 1K blocks.
>
> Tux3 has passed 27 hours of fsx-linux stress testing under memory
> pressure, with delalloc and the new volmap metadata mapping.  We will
> now say sayonara to stability for a while, as atomic commit goes in.
> When atomic commit is in, the main structure of Tux3 is done, and we
> plan to call for review at that time, leaving a bunch of features and
> optimizations for later.  We expect Tux3 will perform decently as an
> Ext3-class filesystem at that point, including crash recovery, though
> it will be no benchmark champion before further optimization.
>
> Build instructions
>
> If you already have Linus's Git tree, please be nice and clone it
> locally, otherwise:
>
>   # Clone Linus's Git tree:
>   git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>   cd linux-2.6
>   git checkout v2.6.29-rc1
>
>   # Get the current Tux3 patch and apply it:
>   wget http://tux3.org/patches/tux3-v2.6.29-rc1
>   patch <tux3-v2.6.29-rc1 -p1
>
>   # Build linux with tux3:
>   make defconfig
>   make CONFIG_TUX3=y
>   sudo make install
>
>   # Check out the Tux3 user space Mercurial tree:
>   hg clone http://hg.tux3.org/tux3/
>   cd tux3/user
>   make
>
>   # make a tux3 filesystem
>   sudo ./tux3 mkfs /dev/<testpartition>
>
> Boot and mount!
>
>   cat /proc/filesystems | grep tux3 && mount /dev/<testpartition> /mnt
>
> Recovery after crash or unexpected shutdown is easy:
>
>   tux3 mkfs <volname>
>
> Regards,
>
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Pradeep Singh Rautela
http://eagain.wordpress.com
http://emptydomain.googlepages.com

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3