Tux3 filesystem interest ()

Re: Current Activities?

On Friday 31 July 2009, debian developer wrote:
> Hi Daniel,
> 
> On Fri, May 1, 2009 at 9:19 AM, Daniel Phillips<phillips <at> phunq.net> wrote:
> > On Wednesday 29 April 2009, t3right.thebashar <at> xoxy.net wrote:
> >> Hi Daniel,
> >>
> >> I want to apologize upfront if I sound like one of those "when will it
> >> be done" questions that are best left unasked with most open source
> >> projects.  Actually, I'm just really curious about what's been going
> >> on lately.  I am somewhat embarrassed to admit that I became
> >> fascinated with tux3's development since the first time it was
> >> featured in an article on kerneltrap.  I've greatly enjoyed reading
> >> your design notes and dialog with the btrfs team.  I had no naive
> >> hopes that tux3 would get integrated into the linux kernel
> >> immediately, but I've been extremely surprised at the loss of public
> >> progress notes from you after the initial review request back and
> >> forth died off.  In fact it seems like there's only been 7 postings
> >> from you in the month since the last kernel merge related thread.
> >>
> >> I've really missed the public view into tux3's progress.  If it's not
> >> too presumptuous, how are you? How's tux3 coming along?  What part of
> >> the kernel port is taking the bulk of the work?  What new and
> >> interesting challenges have you been wrestling with?
> >
> > Actually, I have been busy with real life for the last couple
> > of months.  An interesting challenge is how I can keep up the
> > previous development without any corporate support.  Zero.  Zip.
> > Nada.  There has been exactly zero support from the usual
> > suspects, who all have their own good reasons no doubt, which

(Continue reading)

headers

Theodore Tso | 2 Aug 00:26

Re: Current Activities?

On Sat, Aug 01, 2009 at 09:42:51AM -0700, Daniel Phillips wrote:
> Shapor maintains our website, which does have a wiki.  Just ping him on
> irc about it.

Free hint: make a pointer to the wiki be much more prominent on the
tux3.org web site.  I tried looking for it on the tux3 web site, and
then on google, and the closest thing I could find was this empty wiki:

     http://bitbucket.org/shapor/tux3/wiki/Home

One thing which you might want to include is what makes the tux3 file
system unique and why someone might want to use tux3 instead of some
other file system?  The web site talks about "versioned pointer" which
is a technical feature that might appeal to a computer scientist ---
but what does that mean to an end user?

Performance?  Features?  If so, which features?  From what I can tell,
the feature set of tux3 seems to be a subset of btrfs; is there some
feature or features that tux3 have that other filesystems will not?
Not that I advocate file system developers throwing elbows or
otherwise being too competitive with each other, but the reality is
that every file system design makes tradeoffs, giving it certain
strengths, and some weaknesses.  So what *is* tux3's core design
focus, in terms of workload, or user base?  Making a clear statement
about what the goals of the tux3 filesystem on the web site is
certainly one of those things that I would recommend.

Best regards,

					- Ted

(Continue reading)

headers

Michael Pattrick | 2 Aug 01:13

Question about 212c59f7565f

