Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Linux Kernel Source

Reply
Thread Tools

Linux Kernel Source

 
 
Bart C
Guest
Posts: n/a
 
      01-23-2008
Kaz Kylheku wrote:
> On Jan 22, 6:59 pm, "Bart C" <(E-Mail Removed)> 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.


So I was right to question the size of code needed to run an OS. (And I
thought drivers and things were outside the kernel.) That's reassuring to
know for some reason.

--
Bart


 
Reply With Quote
 
 
 
 
joe4702
Guest
Posts: n/a
 
      01-23-2008
On Jan 21, 10:19*pm, Billy Bong <(E-Mail Removed)> 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.
>


Linux source is like most any large body of software developed by many
people - some of it is beautiful, clean, modular and maintainable, and
much of it is garbage spaghetti code that looks like a Programming 101
first homework assignment.

 
Reply With Quote
 
 
 
 
Syren Baran
Guest
Posts: n/a
 
      01-23-2008
Billy Bong schrieb:

> 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".

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

Clearly you have never seen commercial software development. Often
enough time frames get set by people with absolutely NO knowledge of coding.
The coding skill does not magicly increase or decrease depending on
wether you get paid or not.
When i do freelance work i just get the some job done. Anything else
would be a waste of time and thus money for the contractor.
When working on my own open source projects i have no deadlines, try new
tricks and can add features that just wouldnt be feasible to implement
in a paid project. You know, often enough open source developers
consider their projects to be more like their babies.
> Microsoft pays people.

So does Red Hat, Novell, Canonical etc...
Others get paid cause their company has a viable interrest in Linux,
such as IBM, Intel, AMD etc...
To my knowledge all big open source projects also have paid developers.
Its not like all open source/free software developers are a bunch of
holy preaching hippies.
>
> Best regards

 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-23-2008
"Billy Bong" <(E-Mail Removed)> wrote in message
newsVflj.108$(E-Mail Removed)...
> 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.


The Linux kernel is an ugly mess in places. It's a good example of
real-world code with lots of contributors, but I wouldn't hold it up as a
model of how to do things right. As with most things in life, it's only
good enough to get the job done.

> 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.


Who said they were bugs? The term "kludge" is usually applied something
that works but inelegantly; the comment is mainly requesting someone else to
find a more elegant solution -- if there is one. Sometimes, there just
isn't.

"FIXME" is more likely to be a true bug, but not necessarily. It might be
that the code is known to break under circumstances that, as far as anyone
knows, never occur. If it actually caused problems, someone would track the
problem down and fix it.

> 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)


That does not prove the nonexistence of bugs or even kludges -- it just
means that Microsoft's marketing department has removed things from the
comments that make them look bad. You think there aren't any bugs in MFC?
Do you think it's better to admit the problems, in hopes someone will fix
them, or pretend they don't exist?

I'll also note, as others have, that comparing an OS kernel to a GUI library
is inappropriate. I'd bet the Vista kernel has _at least_ the same rate and
types of comments, but you can't see that because it's closed source. If
you want to compare something to MFC, try Qt or GNOME.

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


Well, it's better than not putting the comments on that same code. Better,
of course, would be improving the code so they no longer apply, but that
ignores several realities in any human endeavor.

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


If you think people, even "professionals", always do everything perfectly,
you're in for a rude awakening one day. I'd rather have people that
recognize and admit when something's not perfect than ones who can't/won't.

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


Why not?

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


Absolutely nothing useful that couldn't also be said about every other large
software project, both open and closed source, that I've seen.

(TeX, I believe, is claimed to have zero bugs. I haven't read the source,
though.)

> 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.


I'm quite sure Linus is aware of those comments and has written many of them
himself. He's human just like the rest of us.

> 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.


Then you misunderstand the "evidence" you've collected.

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

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      01-24-2008
santosh wrote:
> Billy Bong wrote:
>

.... snip ...
>
>> 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.


No. When source code is hidden, you don't have the opportunity to
pay or not to pay for improvements. You have to accept the
product, and can only swear at the mistakes.

To be accurate, you have to compare systems released under the same
open-source licenses.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Chris Hills
Guest
Posts: n/a
 
      01-24-2008
In article <(E-Mail Removed)>, CBFalconer <(E-Mail Removed)>
writes
>santosh wrote:
>> Billy Bong wrote:
>>

>... snip ...
>>
>>> 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.

>
>No. When source code is hidden, you don't have the opportunity to
>pay or not to pay for improvements. You have to accept the
>product, and can only swear at the mistakes.
>
>To be accurate, you have to compare systems released under the same
>open-source licenses.


CRAP. I can supply a LOT of professional course code that is not FOSS ,
GPL etc. Many commercial systems come with source code.... (that
includes Linux which is in effect a commercial system now)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ http://www.velocityreviews.com/forums/(E-Mail Removed) www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-24-2008
Chris Hills wrote:
> In article <(E-Mail Removed)>, CBFalconer <(E-Mail Removed)>
> writes
>> santosh wrote:
>>> Billy Bong wrote:
>>>

>> ... snip ...
>>>
>>>> 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.

