[Tux3] [PATCH 02/10] don't use preallocation if BUFFER_PARANOIA_DEBUG is defined

If buffer was allocated linearly, hard to detect invalid buffer access. So, don't use preallocation if BUFFER_PARANOIA_DEBUG is defined. --- user/test/buffer.c | 31 +-- 1 file changed, 29 insertions(+), 2 deletions(-) diff -puN user/test/buffer.c~buffer-debug

Re: [Tux3] [PATCH 03/10] Fix ileaf aligment

can handle unaligned accesses on all architectures. I see. BTW, Linux has macros for it - get_unaligned_be*/_le*. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] [PATCH 03/10] Fix ileaf aligment

Daniel Phillips [EMAIL PROTECTED] writes: On Friday 17 October 2008 02:59, OGAWA Hirofumi wrote: Daniel Phillips [EMAIL PROTECTED] writes: -struct ileaf { u16 magic, count; inum_t ibase; char table[]; }; +struct ileaf { u16 magic, count; u32 pad; inum_t ibase; char table

[Tux3] [PATCH 06/10] purge_inum() should use buffer-data

--- user/test/inode.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN user/test/inode.c~inode-purge_inum-fix user/test/inode.c --- tux3/user/test/inode.c~inode-purge_inum-fix 2008-10-16 01:20:44.0 +0900 +++ tux3-hirofumi/user/test/inode.c 2008-10-16

Re: [Tux3] [PATCH 03/10] Fix ileaf aligment

. Looks good. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] [PATCH 03/10] Fix ileaf aligment

is supposed to generate code to access the fields bytewise on architectures that generate alignment faults, when the compiler can't prove statically that the fields are aligned. I could be completely wrong about that... Um.. We will need to check recent gcc... -- OGAWA Hirofumi [EMAIL PROTECTED

[Tux3] [PATCH 05/10] Use -entries_per_leaf in ileaf_split

--- user/test/ileaf.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN user/test/ileaf.c~ileaf-split-use-entries_per_leaf user/test/ileaf.c --- tux3/user/test/ileaf.c~ileaf-split-use-entries_per_leaf 2008-10-16 01:20:43.0 +0900 +++

[Tux3] [PATCH 09/10] Fix missing set_buffer_dirty()

--- user/test/btree.c |1 + user/test/filemap.c |2 ++ 2 files changed, 3 insertions(+) diff -puN user/test/filemap.c~filemap-dtree-dirty user/test/filemap.c --- tux3/user/test/filemap.c~filemap-dtree-dirty2008-10-16 01:20:45.0 +0900 +++

[Tux3] [PATCH 08/10] rename extent() to make_extent()

Let's use extent for local value. --- user/test/dleaf.c |2 +- user/test/filemap.c |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff -puN user/test/dleaf.c~extent-rename user/test/dleaf.c --- tux3/user/test/dleaf.c~extent-rename2008-10-16 01:20:45.0

Re: [Tux3] Small warning fix

])); index += extent_count(seg[i]); } printf( (%i)\n, segs); Whoops, sorry about that. gcc-4.3.2 didn't warn those. If warning flags is bothering us, we can just reject that patch. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3

Re: [Tux3] [PATCH 02/10] don't use preallocation if BUFFER_PARANOIA_DEBUG is defined

be wrong, or there may be more good fix. -- OGAWA Hirofumi [EMAIL PROTECTED] Yes, the change look correct to me. I merged all your patches, Thanks. inserting this one between 2 and 3 and all the tests passed after each one. I also now have a semi-automated system for testing patches and patch

[Tux3] [PATCH 1/3] Use tuxtime() to update timestamp

# HG changeset patch # User OGAWA Hirofumi [EMAIL PROTECTED] # Date 1226380667 -32400 # Node ID 24f3b0f20899b2c5ad5554b7512f647f75c5d3be # Parent dab895e2e896189f1764a7ec3330b6473757138e Use tuxtime() to update timestamp And this moves time functions to tux3.h to use those without including

[Tux3] [PATCH 3/3] Add billionths() and use it, instead of millionths()

# HG changeset patch # User OGAWA Hirofumi [EMAIL PROTECTED] # Date 1226380749 -32400 # Node ID daac4717e4cc70df5efde5bf82df1841dcc99537 # Parent 55013c67b722e7b218c348f7cda68c766c62fd31 Add billionths() and use it, instead of millionths() diff -r 55013c67b722 -r daac4717e4cc user/tux3.h

[Tux3] [PATCH 1/3] Use tuxtime() to update timestamp

# HG changeset patch # User OGAWA Hirofumi [EMAIL PROTECTED] # Date 1226387681 -32400 # Node ID 6b615de4d62bea052bb57474e754233f911edf1e # Parent dab895e2e896189f1764a7ec3330b6473757138e Use tuxtime() to update timestamp And this moves time functions to tux3.h to use those without including

