Linux Kernel Source

Discussion in 'C Programming' started by Billy Bong, Jan 22, 2008.

  1. Billy Bong

    Billy Bong Guest

    Hi guys!

    I recently downloaded the Linux Kernel source code, in the hopes of
    learning a thing or two about how the "pros" do it in C.

    Much to my chagrin, I inevitably came across comments that included the
    words "kludge" and "FIXME" in the Linux Kernel source code.

    Because I'm a curious kind of creature, I decided to search the entire
    Linux Kernel source code for instances of "kludge" and "FIXME". And here
    is what I found:

    kludge: 154 occurrences
    FIXME: 3120 occurrences

    These results seem rather striking to me. After all, the Linux Kernel
    source is "open source", and, frankly, I expected to find 0 occurrences
    of both these search strings, given that we should have multitudes of
    programmers working on this source and fixing the bugs in what I pretty
    much expect should be real-time.

    Because I'm a curious kind of creature, I decided to search the entire
    Microsoft MFC source code for instances of "kludge" and "FIXME". And here
    is what I found:

    kludge: 0 occurrence(s)
    FIXME: 0 occurrence(s)

    At this point, I'm feeling pretty damned hoodwinked. That desktop graphic
    of the penguin sucking on a cardboard drink container with the Windows XP
    logo and the words "We suck more!" on it look really appealing, but what
    is really behind all that--just a dog-and-pony show?

    My C question is the following:

    Is it good practice to comment our code with words like "kludge" and
    "FIXME"?

    If so, what does that say about our requirements in specific, and our
    development process in general?

    And if so, shouldn't we expect nothing less than undefined behavior?

    And if not, what does that say about the Linux Kernel source code?

    I notice that many of the Linux Kernel source code files list Linus
    Torvalds as an author. I wonder if he is aware of this apparent disarray
    of the current Linux Kernel source code? If someone has his phone number,
    perhaps they might try calling him to inform him of the current situation
    as described above to see what he thinks, and report back here with a
    transcript of the conversation.

    For those of you who think I'm a pro-Microsoft dude and a Linux basher,
    think again. I'm posting this from Linux. I just don't have the same
    confidence in this Linux OS that I had when I installed it--based on the
    evidence I presented, of course.

    --
    Billy
     
    Billy Bong, Jan 22, 2008
    #1
    1. Advertising

  2. Billy Bong <> writes:

    >
    > Much to my chagrin, I inevitably came across comments that included the
    > words "kludge" and "FIXME" in the Linux Kernel source code.
    >
    > Because I'm a curious kind of creature, I decided to search the entire
    > Linux Kernel source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences
    >
    > These results seem rather striking to me. After all, the Linux Kernel
    > source is "open source", and, frankly, I expected to find 0 occurrences
    > of both these search strings, given that we should have multitudes of
    > programmers working on this source and fixing the bugs in what I pretty
    > much expect should be real-time.

    Well I do bet that MS has more programmers working on their OSes then
    Linux. And the code above just implies to me: The people see that
    things are broken and they name it. The multitude of programmers is an
    illusion.
    >
    > Because I'm a curious kind of creature, I decided to search the entire
    > Microsoft MFC source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 0 occurrence(s)
    > FIXME: 0 occurrence(s)

    Is that really a suprise? You must use MS speak for finding that
    things. You can not expect them to say straigt-forward. "oh that
    sucks"....

    Regards
    Friedrich




    --
    Please remove just-for-news- to reply via e-mail.
     
    Friedrich Dominicus, Jan 22, 2008
    #2
    1. Advertising

  3. Billy Bong

    santosh Guest

    Billy Bong wrote:

    > Hi guys!
    >
    > I recently downloaded the Linux Kernel source code, in the hopes of
    > learning a thing or two about how the "pros" do it in C.


    Unless you are fairly competent with C, it's probably going to confuse
    you further.

    > Much to my chagrin, I inevitably came across comments that included
    > the words "kludge" and "FIXME" in the Linux Kernel source code.
    >
    > Because I'm a curious kind of creature, I decided to search the entire
    > Linux Kernel source code for instances of "kludge" and "FIXME". And
    > here is what I found:
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences
    >
    > These results seem rather striking to me. After all, the Linux Kernel
    > source is "open source", and, frankly, I expected to find 0
    > occurrences of both these search strings, given that we should have
    > multitudes of programmers working on this source and fixing the bugs
    > in what I pretty much expect should be real-time.


    That just shows that you are inexperienced with developing large
    software systems. I would say that those figures that you have shown
    above (assuming that they are correct), are actually quite acceptable
    given the size of the software concerned and it's development
    methodology.

    Also note that "kludge" and "FIXME" don't necessarily mean bugs. It may
    simply mean that the tagged code is less than ideal.

    > Because I'm a curious kind of creature, I decided to search the entire
    > Microsoft MFC source code for instances of "kludge" and "FIXME". And
    > here is what I found:
    >
    > kludge: 0 occurrence(s)
    > FIXME: 0 occurrence(s)
    >
    > At this point, I'm feeling pretty damned hoodwinked. That desktop
    > graphic of the penguin sucking on a cardboard drink container with the
    > Windows XP logo and the words "We suck more!" on it look really
    > appealing, but what is really behind all that--just a dog-and-pony
    > show?


    If that's how you feel, then you should give Linux and pass and go play
    with your shiny new Microsoft (R) Windows (R) Vista (TM) Ultimate (TM)
    Edition.

    > My C question is the following:
    >
    > Is it good practice to comment our code with words like "kludge" and
    > "FIXME"?


    If it is used consistently within the project then I don't see any
    obvious objections.

    > If so, what does that say about our requirements in specific, and our
    > development process in general?


    Huh?

    > And if so, shouldn't we expect nothing less than undefined behavior?


    Not necessarily. It really depends on a case by case basis. As I said
    earlier, some instances of code tagged as such may simply indicate a
    contorted solution, or a less than ideal algorithm, or more than
    necessary assumptions. Such code needn't exhibit undefined behaviour at
    all.

    Moreover in system software like Linux, undefined behaviour is not quite
    the same as it is defined by the C Standard. Generally a portion of
    code will either work or not work, barring errors. Not working might
    either be okay (example the device associated with a driver is not
    installed), less than ideal but all right (advanced ACPI is not
    enabled, but system is otherwise usable), broken functionally (a
    particular peripheral is disabled), or outright panic (a fundamental
    problem either with the hardware or core portions of the system
    software, making the system totally unusable).

    I would reserve the term undefined behaviour for describing the outcome
    of the machine state after a serious error like buffer overflow has
    been triggerred within the kernel.

    > And if not, what does that say about the Linux Kernel source code?


    Form your own conclusions and don't expect anyone to give them the least
    weightage.

    > I notice that many of the Linux Kernel source code files list Linus
    > Torvalds as an author. I wonder if he is aware of this apparent
    > disarray of the current Linux Kernel source code? If someone has his
    > phone number, perhaps they might try calling him to inform him of the
    > current situation as described above to see what he thinks, and report
    > back here with a transcript of the conversation.


    What disarray? If you feel so passionately about perceived bugs in the
    Linux kernel, why don't you go ahead and fix them and submit your
    patches to Linus? Or perhaps call him and make your concerns known. Be
    sure to post the transcript of your conversation with Linus. It would
    be an amusing change from the usual stuff trotted out by Kenny and Co.

    > For those of you who think I'm a pro-Microsoft dude and a Linux
    > basher, think again. I'm posting this from Linux. I just don't have
    > the same confidence in this Linux OS that I had when I installed
    > it--based on the evidence I presented, of course.


    A good test of a piece of software is actually trying it out under field
    conditions. If, after trying it out for a reasonable period of time,
    you find Linux not to your taste (or your hardware's) then fine. Use
    something else. Perhaps MacOS or BSD? Or perhaps Windows? Linux isn't a
    solution for all users, neither does it claim to be, unlike Microsoft.
     
    santosh, Jan 22, 2008
    #3
  4. Billy Bong

    Ian Collins Guest

    Billy Bong wrote:
    > Hi guys!
    >
    > I recently downloaded the Linux Kernel source code, in the hopes of
    > learning a thing or two about how the "pros" do it in C.
    >

    Make that Linux developers do it in gcc, which isn't the same thing!
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences
    >
    > These results seem rather striking to me. After all, the Linux Kernel
    > source is "open source", and, frankly, I expected to find 0 occurrences
    > of both these search strings, given that we should have multitudes of
    > programmers working on this source and fixing the bugs in what I pretty
    > much expect should be real-time.
    >

    Why? They probably aren't bugs but less than ideal or messy solutions.
    Look at the code and see why the comment is there.

    > Because I'm a curious kind of creature, I decided to search the entire
    > Microsoft MFC source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >

    MFC is a library, not an Kernel. It also comes form a source who are
    hardly likely to be open about such things. To many, MFC in its
    entirety is a kludge!

    Try the same thing with the Vista source...

    <OT>The scores for the OpenSolaris kernel are 227 and 173</OT>
    >
    > My C question is the following:
    >
    > Is it good practice to comment our code with words like "kludge" and
    > "FIXME"?
    >

    Yes, there are often compromises, code the works but is inelegant.

    --
    Ian Collins.
     
    Ian Collins, Jan 22, 2008
    #4
  5. Ian Collins wrote:
    > Billy Bong wrote:


    >> Is it good practice to comment our code with words like "kludge" and
    >> "FIXME"?
    >>

    > Yes, there are often compromises, code the works but is inelegant.


    I remember a colleague's comment in a mobile phone source code: "I am
    proud of this goto statement!" Unfortunately, exactly this part
    contained the bug I had to fix, and, sad to say, I removed the goto
    again.

    Regards
    Steffen
     
    Steffen Buehler, Jan 22, 2008
    #5
  6. Billy Bong

    Guest

    This discussion is off-topic here, and would be better in a Linux or
    MS advocacy group, even as your intend was to learn C. Learning C can
    be done by reading a lot of code, but it is better to start with some
    small project, where you could try to get involved in the development.
    Next to learning C you would also be helping the development.

    On Jan 22, 7:19 am, Billy Bong <> wrote:
    > I recently downloaded the Linux Kernel source code, in the hopes of
    > learning a thing or two about how the "pros" do it in C.


    > Because I'm a curious kind of creature, I decided to search the entire
    > Linux Kernel source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences
    >


    From MFC:
    > kludge: 0 occurrence(s)
    > FIXME: 0 occurrence(s)


    Look at this from another point of view: MS is shipping a commercial
    product. Wouldn't you feel bad if you bought something with labels on
    it like "fixme", "broken", "kludge", etc.? I guess MS probably has
    some kind of filter to get these comments out of their code before
    releasing a product. The fact that there are no keywords like these in
    the code to me can indicate a number of things:
    - Filter (as indicated)
    - Separate quality control: problems in SW are entered in a database
    and not in the code
    - Unqualified developers
    I expect that the first 2 are in effect at MS, however I cannot
    exclude the last one :) As MS is a large company they certainly have
    some QC tooling in place.

    The fact that you find these in the Linux kernel is explained by the
    fact that this is a project in development. These indications are only
    for other developers, to indicate that some improvements can be made.
    Of course there are some places where these FIXME's indicate real
    problems, but usually there are workarounds in place.
    Some examples of FIXME's:
    udelay(1000); /* FIXME: seems a little long */
    /* FIXME: obviously we want to put this in a header file soon */
    /* FIXME: i don't like this... looks wrong */

    Kind regards,
    Johan Borkhuis
     
    , Jan 22, 2008
    #6
  7. Billy Bong said:

    > Hi guys!
    >
    > I recently downloaded the Linux Kernel source code, in the hopes of
    > learning a thing or two about how the "pros" do it in C.


    Um, right. Believe it or not, that's kind of off-topic here, and it's
    pretty much flamebait material - but it may be possible to contribute an
    impassive note or two.

    > Much to my chagrin, I inevitably came across comments that included the
    > words "kludge" and "FIXME" in the Linux Kernel source code.


    Well, there's honesty for you. :)

    > Because I'm a curious kind of creature, I decided to search the entire
    > Linux Kernel source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences


    And there's 3274 honesties for you.

    > These results seem rather striking to me. After all, the Linux Kernel
    > source is "open source", and, frankly, I expected to find 0 occurrences
    > of both these search strings, given that we should have multitudes of
    > programmers working on this source and fixing the bugs in what I pretty
    > much expect should be real-time.


    Why do you expect this? Have you tried fixing any of these 3274 honesties
    yourself? If you're not part of the solution, you're part of the test
    tube. Er, problem. That is to say, if everyone assumes that kludges and
    FIXMEs are Someone Else's Problem, then nobody will ever fix them, will
    they?

    > Because I'm a curious kind of creature, I decided to search the entire
    > Microsoft MFC source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 0 occurrence(s)
    > FIXME: 0 occurrence(s)


    Perhaps they use some other way to indicate problems. TODO might be worth
    grepping for, I don't know. But bear in mind that you're comparing two
    very different things - a class library and a kernel. Also consider that
    MFC is something that MS has been moving away from for some years; why, if
    it's so perfect?

    > At this point, I'm feeling pretty damned hoodwinked.


    Why?

    > That desktop graphic
    > of the penguin sucking on a cardboard drink container with the Windows XP
    > logo and the words "We suck more!" on it look really appealing, but what
    > is really behind all that--just a dog-and-pony show?


    I don't think so. I don't pretend Linux is perfect, but I'm using an
    ancient SuSE distro and it has behaved remarkably well over the years.
    It's roughly contemporary with Windows 2000, but a lot more stable.

    The apps? Ah, that's different. Some of the programs in the distro could
    certainly do with a lot of bug-fixing! But since I'm too lazy to fix them
    myself or upgrade to later versions, I can hardly complain about that.
    They work well enough, even though I wish they worked better. Principal
    culprits? Galeon, Mozilla, Konqueror, Knode, Kmail. Oh, and kdeinit seems
    to get carried away sometimes and hog vast numbers of cycles to no good
    effect. (Of these, I think only kdeinit could reasonably be called a
    system program.)

    I don't use Windows enough nowadays to know how the MS versions of these
    programs have improved over the years, but when I last used Windows a lot,
    they (and it) still seemed pretty buggy. I'm told that it's all a lot more
    stable than it used to be, and I'm glad about that, because frankly it was
    almost unusable up to about 2003 or so.

    > My C question is the following:
    >
    > Is it good practice to comment our code with words like "kludge" and
    > "FIXME"?


    It's better practice to fix the code right away, of course - but people do
    so love adding features, don't they? Besides, one man's kludge is another
    man's craftsmanship. It's not like there's an ISO Standard to define
    "kludge" for us. What I call a kludge, you might be happy with. What you
    say is a FIXME, I might consider perfectly good code.

    > If so, what does that say about our requirements in specific, and our
    > development process in general?


    Very little, actually. But I think you have at least a partial point - many
    of us are too keen to get the thing "working", without worrying enough
    about whether it *works*.

    > And if so, shouldn't we expect nothing less than undefined behavior?


    Quite so.

    > And if not, what does that say about the Linux Kernel source code?


    I don't know - but I do know that I'm pretty happy with the Linux kernel
    I've got. :)

    > I notice that many of the Linux Kernel source code files list Linus
    > Torvalds as an author. I wonder if he is aware of this apparent disarray
    > of the current Linux Kernel source code? If someone has his phone number,
    > perhaps they might try calling him to inform him of the current situation
    > as described above to see what he thinks, and report back here with a
    > transcript of the conversation.


    If anyone does that, be sure to tell him he's being recorded and that you
    intend to publish the transcript. Otherwise, you could be on dodgy ground
    (morally, at the very least).

    > For those of you who think I'm a pro-Microsoft dude and a Linux basher,
    > think again. I'm posting this from Linux. I just don't have the same
    > confidence in this Linux OS that I had when I installed it--based on the
    > evidence I presented, of course.


    The proof of the pudding is in the eating. Does Linux do all that you
    require of it?

    If not, FIXIT. Or use something else. Or put up with it until someone else
    fixes it.

    It's your choice. And remember that, if it weren't for these alternative
    OSs, you wouldn't have that choice.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jan 22, 2008
    #7
  8. santosh wrote:

    > Not necessarily. It really depends on a case by case basis. As I said
    > earlier, some instances of code tagged as such may simply indicate a
    > contorted solution, or a less than ideal algorithm, or more than
    > necessary assumptions. Such code needn't exhibit undefined behaviour at
    > all.


    Moreover, sections labelled as possibly flaky are good starting points when
    a bug needs to be fixed in the affected part of the source.

    robert
     
    Robert Latest, Jan 22, 2008
    #8
  9. Billy Bong wrote:

    > Much to my chagrin, I inevitably came across comments that included the
    > words "kludge" and "FIXME" in the Linux Kernel source code.


    Note that "kludge" probably means that the programmer had to work around
    some issue that he could't resolve for himself, like a piece of kernel API
    written by somebody else, or --very likely-- something to do with some
    hardware.

    Even programming in pure standard C itself requires kludges at times, like
    when the compare function passed to qsort() needs additional data (there was
    a thread about this a while ago on this newsgroup).

    And for the FIXMEs -- don't we all at times hurry through some issue with
    hastily written code that we know we should get back to some time? Either
    because it's potentially buggy, or algorithmically inefficient, or simply
    inelegant? If I attached a FIXME note to each instance where I'm not
    checking printf()s or --much worse-- malloc()s return value there would be
    very little C flesh in between.

    > kludge: 154 occurrences
    > FIXME: 3120 occurrences


    Given God knows how many tens of thousands code lines those number
    (especially the "kludges") seem very modest.

    > Is it good practice to comment our code with words like "kludge" and
    > "FIXME"?


    If we write kludges (which are often necessary) and possibly buggy code (who
    doesn't?) I think it is excellent practice to mark it as such. As a reminder
    to ourselves when we get back to our own code, or as a hint to somebody else
    who may work on it.

    > If so, what does that say about our requirements in specific, and our
    > development process in general?


    It says that we're aware of our own fallacies and don't have a reason to
    hide them from our customers because we're honest, and they expect honesty.

    > And if so, shouldn't we expect nothing less than undefined behavior?


    From marked FIXMEs and kludges and the rest of the code alike, yes.

    > And if not, what does that say about the Linux Kernel source code?


    It says that it was written by people who often knew what they were doing
    and sometimes didn't. In short, by people.

    > I notice that many of the Linux Kernel source code files list Linus
    > Torvalds as an author.


    Surprise ;-)

    > I wonder if he is aware of this apparent disarray
    > of the current Linux Kernel source code?


    He more than most others I'm sure.

    > I just don't have the same
    > confidence in this Linux OS that I had when I installed it--based on the
    > evidence I presented, of course.


    Just don't read system code, from any OS. It's bad for the head.

    robert
     
    Robert Latest, Jan 22, 2008
    #9
  10. Billy Bong

    Syren Baran Guest

    Billy Bong schrieb:
    > Hi guys!
    >
    > Because I'm a curious kind of creature, I decided to search the entire
    > Linux Kernel source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 154 occurrences
    > FIXME: 3120 occurrences

    You are aware of the fact that the kernel consists of over 4 million
    lines of code?
    You are aware of the fact that "make menuconfig"'s first item is "code
    maturity level"?
     
    Syren Baran, Jan 22, 2008
    #10
  11. Billy Bong

    Kaz Kylheku Guest

    On Jan 21, 10:19 pm, Billy Bong <> wrote:
    > Because I'm a curious kind of creature, I decided to search the entire
    > Microsoft MFC source code for instances of "kludge" and "FIXME". And here
    > is what I found:
    >
    > kludge: 0 occurrence(s)
    > FIXME: 0 occurrence(s)


    Hi Billy Bong,

    I hope you realize that in software engineering ``zero occurences''
    really means ``no known occurences''.

    Before you can document something as a kludge or fixme item, you have
    to recognize that what you have written is in fact such a thing.

    I suspect that if I were to review the MFC code line by line, I could
    add in thousands of missing ``kludge'' and ``fixme'' comments.
     
    Kaz Kylheku, Jan 22, 2008
    #11
  12. Billy Bong

    Kaz Kylheku Guest

    On Jan 22, 1:33 am, Richard Heathfield <> wrote:
    > Billy Bong said:
    > > At this point, I'm feeling pretty damned hoodwinked.

    >
    > Why?


    Because that sort of suspicion is the typical reaction of a small
    mind. Someone's always out to pull that proverbial wool over his eyes
    and take advantage of him! But of course, he won't let that happen
    because he's too clever.
     
    Kaz Kylheku, Jan 22, 2008
    #12
  13. Billy Bong

    Bart C Guest

    "Syren Baran" <> wrote in message
    news:47960f02$0$9114$-online.net...
    > Billy Bong schrieb:
    >> Hi guys!
    >>
    >> Because I'm a curious kind of creature, I decided to search the entire
    >> Linux Kernel source code for instances of "kludge" and "FIXME". And here
    >> is what I found:
    >>
    >> kludge: 154 occurrences
    >> FIXME: 3120 occurrences

    > You are aware of the fact that the kernel consists of over 4 million lines
    > of code?


    4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
    some 24 ft/7m high if printed single-sided.

    Surely that can't be right? Is an OS really that complex?

    But then, I remember jacob navia writing about gcc, that each contributor
    wanted to be remembered for what they added to the project, not for what
    they removed. Or something to that effect.

    So software just gets bigger and bigger, because no-one wants to be
    responsible for getting rid of large chunks of someone else's code.

    --
    Bart
     
    Bart C, Jan 23, 2008
    #13
  14. Billy Bong

    santosh Guest

    Bart C wrote:

    >
    > "Syren Baran" <> wrote in message
    > news:47960f02$0$9114$-online.net...
    >> Billy Bong schrieb:
    >>> Hi guys!
    >>>
    >>> Because I'm a curious kind of creature, I decided to search the
    >>> entire Linux Kernel source code for instances of "kludge" and
    >>> "FIXME". And here is what I found:
    >>>
    >>> kludge: 154 occurrences
    >>> FIXME: 3120 occurrences

    >> You are aware of the fact that the kernel consists of over 4 million
    >> lines of code?

    >
    > 4 million lines? Just for a kernel? I make that a stack of 70,000 A4
    > sheets, some 24 ft/7m high if printed single-sided.
    >
    > Surely that can't be right? Is an OS really that complex?


    Ha! If you think four million lines are too much, consider the fact that
    Windows 2000's LoC was estimated at around 30 million. And yes, that
    was about seven years ago. Heavens knows what the LoC count for Vista
    is. I don't even want to know.

    But coming to your question, the bulk of the code for the Linux kernel
    (and I presume most kernels) are from the device drivers. The vast
    variety of devices out there and the imperative for serious OSes to
    support as much of them as possible means that they end up with an
    awful lot of drivers.

    > But then, I remember jacob navia writing about gcc, that each
    > contributor wanted to be remembered for what they added to the
    > project, not for what they removed. Or something to that effect.


    Yes. Maintenance and bug fixing aren't as glamorous as being an original
    contributor.

    > So software just gets bigger and bigger, because no-one wants to be
    > responsible for getting rid of large chunks of someone else's code.


    Not without a good reason. In the case of Linux, there is no reason to
    remove a perfectly working device driver, simply on the account of
    reducing LoC count or because the associated hardware has become a
    rarity. There might still exist someone who wants to use it.

    Also refactoring a large software system is very difficult task and the
    prime motivation for people contributing to open source projects is to
    add functionality rather than spend time correcting and refactoring.
     
    santosh, Jan 23, 2008
    #14
  15. Billy Bong

    Ian Collins Guest

    santosh wrote:
    > Bart C wrote:
    >
    >> 4 million lines? Just for a kernel? I make that a stack of 70,000 A4
    >> sheets, some 24 ft/7m high if printed single-sided.
    >>
    >> Surely that can't be right? Is an OS really that complex?

    >
    > Ha! If you think four million lines are too much, consider the fact that
    > Windows 2000's LoC was estimated at around 30 million. And yes, that
    > was about seven years ago. Heavens knows what the LoC count for Vista
    > is. I don't even want to know.
    >
    > But coming to your question, the bulk of the code for the Linux kernel
    > (and I presume most kernels) are from the device drivers. The vast
    > variety of devices out there and the imperative for serious OSes to
    > support as much of them as possible means that they end up with an
    > awful lot of drivers.
    >

    <OT>
    Gone are the days when kernels had to be rebuilt to add a driver, these
    days with modern kernels, drivers are loadable modules.

    The LOC count probably includes the userland utilities and networking. </OT>

    --
    Ian Collins.
     
    Ian Collins, Jan 23, 2008
    #15
  16. Billy Bong

    Syren Baran Guest

    Bart C schrieb:
    >> You are aware of the fact that the kernel consists of over 4 million lines
    >> of code?

    >
    > 4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
    > some 24 ft/7m high if printed single-sided.
    >
    > Surely that can't be right? Is an OS really that complex?

    Its just the kernel.
    Well over half of it are device drivers.
    Next biggest part is architecture dependent code.

    > But then, I remember jacob navia writing about gcc, that each contributor
    > wanted to be remembered for what they added to the project, not for what
    > they removed. Or something to that effect.

    Well, try that on lkml if you wish, you'll get a spanking.

    > So software just gets bigger and bigger, because no-one wants to be
    > responsible for getting rid of large chunks of someone else's code.

    Nope. Lots of new hardware. Architecture. File-systems. Optional modules.
    >
    > --
    > Bart
     
    Syren Baran, Jan 23, 2008
    #16
  17. Billy Bong

    Kaz Kylheku Guest

    On Jan 22, 6:59 pm, "Bart C" <> wrote:
    > 4 million lines? Just for a kernel? I make that a stack of 70,000 A4 sheets,
    > some 24 ft/7m high if printed single-sided.


    The kernel runs on i386, SPARC, MIPS, PowerPC, Alpha, HP PA-RISC,
    68K, ....

    It supports many, many boards, peripherals, filesystems, networking
    protocols ...

    Get it?

    The vast majority of the kernel code is not in the central parts like
    scheduling and memory management, but in drivers and other modules.

    Nowhere near all of the four million lines of code are compiled in
    whatever Linux setup you may be running.

    This doesn't, by the way, count the kernel code that is /not/ in the
    kernel. There are drivers and various other patches out there are not
    part of the kernel stream.

    > Surely that can't be right? Is an OS really that complex?


    No, and OS is not that complex. But yes, there is a crapload of
    hardware out there, filesystem formats, protocols, etc. They all do
    the same thing in different ways, and so all of the pieces of code to
    handle them resemble each other. If you understand two or three
    network drivers, you've pretty much seen them all.

    > So software just gets bigger and bigger, because no-one wants to be
    > responsible for getting rid of large chunks of someone else's code.


    But you don't necessarily want to get rid of a module, even if it
    drives very old hardware, or a rare, obsolete filesystem format, etc.
    Someone somewhere might be using it.

    What can be done is to push it back out of the kernel stream so that
    it again lives as a patch or stand-alone module. Let the people who
    need that code maintain it themselves.
     
    Kaz Kylheku, Jan 23, 2008
    #17
  18. Billy Bong

    Billy Bong Guest

    On Tue, 22 Jan 2008 10:36:11 -0800, Kaz Kylheku wrote:

    > On Jan 21, 10:19 pm, Billy Bong <> wrote:
    >> Because I'm a curious kind of creature, I decided to search the entire
    >> Microsoft MFC source code for instances of "kludge" and "FIXME". And
    >> here is what I found:
    >>
    >> kludge: 0 occurrence(s)
    >> FIXME: 0 occurrence(s)

    >
    > Hi Billy Bong,


    Hi Kaz,

    > I hope you realize that in software engineering ``zero occurences''
    > really means ``no known occurences''.


    I fully realize that.

    In my experience, any piece of software that is non-trivial still has
    bugs, no matter what confidence you may think you have in regards to it
    not having bugs. I've been there so many times ...

    "This is the final do-all-and-end-all-release that eliminates all the
    bugs."

    But, yes, inevitably, and without fail, someone finds a bug.

    I've learned to expect that.

    But, I've also learned that you or me or someone else may well find a bug
    in my/our software, and I'm somewhat comforted by the fact that me/us
    have done enough of a good job at following our software development
    process (requirements, design, implementation, verification--and CM and
    QA, if available [1]) that the type of bugs that will be uncovered are
    not of the show-stopper type (e.g., crashes).

    > Before you can document something as a kludge or fixme item, you have to
    > recognize that what you have written is in fact such a thing.


    Good point. What frustrates me is that a company such as Microsoft is
    often privy to the types of details that can eliminate "kludges" and
    "FIXMEs", whereas those such as Linux developers are not.

    > I suspect that if I were to review the MFC code line by line, I could
    > add in thousands of missing ``kludge'' and ``fixme'' comments.


    I know firsthand of kludges and fixmes in MFC code. But, I doubt that
    these types of bugs are in the "thousands". My estimate would be that
    they are in the "hundreds", if not the "tens". When you pay someone to do
    something, you can expect better results compared to when you don't pay
    them. Microsoft pays people.

    Best regards
    --
    Billy

    [1] A good question is ... do Linux Kernel developers in specific, or
    open source developers in general, follow a documented software
    development process? Or is it all ad hoc?
     
    Billy Bong, Jan 23, 2008
    #18
  19. Billy Bong

    santosh Guest

    Billy Bong wrote:

    > On Tue, 22 Jan 2008 10:36:11 -0800, Kaz Kylheku wrote:
    >
    >> On Jan 21, 10:19 pm, Billy Bong <> wrote:
    >>> Because I'm a curious kind of creature, I decided to search the
    >>> entire Microsoft MFC source code for instances of "kludge" and
    >>> "FIXME". And here is what I found:
    >>>
    >>> kludge: 0 occurrence(s)
    >>> FIXME: 0 occurrence(s)

    >>
    >> Hi Billy Bong,

    >
    > Hi Kaz,
    >
    >> I hope you realize that in software engineering ``zero occurences''
    >> really means ``no known occurences''.

    >
    > I fully realize that.
    >
    > In my experience, any piece of software that is non-trivial still has
    > bugs, no matter what confidence you may think you have in regards to
    > it not having bugs. I've been there so many times ...
    >
    > "This is the final do-all-and-end-all-release that eliminates all the
    > bugs."
    >
    > But, yes, inevitably, and without fail, someone finds a bug.
    >
    > I've learned to expect that.
    >
    > But, I've also learned that you or me or someone else may well find a
    > bug in my/our software, and I'm somewhat comforted by the fact that
    > me/us have done enough of a good job at following our software
    > development process (requirements, design, implementation,
    > verification--and CM and QA, if available [1]) that the type of bugs
    > that will be uncovered are not of the show-stopper type (e.g.,
    > crashes).


    Oh? Then why does, for example, Microsoft software, (which you'd presume
    to have been the product of the best software engineering practises),
    have so many "show-stopper" buffer overflow vulnerabilities that need
    to be fixed by a continuous rain of patches?

    Why is it that I have had Windows, which by your line of reasoning be
    the superior product, crash more times than I have kept count, while I
    can list the number crashes I have had with Linux on the fingers of one
    hand?

    >> Before you can document something as a kludge or fixme item, you have
    >> to recognize that what you have written is in fact such a thing.

    >
    > Good point. What frustrates me is that a company such as Microsoft is
    > often privy to the types of details that can eliminate "kludges" and
    > "FIXMEs", whereas those such as Linux developers are not.


    What details? Are you saying that Microsoft has magical methods to purge
    code of all bugs, while others must flounder in the dark?

    As far as I can tell, techniques to produce good software are already
    known to every serious developer. It all a matter of putting it into
    practise.

    >> I suspect that if I were to review the MFC code line by line, I could
    >> add in thousands of missing ``kludge'' and ``fixme'' comments.

    >
    > I know firsthand of kludges and fixmes in MFC code. But, I doubt that
    > these types of bugs are in the "thousands". My estimate would be that
    > they are in the "hundreds", if not the "tens".


    Your basic comparison is flawed. You are comparing an OS kernel with a
    GUI library. Maybe MFC might have only "hundreds" of kludges and
    FIXMEs, but when you consider Windows as a whole, we all know who wins,
    by a wide margin, on the bug count.

    > When you pay someone to do something, you can expect better results
    > compared to when you don't pay them. Microsoft pays people.


    It's not as simple as this. Bad code can be produced whether someone is
    payed or not. The best way to ensure that best possible code is
    produced is to enable competent and interested people to work on it. A
    disinterested developer is going to churn out broken code whether he is
    working on an OSS from home or in Microsoft. He is likely to be bested
    by an intelligent and motivated volunteer.
     
    santosh, Jan 23, 2008
    #19
  20. Billy Bong

    Kaz Kylheku Guest

    On Jan 22, 11:17 pm, Billy Bong <> wrote:
    > On Tue, 22 Jan 2008 10:36:11 -0800, Kaz Kylheku wrote:
    > > Before you can document something as a kludge or fixme item, you have to
    > > recognize that what you have written is in fact such a thing.

    >
    > Good point. What frustrates me is that a company such as Microsoft is
    > often privy to the types of details that can eliminate "kludges" and
    > "FIXMEs", whereas those such as Linux developers are not.


    Incomprehensible babbling. I think that what I said above is that just
    because the comments don't say anything about kludges doesn't mean
    there aren't any.

    > > I suspect that if I were to review the MFC code line by line, I could
    > > add in thousands of missing ``kludge'' and ``fixme'' comments.

    >
    > I know firsthand of kludges and fixmes in MFC code. But, I doubt that
    > these types of bugs are in the "thousands". My estimate would be that
    > they are in the "hundreds", if not the "tens".


    I could probably find ten for every one you find, because, you appear
    pitifully stupid.

    And surely MFC isn't four million lines? Don't you think it would be
    more meaningful to compare density: so many occurences of the
    interesting artifact per so many lines of code?

    A hundred artifacts in a hundred-thousand lines of code is the same
    density as a thousand artifacts in a million lines of code.

    You know. That division thing. The / button on your calculator.

    > When you pay someone to do
    > something, you can expect better results compared to when you don't pay
    > them.


    Wrong guess. Now go read up on the psychology. It is well documented
    that people produce their best work when they are internally motivated
    (doing something for its own sake).

    Of course, that is not incompatible with being compensated---as long
    as the compensation isn't the motivation.

    For instance, see the 1973 paper, "Undermining children's intrinsic
    interest with extrinsic rewards: A test of the overjustification
    hypothesis" by M Lepper, D Green & R Nisbett.

    > Microsoft pays people.


    A lot of the work in the Linux kernel was paid for by someone. I'm
    doing kernel development for a living, currently. Not just kernel
    development, but that's a big part of the job. I write code that goes
    into the kernel, or modify existing code. I have fun, and I get paid
    for it.

    > [1] A good question is ... do Linux Kernel developers in specific, or
    > open source developers in general, follow a documented software
    > development process? Or is it all ad hoc?


    They follow an incompletely documented development process. Which
    isn't the same thing ad-hoc. False dichotomy.

    Anyway, if I feed you any more, you won't fit under the bridge.
     
    Kaz Kylheku, Jan 23, 2008
    #20
    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. Don
    Replies:
    1
    Views:
    5,625
    Victor Bazarov
    Feb 8, 2004
  2. yogesh
    Replies:
    3
    Views:
    603
    Kenny McCormack
    Feb 12, 2006
  3. Billy Bong
    Replies:
    18
    Views:
    538
    santosh
    Jan 25, 2008
  4. Replies:
    3
    Views:
    182
  5. Lars Gierth
    Replies:
    6
    Views:
    238
    David Masover
    Mar 20, 2010
Loading...

Share This Page