Suppress idiotic gcc warning for constant shift on 32 bit arch
       1--- a/user/utility.h	Mon Jun 29 09:55:28 2009 +0900
       2+++ b/user/utility.h	Mon Jun 29 10:10:21 2009 -0700
       3@@ -19,11 +19,10 @@ static __always_inline unsigned long __f
       4 {
       5 	int num = 0;
       6
       7-	if (BITS_PER_LONG == 64)  {
       8-		if ((word & 0xffffffff) == 0) {
       9-			num += 32;
      10-			word >>= 32;
      11-		}
      12+	if (BITS_PER_LONG == 64 && !(word & 0xffffffff)) {
      13+		num += 32;
      14+		word >>= 16; /* work around idiotic gcc warning */
      15+		word >>= 16; /* work around idiotic gcc warning */
      16 	}
      17 	if ((word & 0xffff) == 0) {
      18 		num += 16;

As BITS_PER_LONG is a macro, wouldn't it make more scene to include
that as a preprocess directive to get rid of the compiler warning?

Michael Pattrick
http://www.rhinovirus.org/math

headers

Michael Pattrick | 4 Aug 16:57

Re: Question about 212c59f7565f

Sorry if that previous message was a little ambiguous, what I meant
was: wouldn’t the following snippet achieve the same result without
having to work around a GCC warning?

#if BITS_PER_LONG == 64
	if ((word & 0xffffffff) == 0) {
		num += 32;
		word >>= 32;
	}
#endif

-M

headers

OGAWA Hirofumi | 4 Aug 17:34

Re: Question about 212c59f7565f

Michael Pattrick <mpattrick <at> rhinovirus.org> writes:

> Sorry if that previous message was a little ambiguous, what I meant
> was: wouldn’t the following snippet achieve the same result without
> having to work around a GCC warning?
>
> #if BITS_PER_LONG == 64
> 	if ((word & 0xffffffff) == 0) {
> 		num += 32;
> 		word >>= 32;
> 	}
> #endif

You have same miss with me. :) sizeof() can't use for #if.  I guess
better fix would make BITS_PER_LONG constants, but I didn't find the way
to do.

Thanks.
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>

headers

Michael Pattrick | 4 Aug 18:57

Re: Question about 212c59f7565f

Oh yes, you're right, I guess sizeof is calculated after the
preprocessor is done...

The following should be portable:
#if LONG_MAX == LLONG_MAX

Although, it is a tad less apparent what it is doing.

GCC also offers __WORDSIZE == 64 but I dont think anyone else does.

Cheers,
Michael

On 8/4/09, OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp> wrote:
> Michael Pattrick <mpattrick <at> rhinovirus.org> writes:
>
>> Sorry if that previous message was a little ambiguous, what I meant
>> was: wouldn’t the following snippet achieve the same result without
>> having to work around a GCC warning?
>>
>> #if BITS_PER_LONG == 64
>> 	if ((word & 0xffffffff) == 0) {
>> 		num += 32;
>> 		word >>= 32;
>> 	}
>> #endif
>
> You have same miss with me. :) sizeof() can't use for #if.  I guess
> better fix would make BITS_PER_LONG constants, but I didn't find the way
> to do.

(Continue reading)

headers

OGAWA Hirofumi | 4 Aug 19:54

Re: Question about 212c59f7565f

Michael Pattrick <mpattrick <at> rhinovirus.org> writes:

> Oh yes, you're right, I guess sizeof is calculated after the
> preprocessor is done...
>
> The following should be portable:
> #if LONG_MAX == LLONG_MAX
>
> Although, it is a tad less apparent what it is doing.
>
> GCC also offers __WORDSIZE == 64 but I dont think anyone else does.

Maybe, I found a bit better way. SuSv3 seems to define LONG_BIT in
limits.h.  If it's not portable enough, I hope we can find again :)

Thanks.
--

-- 
OGAWA Hirofumi <hirofumi <at> mail.parknet.co.jp>

diff -puN user/Makefile~utility-cleanup user/Makefile
--- tux3/user/Makefile~utility-cleanup	2009-08-05 02:48:24.000000000 +0900
+++ tux3-hirofumi/user/Makefile	2009-08-05 02:48:24.000000000 +0900
@@ -40,7 +40,7 @@ binaries = $(testbin) $(tux3bin) $(fuseb
 tuxdeps		= Makefile trace.h kernel/trace.h
 diskiodeps	= diskio.c diskio.h
 bufferdeps	= buffer.c buffer.h diskio.h err.h list.h
-utilitydeps	= $(bufferdeps) $(diskiodeps) utility.c
+utilitydeps	= $(bufferdeps) $(diskiodeps) utility.c utility.h
 basedeps	= $(tuxdeps) err.h list.h buffer.h diskio.h tux3.h \
 	kernel/tux3.h hexdump.c lockdebug.h

(Continue reading)

headers

Ingo Molnar | 6 Aug 09:52

Re: [Tux3] Current Activities?

* Daniel Phillips <phillips <at> phunq.net> wrote:

> [...]  I will say this now: if we are invited to merge in the next 
> major release, or in -mm or whatever, we will happily do it. If we 
> are not invited to merge, nobody has any cause to complain about 
> progress slowing down. [...]

The thing is, if you are waiting for an 'invite to upstream Linux 
merge' that could be a _very_ long wait: i've yet to see a single 
one ever since i started hacking Linux ~14 years ago 

The model that Linux has been following for the past 10+ years is 
for new kernel projects to request inclusion. I.e. you push your 
patches upstream: you send patches and a pull request to the 
appropriate people/lists such as lkml.

This is done so because merging patches is a fundamentally 
hierarchical process, and the people merging _your_ patches are the 
real maintenance bottleneck, not you.

So it is not Linus and other maintainers who are searching the web 
for projects to merge and sending out 'invites' but the other way 
around: projects try to get upstream by submitting patches (which 
get reviewed and accepted or rejected).

So if you'd like your code to be merged upstream you better start 
this process now - this alone can take a lot of time: months (or 
years in certain cases). But it is still a much shorter time-span 
than an 'invite to merge'

(Continue reading)

headers

Aruna Medhekar | 6 Aug 14:02

Request for a project idea

Sir,
We are a group of 4 under graduate students who wish to complete a project in kvm.We have gone through your to-do lists but we did not find anything that we could do in a whole year.Can you please suggest something that might be possible for us to implement?

Thanking you,
Regards,

--
Shweta Shetty
Parul Nalavade
Aruna Medhekar
Ruta Gadkari

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

headers

Aruna Medhekar | 6 Aug 14:46

Re: Request for a project idea

Sir,
We are extremely sorry for the error in the previous message.We wish to do a project in tux3 filesystem.Please let us know something that you think is within our scope.
Thank you !

On Thu, Aug 6, 2009 at 5:32 PM, Aruna Medhekar <sparx2010 <at> gmail.com> wrote:

Sir,
We are a group of 4 under graduate students who wish to complete a project in kvm.We have gone through your to-do lists but we did not find anything that we could do in a whole year.Can you please suggest something that might be possible for us to implement?

Thanking you,
Regards,

--
Shweta Shetty
Parul Nalavade
Aruna Medhekar
Ruta Gadkari

--
Shweta Shetty
Parul Nalavade
Aruna Medhekar
Ruta Gadkari
X

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

1	March 2011
1	September 2010
1	June 2010
1	January 2010
2	November 2009
1	October 2009
17	August 2009
3	July 2009
4	June 2009
16	May 2009
9	April 2009
86	March 2009
50	February 2009
145	January 2009
176	December 2008
78	November 2008
67	October 2008
139	September 2008
68	August 2008
19	July 2008

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31