linux-kernel - Re: 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:	Thu, 12 Mar 2009 14:24:20 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Daniel Phillips <phillips@...nq.net>, tux3@...3.org,
	linux-kernel@...r.kernel.org
Subject: Re: Tux3 report: Tux3 Git tree available

Andrew Morton <akpm@...ux-foundation.org> writes:

As a general comment I'm not sure it really makes all that sense to
integrate anywhere without recovery functionality because noone can
really use in that state. I think it would be better to concentrate
reviewing/testing efforts on other submitted file systems that
actually work and are used today (like ceph or nilfs2)

Also to be honest the estimate of adding btree directories in 3kLOC
of code seems very optimistic.

>
>> > - count_range() is an unsuitable identifier for a kernel-wide symbol.
>> >   Please review all global symbols in the fs, ensure that they are
>> >   prefixed with "tux3_".  Or make them static, of course.
>> 
>> This symbol is only supposed to be shared between separate compilation
>> units within fs/tux3, not be visible outside our module.  How do we do
>> that?
>
> You can't.  Bear in mind that we want the allyesconfig kernel to link
> and run, and that includes tux3.  So do it manually by prefixing
> everything with tux3_ or whatever.  (does it need the "3"?)

AFAIK it could be done by using special linker scripts for the sublinks.
But I'm not sure it's worth it because that would require listing of the symbols
in some file. Would need some Makefile magic.

For modules I also had the "namespace" patches some time ago which implemented
simple namespace support. Should probably resurrect that.

> I'm not sure why, really - I have vague memories of Linus having an
> episode...  It seems an OK construct if used tastefully.  Although it
> does make it easy to hide nasty surprises.

The original reason was gcc 2.95, but that got dropped.

Then I loved to use c99 mixed code/declarations (imho putting the declaration
near the code improves readability), but someone pointed
out that having them makes it harder to catch patch mistakes when
patch puts a hunk in the wrong place.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/