[Tux3] [PATCH 2/3] Convert more timestamp to high resolution in tux3fuse

# HG changeset patch # User OGAWA Hirofumi [EMAIL PROTECTED] # Date 1226387746 -32400 # Node ID d680e7bc61353f6c4de5ef24e30b4f5d8245150d # Parent 6b615de4d62bea052bb57474e754233f911edf1e Convert more timestamp to high resolution in tux3fuse diff -r 6b615de4d62b -r d680e7bc6135 user/tux3fuse.c

[Tux3] [PATCH 3/3] Add billionths() and use it, instead of millionths()

# HG changeset patch # User OGAWA Hirofumi [EMAIL PROTECTED] # Date 1226387771 -32400 # Node ID e50b06dfcea7f1d56578e12e91d50e5de47983cc # Parent d680e7bc61353f6c4de5ef24e30b4f5d8245150d Add billionths() and use it, instead of millionths() diff -r d680e7bc6135 -r e50b06dfcea7 user/tux3.h

[Tux3] cleanup and small fix, and sparse warning fix

:1b9f30bfd9043fc008e6ad32141001144306089f tag: tip user:OGAWA Hirofumi [EMAIL PROTECTED] date:Thu Nov 13 20:56:30 2008 +0900 files: user/tux3graph.c description: tux3graph update to current format The order of fields in struct extent was changed, use same order. changeset: 420

Re: [Tux3] rename of ext2_* to tux_*, and tux_sb() stuff.

Daniel Phillips [EMAIL PROTECTED] writes: On Wednesday 19 November 2008 04:17, OGAWA Hirofumi wrote: Unfortunately, quick search was right. SLUB didn't warn by test. (probably, I should send a patch to lkml) So, I tweaked malloc() like the following. might_sleep() is only for CONFIG_SLUB

Re: [Tux3] Move some user space code to fs/tux3/inode.c and super.c

Daniel Phillips [EMAIL PROTECTED] writes: Hi Hirofumi, Hi This patch has some code from user/inode.c that also belongs in kernel. It has a lot of minor problems still, please take a look at it if you wish. Thanks. I'll tackle based on this. -- OGAWA Hirofumi [EMAIL PROTECTED

[Tux3] Further sync for inode.c

) This functions may rewrite in kernel completely, I'm not sure. Well, this difference wouldn't matter at least for now. Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Further sync for inode.c

, and maybe forever as they evolve and develop better interfaces. Ok, I'll move it to inside __KERNEL__. Is there are reason to change tux_path[] to *tux_path? We are allocate it by alloc_path(), so it's not array actually now. -- OGAWA Hirofumi [EMAIL PROTECTED

[Tux3] we can mount tux3 in kernel

memory. Well, much work is remaining, enjoy. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Block handle demo code

, e.g. kmap_atomic() or something? Or we use GFP_USERS or something (at least wouldn't use for file data)? At least I was not thinking about it. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo

Re: [Tux3] Possible solution to the deferred nameops delete issue

, otherwise the user can open it via cached_lookup() without inode-i_op-lookup(). So, I think it's necessary. Maybe, test case is: $ echo 111 test.txt $ sleep 30 test.txt $ rm test.txt $ cat test.txt Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED

[Tux3] cleanup and tux3graph improvement

://userweb.kernel.org/~hirofumi/tux3-new.png Please check it. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] cleanup and tux3graph improvement

OGAWA Hirofumi [EMAIL PROTECTED] writes: Those patches are trivial cleanup, and tux3graph improvement. Well, the output of tux3graph is not changed much, however, perhaps the preparation to dump the data which is pointed by extents is done almost. static-http://userweb.kernel.org

Re: [Tux3] cleanup and tux3graph improvement

png. Can we make the svg support depend on the graphviz version? Yes. However, graphviz seems to be already supporting svg at 2004. $ tux3graph [-v] volname $ dot -Tsvg volname.dot foo.svg $ viewer foo.svg We can use -Tsvg, instead of -Tpng. -- OGAWA Hirofumi [EMAIL

Re: [Tux3] Bug? Atom refcounting redux

) return -(long)(ptr - error_base); IS_ERR(ptr) return (error_base ptr ptr = error_base + MAX_ERRNO); -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] [PATCH]tux3_mkdir

/scripts/checkpatch.pl /path/to/your/foo.patch or linux/scripts/checkpatch.pl --file /path/to/your/foo.c -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Deferred namespace operations, third attempt

) { + if (d_negative(nd-path.dentry)) { path_put(old_path); return 1; } Although I'm not seeing whole path, before I forget, this should be !d_negative(nd-path.dentry). -- OGAWA Hirofumi [EMAIL PROTECTED

[Tux3] symlink, truncate, unlink, link, and some bug fixes

to be fixed soon or later. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review it. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Deferred namespace operations, Split up ext2_new_inode

of inode. We have to provide own -get_name() handler. Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED] ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] 64bit inum, mknod(), dirent change, etc.