>>
>> No. When source code is hidden, you don't have the opportunity to
>> pay or not to pay for improvements. You have to accept the
>> product, and can only swear at the mistakes.
>>
>> To be accurate, you have to compare systems released under the same
>> open-source licenses.

>
> CRAP. I can supply a LOT of professional course code that is not FOSS ,
> GPL etc. Many commercial systems come with source code.... (that
> includes Linux which is in effect a commercial system now)


Good point. Other commercial and non-commercial open source operating
systems also use different licenses.

--
Ian Collins.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      01-24-2008
CBFalconer wrote:

> santosh wrote:
>> Billy Bong wrote:
>>

> ... snip ...
>>
>>> 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.

>
> No. When source code is hidden, you don't have the opportunity to
> pay or not to pay for improvements. You have to accept the
> product, and can only swear at the mistakes.


Er, most closed source software has mechanisms through which you can
complain about problems. If everthing else fails, you can always
actively stop buying, or using, the product in question.

> To be accurate, you have to compare systems released under the same
> open-source licenses.


Yes. Many respondents have already pointed that out to the OP.

My point is that people who have a natural aptitude for what they are
doing are likely to produce a better job than others. Money, or fame,
or whatever is no substitute for interest, IMO.

Anyway it's beyond doubt now that "Billy Bong" /is/ a troll, so this
discussion (or any other discussion with him) is fruitless.

 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      01-24-2008
[snips]

On Tue, 22 Jan 2008 06:19:15 +0000, Billy Bong wrote:

> 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?


In any large-scale development project, there will typically be boatloads
of things which need fixing or are kludges. This is the way of the
world. Nor is this necessarily a terrible thing.

One piece of code I wrote many moons back involved about six lines of
code, which, when examined, should have had no actual effect whatsoever.
The fact they did was due to an immensely obscure bug in the firmware of
a modem the code was controlling. While the mechanism I came up with did
work, I was quite convinced there was a better way - if we had more
information on the modem. Hence, it got a KLUDGE tag - but it also made
it to the release version. Why not? After all, it worked, it was
effective, it was just ugly.

Some of those kludges may stick around a hell of a long time, too, for
the simple reason that while they may be ugly, they work, and other
things are more important.

The same might be true with a FIXME as well. Consider, oh, a driver. To
get best performance, you might want to set the device into a particular
operational mode - but not all devices might like that. Any which are
identified as "can't do that" might get blacklisted, set to run in a less
than optimal mode.

This is probably acceptable insofar as the system _works_. That said, it
would be better to figure out what other systemic changes need to be made
to get the device running at peak, but this may involve significant
changes to several other important pieces of code, something not to be
done casually.

Such a case would definitely warrant a FIXME, IMO, as it means you're not
operating as you should be - it's not simply ugly, it is actually
defective - but until you figure out a workaround and patch all the
affected areas, it at least works.

So what should one do in such a case? Say no, sorry, we won't support
that device at all? Not good. How about holding off release until the
device is fully supported? Possibly an option, but if the hardware
vendor isn't helpful, it could mean a potential delay of years or more
before release.

The best answer seems to be to bite the bullet, release it as it is -
optimal on most devices, suboptimal on others - but note, in the code,
that this really needs to be fixed.

Ain't nothing wrong with that. FIXME and KLUDGE and the rest are only
worrisome if they involve something where there's a really fundamental
failure or there is a comparatively trivial fix - but this is not,
generally, the case in code such as the Linux kernel.

 
Reply With Quote
 
Chris Hills
Guest
Posts: n/a
 
      01-24-2008
In article <(E-Mail Removed)>, Ian Collins
<(E-Mail Removed)> writes
>Chris Hills wrote:
>> In article <(E-Mail Removed)>, CBFalconer <(E-Mail Removed)>
>> writes
>>> santosh wrote:
>>>> Billy Bong wrote:
>>>>
>>> ... snip ...
>>>>
>>>>> 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.
>>>
>>> No. When source code is hidden, you don't have the opportunity to
>>> pay or not to pay for improvements. You have to accept the
>>> product, and can only swear at the mistakes.
>>>
>>> To be accurate, you have to compare systems released under the same
>>> open-source licenses.

>>
>> CRAP. I can supply a LOT of professional course code that is not FOSS ,
>> GPL etc. Many commercial systems come with source code.... (that
>> includes Linux which is in effect a commercial system now)

>
>Good point. Other commercial and non-commercial open source operating
>systems also use different licenses.


In fact ALL the commercial software I supply RTOS, stacks, file systems
etc comes in source code form.

Fortunately they don't have the highly restrictive GPL license.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ (E-Mail Removed) www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel#autoload ignores custom monkey patched Kernel#require Lars Gierth Ruby 6 03-20-2010 10:35 PM
Linux Kernel Source--Unquestionably Undefined Behavior Billy Bong C Programming 18 01-25-2008 06:20 AM
Why "Kernel.puts" and not "Kernel.put"? shadytrees@gmail.com Ruby 3 04-08-2006 01:42 PM
kernel hangs after "UNCOMPRESSING KERNEL OK BOOTING KERNEL" yogesh C Programming 3 02-12-2006 11:19 AM
casting question in kernel source code rahul8143@gmail.com C Programming 1 04-17-2005 02:23 PM



Advertisments