linux-kernel - Re: [Tux3] Tux3 report: Tux3 Git tree available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 14 Mar 2009 20:54:09 -0700
From:	Daniel Phillips <phillips@...nq.net>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, tux3@...3.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [Tux3] Tux3 report: Tux3 Git tree available

On Thursday 12 March 2009, OGAWA Hirofumi wrote:
> Nick Piggin <nickpiggin@...oo.com.au> writes:
> >> There are a couple of issues, one is u64 being (long) instead of
> >> (long long) as you say, and the other is variable type sizes like
> >> loff_t.  That specific one isn't actually a problem, we can just refuse
> >> to support 32 bit libc file ops, but there may be others.  We had a
> >> world of pain before (L) arrived, then with (L) it was easy.  Maybe
> >> just edit them all to (long long) for now, and damn the line length.
> >
> > Yes please do this. A significant style change like this that lots of
> > code already does I think is best first discussed as a standalone
> > change to kernel rather than everyone developing their own convention.
> 
> BTW, personally I wonder whether there are any suggestion - how early
> stage do we try to start review process? Someone suggests it should be
> early, but how early?
> 
> I know tux3 still have to work for various things, however, people join
> to develop those, and see the progress? Or people just want to see the
> result of various work later? ...

It is not just how quickly the work gets done, but the quality of work
that is more widely reviewed and has more total review cycles.  I guess
we are proceeding about the right speed in that direction: not slow,
not fast.  We won't be asking for merging immediately, just review.

There is a lot to be said for finishing up the most interesting
pre-merge bit, atomic commit, "in public", which of course we have done
all along, but it could be more public.  I would like to see a few more
folks get the "aha" about what we are doing with the cache model, the
hybrid logging and other details.

Regards,

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/