lkml.org 
[lkml]   [2009]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [Tux3] Tux3 report: Tux3 Git tree available
    Date
    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.



    \
     
     \ /
      Last update: 2009-03-12 10:13    [W:0.024 / U:0.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site