Re: Tux3 report: Tux3 Git tree available

[Andi Kleen <andi@firstfloor.org>]

Andrew Morton <akpm@linux-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@linux.intel.com -- Speaking for myself only.