How to name a function to indicate that they require calling from acritical section?

Discussion in 'C Programming' started by celephicus@gmail.com, Aug 9, 2012.

  1. Guest

    Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.

    How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.

    Any ideas?
    , Aug 9, 2012
    #1
    1. Advertising

  2. Eric Sosman Guest

    Re: How to name a function to indicate that they require callingfrom a critical section?

    On 8/8/2012 9:55 PM, wrote:
    > Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.
    >
    > How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.
    >
    > Any ideas?


    Idea: Pthreads uses names like fputc_unlocked() for a similar
    purpose, and you might imitate that. I don't think the ugliness
    of such names should be much of a barrier; you *want* them to jump
    out and be difficult to overlook -- even difficult to type, if the
    functions should only be called in unusual circumstances.

    But could you do better by reorganizing the program a bit?
    By that I mean: In many cases, an "uncritical" piece of the program
    calls a function that "goes critical" (acquires a lock, whatever),
    does its job, restores normal mode, and returns to the caller, with
    its work done and no longer "critical." If the function's work is
    complex enough to be broken down into sub-functions, consider making
    those subordinate functions `static' so outsiders cannot call them
    directly but can only get at them through the "safe" API.

    --
    Eric Sosman
    d
    Eric Sosman, Aug 9, 2012
    #2
    1. Advertising

  3. Re: How to name a function to indicate that they require callingfrom a critical section?

    On 09/08/2012 02:55, wrote:
    > Good programmers know about critical sections, which protect shared resources. Good programmers use descriptive names. I just spent a day tracking down a real-time bug due to me calling a function outside a critical section.
    >
    > How would you name a function to indicate that it should only be called from within a critical section? Something like doStuff_critical() with the "_critical" telling you the requirement for a critical section. But of course less ugly.
    >
    > Any ideas?
    >


    By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
    is the actual implementation, with assumptions about locks etc in the
    comments, and foo() is a wrapper which takes the correct lock(s), irq
    states etc.

    As a result, non-critical sections can call foo() and bar(), while a
    larger complicated critical section can take the relevant locks and call
    the required __foo() and __bar() functions.

    (Although it should be noted that kernel critical sections will probably
    differ widely from application level critical sections)

    ~Andrew
    Andrew Cooper, Aug 9, 2012
    #3
  4. Re: How to name a function to indicate that they require calling from a critical section?

    Andrew Cooper <> writes:
    > On 09/08/2012 02:55, wrote:
    >> Good programmers know about critical sections, which protect shared
    >> resources. Good programmers use descriptive names. I just spent a day
    >> tracking down a real-time bug due to me calling a function outside a
    >> critical section.
    >>
    >> How would you name a function to indicate that it should only be
    >> called from within a critical section? Something like
    >> doStuff_critical() with the "_critical" telling you the requirement
    >> for a critical section. But of course less ugly.

    >
    > By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
    > is the actual implementation, with assumptions about locks etc in the
    > comments, and foo() is a wrapper which takes the correct lock(s), irq
    > states etc.
    >
    > As a result, non-critical sections can call foo() and bar(), while a
    > larger complicated critical section can take the relevant locks and call
    > the required __foo() and __bar() functions.
    >
    > (Although it should be noted that kernel critical sections will probably
    > differ widely from application level critical sections)


    Identifiers starting with two underscores, or with an underscore and an
    uppercase letter, are reserved to the implementation; if you define such
    an identifer yourself, the behavior is undefined.

    (The kernel is arguably part of the implementation, and even if it
    isn't, it's probably ok for the developers to rely on certain behaviors
    that aren't defined by the language standard.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 9, 2012
    #4
  5. Re: How to name a function to indicate that they require calling from a critical section?

    "China Blue [Tor], Meersburg" <> writes:
    > In article <>,
    > wrote:
    >
    >> Good programmers know about critical sections, which protect shared
    >> resources. Good programmers use descriptive names. I just spent a day
    >> tracking down a real-time bug due to me calling a function outside a
    >> critical section.
    >>
    >> How would you name a function to indicate that it should only be
    >> called from within a critical section? Something like
    >> doStuff_critical() with the "_critical" telling you the requirement
    >> for a critical section. But of course less ugly.
    >>
    >> Any ideas?

    >
    > zephodBeebleBrox_function


    How does appending "_function" to the name suggest critical sections? Or
    did you mean something else?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Aug 9, 2012
    #5
  6. Re: How to name a function to indicate that they require callingfrom a critical section?

    On 09/08/2012 21:58, Keith Thompson wrote:
    > Andrew Cooper <> writes:
    >> On 09/08/2012 02:55, wrote:
    >>> Good programmers know about critical sections, which protect shared
    >>> resources. Good programmers use descriptive names. I just spent a day
    >>> tracking down a real-time bug due to me calling a function outside a
    >>> critical section.
    >>>
    >>> How would you name a function to indicate that it should only be
    >>> called from within a critical section? Something like
    >>> doStuff_critical() with the "_critical" telling you the requirement
    >>> for a critical section. But of course less ugly.

    >>
    >> By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
    >> is the actual implementation, with assumptions about locks etc in the
    >> comments, and foo() is a wrapper which takes the correct lock(s), irq
    >> states etc.
    >>
    >> As a result, non-critical sections can call foo() and bar(), while a
    >> larger complicated critical section can take the relevant locks and call
    >> the required __foo() and __bar() functions.
    >>
    >> (Although it should be noted that kernel critical sections will probably
    >> differ widely from application level critical sections)

    >
    > Identifiers starting with two underscores, or with an underscore and an
    > uppercase letter, are reserved to the implementation; if you define such
    > an identifer yourself, the behavior is undefined.
    >
    > (The kernel is arguably part of the implementation, and even if it
    > isn't, it's probably ok for the developers to rely on certain behaviors
    > that aren't defined by the language standard.)
    >


    I doubt anyone could make a functional kernel while strictly adhering to
    non UD behaviour. There is "what the standard states" and "what
    basically universally works".

    Having said that, because of narrow architecture targets of kernels, you
    can perhaps rely substantially more on "what will work" while strictly
    being UD.

    ~Andrew (who had never really pondered this before)
    Andrew Cooper, Aug 9, 2012
    #6
  7. Eric Sosman Guest

    Re: How to name a function to indicate that they require callingfrom a critical section?

    On 8/9/2012 6:11 PM, Andrew Cooper wrote:
    > On 09/08/2012 21:58, Keith Thompson wrote:
    >> [...]
    >> Identifiers starting with two underscores, or with an underscore and an
    >> uppercase letter, are reserved to the implementation; if you define such
    >> an identifer yourself, the behavior is undefined.
    >>
    >> (The kernel is arguably part of the implementation, and even if it
    >> isn't, it's probably ok for the developers to rely on certain behaviors
    >> that aren't defined by the language standard.)
    >>

    >
    > I doubt anyone could make a functional kernel while strictly adhering to
    > non UD behaviour. There is "what the standard states" and "what
    > basically universally works".


    If you hadn't said "universally" I'd have agreed with you,
    more or less. But it is *not* universally true that you're
    free to start your identifiers with __ and have things "work."
    Even if you can get away with the particular set of __xxx you
    use today with the particular compiler and options you use today,
    you may find yourself in trouble tomorrow when you upgrade to the
    next compiler version or invent a new identifier or even #include
    a new header.

    Example: Try this in gcc:

    #include <stdio.h>
    static const char *whom(void) {
    return "World";
    }
    int main(void) {
    printf("Hello, %s!\n", whom());
    }

    Everything working? Okay, now change the identifier `whom' to
    `__attribute__'.


    > Having said that, because of narrow architecture targets of kernels, you
    > can perhaps rely substantially more on "what will work" while strictly
    > being UD.


    Agreed that you can -- indeed, must -- rely on a lot of things
    the C language itself does not guarantee. But adopting a dubious
    naming convention (when there are plenty of others available) is
    begging for trouble just for the thrill of begging.

    --
    Eric Sosman
    d
    Eric Sosman, Aug 9, 2012
    #7
  8. Tim Rentsch Guest

    Re: How to name a function to indicate that they require calling from a critical section?

    Keith Thompson <> writes:

    > Andrew Cooper <> writes:

    [snip]
    >> By and large, Linux and Xen tend to use foo() and __foo(), where __foo()
    >> is the actual implementation, [snip]

    >
    > Identifiers starting with two underscores, or with an underscore and an
    > uppercase letter, are reserved to the implementation; if you define such
    > an identifer yourself, the behavior is undefined.
    >
    > (The kernel is arguably part of the implementation, and even if it
    > isn't, it's probably ok for the developers to rely on certain behaviors
    > that aren't defined by the language standard.)


    The Linux kernel is part of no existing C implementation. And,
    even if it were, it is not part of implementations running on
    other operating systems (eg MS windows or MacOS), yet presumably
    it's expected to be compileable some such environments, so it's
    still breaking the rules regarding reserved identifiers.

    Don't get me wrong, it's no big deal that these particular
    rules are being broken in this case, but that doesn't mean
    the rules aren't being broken.
    Tim Rentsch, Sep 7, 2012
    #8
  9. Re: How to name a function to indicate that they require callingfrom a critical section?

    On 07-Sep-12 10:37, Tim Rentsch wrote:
    > Keith Thompson <> writes:
    >> (The kernel is arguably part of the implementation, and even if it
    >> isn't, it's probably ok for the developers to rely on certain
    >> behaviors that aren't defined by the language standard.)

    >
    > The Linux kernel is part of no existing C implementation.


    The _running_ kernel is arguably part of the implementation; the kernel
    _source being compiled_ is not.

    > And, even if it were, it is not part of implementations running on other
    > operating systems (eg MS windows or MacOS), yet presumably it's expected
    > to be compileable some such environments, so it's still breaking the
    > rules regarding reserved identifiers.


    The Linux kernel is only expected to be compilable by GCC, and successfully
    compiling the Linux kernel is a gate in the GCC release process, so the two
    are intimately tied together.

    I would expect the same of Windows and MSVC, etc. Kernels are special.

    > Don't get me wrong, it's no big deal that these particular rules are
    > being broken in this case, but that doesn't mean the rules aren't being
    > broken.


    In such a case, the normal rules are simply not relevant.

    OTOH, that also means that one should always be careful before using kernel
    source as an example of how to write non-kernel source.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Sep 7, 2012
    #9
  10. Tim Rentsch Guest

    Re: How to name a function to indicate that they require calling from a critical section?

    Stephen Sprunk <> writes:

    > On 07-Sep-12 10:37, Tim Rentsch wrote:
    >> Keith Thompson <> writes:
    >>> (The kernel is arguably part of the implementation, and even if it
    >>> isn't, it's probably ok for the developers to rely on certain
    >>> behaviors that aren't defined by the language standard.)

    >>
    >> The Linux kernel is part of no existing C implementation.

    >
    > The _running_ kernel is arguably part of the implementation;


    You mean it's arguably part of _an_ implementation. I will
    take up this question further on.

    > the kernel _source being compiled_ is not.
    >
    >> And, even if it were, it is not part of implementations running on other
    >> operating systems (eg MS windows or MacOS), yet presumably it's expected
    >> to be compileable some such environments, so it's still breaking the
    >> rules regarding reserved identifiers.

    >
    > The Linux kernel is only expected to be compilable by GCC,


    Doesn't change my point, since GCC runs on systems besides
    Linux.

    > and successfully compiling the Linux kernel is a gate in the
    > GCC release process, so the two are intimately tied together.


    That doesn't make Linux part of a gcc implementation, any more
    than a requirement for a successful compilation of 'rogue' would
    make 'rogue' part of gcc implementations.

    > I would expect the same of Windows and MSVC, etc. Kernels are
    > special.


    Kernels generally are more dependent on their compilation
    environment than other programs. From a compiler's point
    of view though they are still just programs.

    >> Don't get me wrong, it's no big deal that these particular
    >> rules are being broken in this case, but that doesn't mean the
    >> rules aren't being broken.

    >
    > In such a case, the normal rules are simply not relevant.


    The rules are relevant precisely because the kernel must
    ensure that the rules it chooses to violate won't be
    messed up by any implementation-reserved decisions made
    by the compiler in question. If the kernel didn't break
    any rules, then it wouldn't matter which compiler is
    used to compile it; it's because the kernel _does_ break
    rules that it needs to be choosy about which compilers
    it uses. What I think you mean is that, because the
    kernel is compiled with a compiler that doesn't exhibit
    destructive interference over the rules the kernel does
    break, breaking those rules does not have any negative
    effects; and certainly that is true (by definition
    it would have to be).

    > OTOH, that also means that one should always be careful before
    > using kernel source as an example of how to write non-kernel
    > source.


    I agree with that, but I think that's more an artifact of
    expecting certain definitions of implementation-defined and
    implementation-dependent behavior than it is of being a kernel.
    Kernels are more prone to rely on those things than most
    programs; but so also are many or most programs that run
    on bare hardware, and certainly not all of those are kernels.

    On the earlier question of whether Linux (or any typical modern
    operating system) is part of a C implementations --

    Paragraph 1 of section 5 says

    An implementation translates C source files and executes C
    programs in two data-processing-system environments, which
    will be called the /translation environment/ and the
    /execution environment/ in this International Standard.

    Paragraph 2 of section 1 says

    This International Standard does not specify

    [...other items...]

    . all minimal requirements of a data-processing system that
    is capable of supporting a conforming implementation.

    My argument is that a running Linux kernel supplies an execution
    environment (and perhaps also a translation environment), which
    under the descriptions in sections 1 and 5 is a data-processing
    system, and as such these /support/ conforming implementations but
    are not themselves /part of/ conforming implementations. The
    Standard draws a distinct boundary between the two; and conventional
    operating systems are clearly on the non-implementation side of that
    boundary.
    Tim Rentsch, Sep 8, 2012
    #10
  11. Ian Collins Guest

    Re: How to name a function to indicate that they require callingfrom a critical section?

    On 09/ 8/12 09:01 AM, Stephen Sprunk wrote:
    > On 07-Sep-12 10:37, Tim Rentsch wrote:
    >> Keith Thompson<> writes:
    >>> (The kernel is arguably part of the implementation, and even if it
    >>> isn't, it's probably ok for the developers to rely on certain
    >>> behaviors that aren't defined by the language standard.)

    >>
    >> The Linux kernel is part of no existing C implementation.

    >
    > The _running_ kernel is arguably part of the implementation; the kernel
    > _source being compiled_ is not.
    >
    >> And, even if it were, it is not part of implementations running on other
    >> operating systems (eg MS windows or MacOS), yet presumably it's expected
    >> to be compileable some such environments, so it's still breaking the
    >> rules regarding reserved identifiers.

    >
    > The Linux kernel is only expected to be compilable by GCC, and successfully
    > compiling the Linux kernel is a gate in the GCC release process, so the two
    > are intimately tied together.
    >
    > I would expect the same of Windows and MSVC, etc. Kernels are special.


    Not necessarily. One of the early tasks when the Solaris kernel was
    open-sourced was to get it to compile cleanly with gcc as well as the
    native compiler. This took a while, but in the process removed a lot of
    cruft from the source. Just like any other code base, being able to
    compile with more than one compiler is a good way to improve and
    maintain code quality. From my occasional exposure to it, my impression
    is the Linux kernel is a lost cause when it comes to compiler portability!

    Due to their size and reliance on high levels of optimisation, kernels
    are more susceptible than most applications to compiler bugs. This
    should be seen as an opportunity to improve compiler quality rather than
    a direct coupling.

    >> Don't get me wrong, it's no big deal that these particular rules are
    >> being broken in this case, but that doesn't mean the rules aren't being
    >> broken.

    >
    > In such a case, the normal rules are simply not relevant.
    >
    > OTOH, that also means that one should always be careful before using kernel
    > source as an example of how to write non-kernel source.


    See above.

    --
    Ian Collins
    Ian Collins, Sep 8, 2012
    #11
  12. Re: How to name a function to indicate that they require callingfrom a critical section?

    On 07-Sep-12 20:37, Tim Rentsch wrote:
    > Stephen Sprunk <> writes:
    >> On 07-Sep-12 10:37, Tim Rentsch wrote:
    >>> Keith Thompson <> writes:
    >>>> (The kernel is arguably part of the implementation, and even if
    >>>> it isn't, it's probably ok for the developers to rely on
    >>>> certain behaviors that aren't defined by the language
    >>>> standard.)
    >>>
    >>> The Linux kernel is part of no existing C implementation.

    >>
    >> The _running_ kernel is arguably part of the implementation;

    >
    > You mean it's arguably part of _an_ implementation. I will take up
    > this question further on.


    I was assuming the context of compiling the Linux kernel on a running
    Linux system. Obviously, if you're compiling the Linux kernel with a
    cross-compiler running on some other OS, then the Linux kernel would not
    be part of the implementation.

    My point was that it's not the kernel source that was being claimed to
    be part of the implementation.

    >> the kernel _source being compiled_ is not.
    >>
    >>> And, even if it were, it is not part of implementations running
    >>> on other operating systems (eg MS windows or MacOS), yet
    >>> presumably it's expected to be compileable some such
    >>> environments, so it's still breaking the rules regarding reserved
    >>> identifiers.

    >>
    >> The Linux kernel is only expected to be compilable by GCC,

    >
    > Doesn't change my point, since GCC runs on systems besides Linux.


    True, except that it undercuts the justification for your point. If the
    Linux kernel is only expected to be compilable by GCC, then it is free
    to take advantage of GCC's implementation-defined behavior--and that is
    exactly what started this discussion.

    >> and successfully compiling the Linux kernel is a gate in the GCC
    >> release process, so the two are intimately tied together.

    >
    > That doesn't make Linux part of a gcc implementation, any more than a
    > requirement for a successful compilation of 'rogue' would make
    > 'rogue' part of gcc implementations.
    >
    >> I would expect the same of Windows and MSVC, etc. Kernels are
    >> special.

    >
    > Kernels generally are more dependent on their compilation environment
    > than other programs. From a compiler's point of view though they are
    > still just programs.


    That depends. When GCC has flags (eg. -cmodel=kernel) to tell the
    compiler to use a special mode only for kernels, that seems to imply
    kernels are not "just programs."

    Also, a few years ago GCC added an optimization that _only_ broke
    kernels: it removed null pointer checks after a pointer had been
    dereferenced on the assumption that if the pointer had been null,
    execution could not have continued. That assumption does not hold in
    kernel mode, though, which resulted in a security vulnerability in the
    Linux kernel. Kernels _are_ different in practice, not just theory.

    >>> Don't get me wrong, it's no big deal that these particular rules
    >>> are being broken in this case, but that doesn't mean the rules
    >>> aren't being broken.

    >>
    >> In such a case, the normal rules are simply not relevant.

    >
    > The rules are relevant precisely because the kernel must ensure that
    > the rules it chooses to violate won't be messed up by any
    > implementation-reserved decisions made by the compiler in question.


    .... unless the implementation has made an explicit statement that it
    will not violate any assumptions the kernel makes, as in the case of GCC
    with respect to the Linux kernel. (Including, for instance, the
    assumption that dereferencing a null pointer has well-defined behavior.)

    Note that this does _not_ apply to other kernels that may be compiled
    with GCC, in which case your point would be valid.

    > If the kernel didn't break any rules, then it wouldn't matter which
    > compiler is used to compile it; it's because the kernel _does_
    > break rules that it needs to be choosy about which compilers it uses.


    True, but nobody seems to care about that.

    Well, Intel seems to have cared, to the point that being able to compile
    the Linux kernel was considered a "must have" for ICC to be viable in
    the Linux market. That wouldn't have been such a big deal if the kernel
    didn't take advantage of--or dictate--GCC's peculiarities.

    > What I think you mean is that, because the kernel is compiled with a
    > compiler that doesn't exhibit destructive interference over the rules
    > the kernel does break, breaking those rules does not have any
    > negative effects; and certainly that is true (by definition it would
    > have to be).


    I'm not sure what you mean here.

    >> OTOH, that also means that one should always be careful before
    >> using kernel source as an example of how to write non-kernel
    >> source.

    >
    > I agree with that, but I think that's more an artifact of expecting
    > certain definitions of implementation-defined and
    > implementation-dependent behavior than it is of being a kernel.
    > Kernels are more prone to rely on those things than most programs;
    > but so also are many or most programs that run on bare hardware, and
    > certainly not all of those are kernels.


    That leads to debating what we're really referring to by the term
    "kernel", since I doubt we're really restricting it to just OS kernels
    but rather any software that runs directly on the hardware without any
    intermediary.

    > My argument is that a running Linux kernel supplies an execution
    > environment (and perhaps also a translation environment), which under
    > the descriptions in sections 1 and 5 is a data-processing system, and
    > as such these /support/ conforming implementations but are not
    > themselves /part of/ conforming implementations.


    Fair enough.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Sep 30, 2012
    #12
  13. Re: How to name a function to indicate that they require callingfrom a critical section?

    On 07-Sep-12 20:56, Ian Collins wrote:
    > On 09/ 8/12 09:01 AM, Stephen Sprunk wrote:
    >> On 07-Sep-12 10:37, Tim Rentsch wrote:
    >>> Keith Thompson<> writes:
    >>> And, even if [the kernel] were [part of the implementation], it
    >>> is not part of implementations running on other operating systems
    >>> (eg MS windows or MacOS), yet presumably it's expected to be
    >>> compileable some such environments, so it's still breaking the
    >>> rules regarding reserved identifiers.

    >>
    >> The Linux kernel is only expected to be compilable by GCC, and
    >> successfully compiling the Linux kernel is a gate in the GCC
    >> release process, so the two are intimately tied together.
    >>
    >> I would expect the same of Windows and MSVC, etc. Kernels are
    >> special.

    >
    > Not necessarily. One of the early tasks when the Solaris kernel was
    > open-sourced was to get it to compile cleanly with gcc as well as the
    > native compiler. This took a while, but in the process removed a lot
    > of cruft from the source. Just like any other code base, being able
    > to compile with more than one compiler is a good way to improve and
    > maintain code quality.


    I agree that making code portable tends to increase quality, but that's
    not really the point.

    > From my occasional exposure to it, my impression is the Linux kernel
    > is a lost cause when it comes to compiler portability!


    Probably. I'll note that the ICC folks chose to copy GCC's "features"
    rather than change the Linux kernel source itself to be more portable.
    I don't know what drove that decision, nor am I qualified to judge
    whether the kernel developers are justified in the use of said
    "features" in the first place, since they're obviously more skilled than
    I am.

    > Due to their size and reliance on high levels of optimisation,
    > kernels are more susceptible than most applications to compiler
    > bugs.


    I don't think it's bugs per se but that kernels, by their nature, tend
    to rely on behaviors that the Standard does not (and cannot) guarantee,
    which means they become tied to the particular compiler(s) used to
    compile them.

    IMHO, the ability to write both portable and non-portable code in the
    same language is one of C's strengths--and a reason for its enduring
    success. However, it takes discipline to segregate the two types of
    code, which apparently many people (including those who write books)
    seem to be lacking.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Sep 30, 2012
    #13
  14. Tim Rentsch Guest

    Re: How to name a function to indicate that they require calling from a critical section?

    Stephen Sprunk <> writes:

    > On 07-Sep-12 20:37, Tim Rentsch wrote:
    >> Stephen Sprunk <> writes:
    >>> On 07-Sep-12 10:37, Tim Rentsch wrote:
    >>>> Keith Thompson <> writes:
    >>>>> (The kernel is arguably part of the implementation, and even if
    >>>>> it isn't, it's probably ok for the developers to rely on
    >>>>> certain behaviors that aren't defined by the language
    >>>>> standard.)
    >>>>
    >>>> The Linux kernel is part of no existing C implementation.
    >>>
    >>> The _running_ kernel is arguably part of the implementation;

    >>
    >> You mean it's arguably part of _an_ implementation. I will take up
    >> this question further on.

    >
    > I was assuming the context of compiling the Linux kernel on a running
    > Linux system. Obviously, if you're compiling the Linux kernel with a
    > cross-compiler running on some other OS, then the Linux kernel would not
    > be part of the implementation.
    >
    > My point was that it's not the kernel source that was being claimed to
    > be part of the implementation.
    >
    >>> the kernel _source being compiled_ is not.
    >>>
    >>>> And, even if it were, it is not part of implementations running
    >>>> on other operating systems (eg MS windows or MacOS), yet
    >>>> presumably it's expected to be compileable some such
    >>>> environments, so it's still breaking the rules regarding reserved
    >>>> identifiers.
    >>>
    >>> The Linux kernel is only expected to be compilable by GCC,

    >>
    >> Doesn't change my point, since GCC runs on systems besides Linux.

    >
    > True, except that it undercuts the justification for your point. If the
    > Linux kernel is only expected to be compilable by GCC, then it is free
    > to take advantage of GCC's implementation-defined behavior--and that is
    > exactly what started this discussion.
    >
    >>> and successfully compiling the Linux kernel is a gate in the GCC
    >>> release process, so the two are intimately tied together.

    >>
    >> That doesn't make Linux part of a gcc implementation, any more than a
    >> requirement for a successful compilation of 'rogue' would make
    >> 'rogue' part of gcc implementations.
    >>
    >>> I would expect the same of Windows and MSVC, etc. Kernels are
    >>> special.

    >>
    >> Kernels generally are more dependent on their compilation environment
    >> than other programs. From a compiler's point of view though they are
    >> still just programs.

    >
    > That depends. When GCC has flags (eg. -cmodel=kernel) to tell the
    > compiler to use a special mode only for kernels, that seems to imply
    > kernels are not "just programs."
    >
    > Also, a few years ago GCC added an optimization that _only_ broke
    > kernels: it removed null pointer checks after a pointer had been
    > dereferenced on the assumption that if the pointer had been null,
    > execution could not have continued. That assumption does not hold in
    > kernel mode, though, which resulted in a security vulnerability in the
    > Linux kernel. Kernels _are_ different in practice, not just theory.
    >
    >>>> Don't get me wrong, it's no big deal that these particular rules
    >>>> are being broken in this case, but that doesn't mean the rules
    >>>> aren't being broken.
    >>>
    >>> In such a case, the normal rules are simply not relevant.

    >>
    >> The rules are relevant precisely because the kernel must ensure that
    >> the rules it chooses to violate won't be messed up by any
    >> implementation-reserved decisions made by the compiler in question.

    >
    > ... unless the implementation has made an explicit statement that it
    > will not violate any assumptions the kernel makes, as in the case of GCC
    > with respect to the Linux kernel. (Including, for instance, the
    > assumption that dereferencing a null pointer has well-defined behavior.)
    >
    > Note that this does _not_ apply to other kernels that may be compiled
    > with GCC, in which case your point would be valid.
    >
    >> If the kernel didn't break any rules, then it wouldn't matter which
    >> compiler is used to compile it; it's because the kernel _does_
    >> break rules that it needs to be choosy about which compilers it uses.

    >
    > True, but nobody seems to care about that.
    >
    > Well, Intel seems to have cared, to the point that being able to compile
    > the Linux kernel was considered a "must have" for ICC to be viable in
    > the Linux market. That wouldn't have been such a big deal if the kernel
    > didn't take advantage of--or dictate--GCC's peculiarities.
    >
    >> What I think you mean is that, because the kernel is compiled with a
    >> compiler that doesn't exhibit destructive interference over the rules
    >> the kernel does break, breaking those rules does not have any
    >> negative effects; and certainly that is true (by definition it would
    >> have to be).

    >
    > I'm not sure what you mean here.
    >
    >>> OTOH, that also means that one should always be careful before
    >>> using kernel source as an example of how to write non-kernel
    >>> source.

    >>
    >> I agree with that, but I think that's more an artifact of expecting
    >> certain definitions of implementation-defined and
    >> implementation-dependent behavior than it is of being a kernel.
    >> Kernels are more prone to rely on those things than most programs;
    >> but so also are many or most programs that run on bare hardware, and
    >> certainly not all of those are kernels.

    >
    > That leads to debating what we're really referring to by the term
    > "kernel", since I doubt we're really restricting it to just OS kernels
    > but rather any software that runs directly on the hardware without any
    > intermediary.
    >
    >> My argument is that a running Linux kernel supplies an execution
    >> environment (and perhaps also a translation environment), which under
    >> the descriptions in sections 1 and 5 is a data-processing system, and
    >> as such these /support/ conforming implementations but are not
    >> themselves /part of/ conforming implementations.

    >
    > Fair enough.


    Rather than trying to respond point-by-point, let me summarize.

    What I think you're saying is that, for all practical purposes,
    gcc is effectively part of the Linux kernel; the Linux kernel
    depends so much on gcc for its compilation that the kernel
    as a runnable entity basically doesn't exist without gcc.

    What I'm trying to say is that, even granting that gcc is part
    of the Linux kernel, the Linux kernel is not part of any gcc
    implementation. And I think you agreed to that right at the
    end there.

    As long as you agree with those last two paragraphs, I think
    we're all good.
    Tim Rentsch, Dec 17, 2012
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Asfand Yar Qazi
    Replies:
    4
    Views:
    396
    Asfand Yar Qazi
    Nov 12, 2004
  2. Martin M.
    Replies:
    4
    Views:
    341
    Simon Brunning
    Dec 15, 2005
  3. David Mathog

    compiler switch to indicate "end of function"?

    David Mathog, May 10, 2011, in forum: C Programming
    Replies:
    32
    Views:
    799
  4. Ray Song
    Replies:
    10
    Views:
    307
  5. kampy
    Replies:
    9
    Views:
    328
    Steven D'Aprano
    Oct 19, 2012
Loading...

Share This Page