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

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Thursday 12 March 2009 20:00:18 Daniel Phillips wrote:
> Hi Nick,
>
> On Thursday 12 March 2009, Nick Piggin wrote:
> > On Thursday 12 March 2009 19:33:02 Daniel Phillips wrote:
> > > On Wednesday 11 March 2009, Andrew Morton wrote:
> > > > > Obviously, that raises the question of whether C99 syntax is banned
> > > > > in kernel.
> > > >
> > > > It is banned ;)
> > > >
> > > > 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.
> > > > ...
> > > > Well.  As I say, it doesn't bother me much (but I like C++, so ignore
> > > > me).  But it will make merge/review life harder for you at the
> > > > outset. How much harder I cannot predict.  People will fixate on this
> > > > issue at the expense of everything else..
> > >
> > > Well, I suppose we will do something in the middle for now: change some
> > > to K&R, and leave some of it as is where we expect it to be developed
> > > heavily, like dleaf.c which is going to see whole bunch of work to
> > > integrate versioning, so it really makes little sense to make it harder
> > > to factor just before starting that work.  Anyway, the C++ comments are
> > > on their way out and after all that is the one people love to hate.
> >
> > I think they need to be fixed before merge. If the function is easier
> > to follow when you use this feature, IMO it indicates the function is
> > too big or badly written anyway.
>
> It's not about being easier to follow as being easier to factor.  Putting
> the variables far away from point of use increases the busy work in
> moving code around significantly, with a corresponding reduction in code
> quality in the long run, because time is spent fiddling with declarations
> instead of improving structure.  That said, it no doubt will be changed

Again, I would say if it takes so much more work to maintain, then the
functions are too big or badly written. But I guess it is a matter of
opinion, so...


> before merge.  Not that I think there is a sensible reason for it, but
> because it makes little sense to dig in over a cosmetic issue.

... how about because it follows agreed convention?


> > > 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.
>
> That will be in the next batch of changes.  So... we offered our shiny
> new convention, and I consider it voted down.  All in a days work :)

Cool. Maybe if you offer it as a standalone patch to the kernel, it
will get more attention? It's just not appropriate to put in with a
new filesystem.