Daniel Phillips phill...@phunq.net writes: On Thursday 11 December 2008 11:20, OGAWA Hirofumi wrote: static-http://userweb.kernel.org/~hirofumi/tux3/ I upgraded from mercurial 0.9.1 to 1.0.1 to get some of the fancy new extensions, and was not able to pull/clone your repository any more

Re: [Tux3] mkfs.tux3: wiping other fs signatures

and last sector to zero? Ah, I was forgetting about it. I think, first 1024bytes (FAT, NTFS, and EFI), and last 64kbytes (EFI, and MD RAID), should be enough. Right? -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http

Re: [Tux3] structure of tux3

viewer datafile.svg -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] mkfs.tux3: wiping other fs signatures

, mkfs clears first 1024b (or 4096b) and last 64kb, at least for now, it is enough? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Review incoming changes

become the whole volume or at least more blocks. E.g. why do we care only reiserfs? In the same reason, we would want to clear blocks on any offset which is using storage? E.g. ntfs would use the middle of volume. Ugh. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp

Re: [Tux3] Review incoming changes

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: I can see what are you saying, and of course, it is reasonable. But, if we use that rule perfectly, the cleaner would become the whole volume or at least more blocks. E.g. why do we care only reiserfs? In the same reason, we would want

Re: [Tux3] Review incoming changes

reiserfs and NTFS. Because tux3 put superblock at 4096 offset for now, and other blocks can be used for any purpose. So I think, mkfs clears first 1024b (or 4096b) and last 64kb, at least for now, it is enough? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp

Re: [Tux3] Patch: Improve new_btree interface, fix lock init

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Anyway, please apply this patch instead. That is incremental patch of attached patch. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi

Re: [Tux3] Initialize rest_limit_adjust before use

the following instead. Does the following patch work for your gcc version too? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp diff -puN user/kernel/dleaf.c~dleaf-cleanup user/kernel/dleaf.c --- tux3/user/kernel/dleaf.c~dleaf-cleanup 2008-12-31 03:17:33.0 +0900 +++ tux3-hirofumi

Re: [Tux3] Cool features

guess it shouldn't be hard. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] [PATCH] tux3: fix compile error in linus-git

after 2.6.28. And we shouldn't add needless #ifdef. [BTW, if we really want to do this, we should add compat layer like compat.h of external network drivers.] Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp Cleanup/Fix COW credential COW credential was added after 2.6.28. And if we really

Re: [Tux3] [PATCH] tux3: fix compile error in linus-git

didn't break anything. Your improvement is also fine. I would like to keep the #if on VERSION. Oh. I'll just queue the patches for lastest kernel until tux3.git. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http

Re: [Tux3] Userland cleanups

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Well, this make simple sb/inode user, on stack sb/inode is setted up by macros, so we can avoid strace thing by unsetup sb/inode. And, with this, we can share tux_new_volmap() in both of userland and kernel. static-http

Re: [Tux3] Userland cleanups

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Just demonstration though for now. With this hack, volmap/tux_vol_apos seem to work. diff -puN user/kernel/inode.c~vol_bread user/kernel/inode.c --- tux3/user/kernel/inode.c~vol_bread 2009-01-10 00:24:46.0 +0900 +++ tux3-hirofumi/user

Re: [Tux3] Userland cleanups

: not very much. It is looking like a good decision. Yes, I'm running fsx-linux from 2:42 am in JST (Now, 4:32 am). -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Userland cleanups

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Daniel Phillips phill...@phunq.net writes: One thing I was trying to do is keep buffer.c from knowing details of Tux3, such as inode format. Mainly so that it could be used for some other project, the same way I borrowed it from ddsnap. I

[Tux3] Add more buffer debug code

Hi, This is mainly for debugging buffer state, and cleanup for it. I think we will play with buffer soon, to get bugs more early, I hope this is useful for it. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp

Re: [Tux3] Add more buffer debug code

see. Sorry, I didn't notice it. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

[Tux3] Start redirect in filemap(), and some userland changes

Hi, This start to add redirect support to map_region(). It is not big change though. And others is unrelated changes almost. It cleans userland build, and improves debugging. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review. Thanks. -- OGAWA Hirofumi hirof

