lkml.org 
[lkml]   [2008]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] mdb: Merkey's Linux Kernel Debugger 2.6.27-rc4 released
    On Thu, Aug 21, 2008 at 08:57:31AM -0700, Linus Torvalds wrote:
    >
    >
    > On Thu, 21 Aug 2008, Paul E. McKenney wrote:
    > >
    > > Let's face it, the C standard does not support concurrency, so we are
    > > all in a state of sin in any case, forced to rely on combinations of
    > > gcc-specific non-standard language extensions and assembly language.
    > >
    > > Could be worse!!!
    >
    > It _will_ be worse.

    And not only that, it will be worse before the new standard is ratified.
    Or to give the full version: "Could be worse, and probably soon will be."

    > The C standard will eventually support concurrency (they are working on
    > it), and it will almost inevitably be a horrible pile of stinking sh*t,
    > and we'll continue to use the gcc inline asms instead, but then the gcc
    > people will ignore our complaints when they break the compiler, and say
    > that we should use the stinking-pile-of-sh*t ones that are built in.
    >
    > No, I haven't seen the drafts, and maybe I'm overly pessimistic, but I'm
    > pretty sure that this is an area where (a) the kernel needs more support
    > than most normal pthread-like models and (b) any design-by-committee thing
    > simply won't be very good, because they'll have to try to make everybody
    > happy.

    Let's see...

    1. Yes, the standard is being designed by a committee.

    2. No, it does not simply ratify the Linux kernel's memory-barrier
    API. Yes, I did propose that. No, the proposal did not go
    very far, but yes, it did get people's attention. Yes, there
    were a number of people who asserted that Linux's approach was
    fundamentally broken/buggy/whatever. Yes, they have changed
    their mind, most of them, anyway. No, there is still zero
    chance of the standard simply ratifying smp_mb() and friends.

    3. Yes, we are working to get things closer to the Linux kernel's
    memory-barrier API into the spec. No, they will likely not
    be exact. Yes, getting some prominent committee members to
    countenance the idea of any sort of raw memory barrier (not
    connected directly to a load, store, or atomic operation)
    was a long-term project that finally made headway last May.
    Again, design by committee.

    4. No, the current Linux kernel memory-barrier API is not perfect.
    Yes, the proposed standard's preferred memory-barrier approach
    will make code easier to read and understand in many cases, and
    could potentially allow the compiler to do better optimizations
    (which, yes, might or might not be a good thing). No, the
    proposed standard's preferred approach does not apply to all the
    cases in the Linux kernel. No, I don't know whether or not it
    will be worthwhile to introduce the standard's preferred approach
    to the Linux kernel (though I suspect that it would be, but have
    to wait and see). Either way, yes, the Linux kernel will likely
    continue to need to resort to non-standard gcc extensions and
    assembly language in at least some cases. As you say, the kernel
    is not a garden-variety pthreads application.

    But even if the Linux kernel never uses this stuff, user applications
    will need it. And there are a number of reasons why gcc extensions and
    assembly language are even less welcome in many such applications than
    they are in the Linux kernel.

    > Oh, well.

    Pretty much. After all, if you wake up some morning and find that you
    have absolutely no problems, your first action should be to check to
    see if you are under six feet of earth.

    Thanx, Paul


    \
     
     \ /
      Last update: 2008-08-21 18:47    [W:2.341 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site