Re: [Tux3] Start redirect in filemap(), and some userland changes

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: This start to add redirect support to map_region(). It is not big change though. And others is unrelated changes almost. It cleans userland build, and improves debugging. static-http://userweb.kernel.org/~hirofumi/tux3/ This fixes

[Tux3] cursor_redirect fix, and uml patch for current linus git

soon. Well, anyway, this is for someone want to build (uml) kernel for tux3. Signed-off-by: OGAWA Hirofumi hirof...@mail.parknet.co.jp --- fs/Kconfig |1 + fs/Makefile |1 + 2 files changed, 2 insertions(+) diff -puN fs/Kconfig~tux3 fs/Kconfig --- tux3fs-2.6/fs/Kconfig~tux3 2009-01-27 12

[Tux3] new blockdirty() for userspace

, and please pull if it's ok. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

[Tux3] kernel/ileaf.c fixes and cleanup

/~hirofumi/tux3/ I'm not reviewing those by myself, it is for the review. So, please don't pull it yet. However, with this patchset, it passed the fsstress test for several hours. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing

Re: [Tux3] kernel/ileaf.c fixes and cleanup

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: Hi, I've found several bugs in kernel/ileaf.c. Even if all inodes on ileaf was removed, we don't remove ileaf itself, at least for now. So, we have to handle empty ileaf, but in that case, some places is not handling it correctly

Re: [Tux3] Patch : Data Deduplication in Userspace

changing interface for it. So, crypto stuff may be good one. BTW, this issue has git too. So git is using the openssl one and MPL replacement (from mozilla). -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http

Re: [Tux3] Patch: Introduce ddlink interface to expose extended functionality

tux3_ioctl(struct file *file, unsigned int cmd, unsigned long arg) _ -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

[Tux3] [PATHC 1/4] commit cleanup/fix

), \ + .pinned = LIST_HEAD_INIT((sb).pinned) #define rapid_open_inode(sb, io, mode, init_defs...) ({\ struct inode *__inode = (struct inode){}; \ _ -- OGAWA Hirofumi hirof...@mail.parknet.co.jp

[Tux3] [PATHC 2/4] log cleanup

, LOG_REDIRECT }; struct commit_entry { be_u64 previous; }; _ -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

[Tux3] [PATHC 4/4] test flush for bitmap

*argv[]) goto eek; } + /* sb-bitmap is always dirty */ + invalidate_buffers(sb-bitmap-map); //printf( show state \n); //show_buffers(sb-rootdir-map); //show_buffers(sb-volmap-map); _ -- OGAWA Hirofumi hirof

Re: [Tux3] Tux3 Git repository

Signed-off-by: Daniel Phillips tux3@tux3.org I guess it is not good. Especially Signed-off-by, tux3@tux3.org is mailing-list address, not yourself. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3

Re: [Tux3] Tux3 report: Tux3 Git tree available

Andrew Morton a...@linux-foundation.org writes: - When 'bh' is known to be non-NULL, use put_bh() rather than brelse(). It sounds strange. Almost all bh is non-NULL. This means we are going to replace almost all brelse() by put_bh()? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp

Re: [Tux3] Tux3 report: Tux3 Git tree available

, people join to develop those, and see the progress? Or people just want to see the result of various work later? ... -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Tux3 report: Tux3 Git tree available

it, I guess (long long) will bother devlopers. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] Design note: Data flush and rename ordering

transactions to that job] -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3

Re: [Tux3] current my atomic-commit prototype

Samuel Harrington robot...@gmail.com writes: On Tue, May 5, 2009 at 12:49 PM, Martin Steigerwald mar...@lichtvoll.de wrote: Am Dienstag 05 Mai 2009 schrieb OGAWA Hirofumi: http://userweb.kernel.org/~hirofumi/note.defree-logs Hmmm, the URL can't be found on the server. Thats at least

Re: [Tux3] current my atomic-commit prototype (v2)

OGAWA Hirofumi hirof...@mail.parknet.co.jp writes: But, it is not true. So, this patch fixes the cursor position only if splited new block has target child. This means the following, But, it is not true. So, this patch fixes the cursor position by changing the position only if splited new

[Tux3] Bug fixes

Hi, I've picked the bug-fix patches up from my patchset. And this changes is including the patch for packaging and reported bugs from Mario Fetka. Thanks Mario. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- OGAWA Hirofumi hirof

Re: [Tux3] Bug fixes

not a great idea. In tux3.c, it is a (minor) bug that should be cleaned up, even though we have to do #define assert(expr) nothing to trigger it. Yes, I agree. And I think it would also be good to use #include assert.h with the patch of fixing assert() usage. Thanks. -- OGAWA Hirofumi hirof

[Tux3] start the logging for atomic commit

or less. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp ___ Tux3 mailing list Tux3@tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3