What's the easiest and/or simplest part of Linux Kernel?

[郭é–]

Here is about C language, so I think people here might know something about Linux Kernel.

Recently I have a interest in Linux Kernel, but I don't think my C programming skill is able to handle it, I'm just going to read the code in Github.

So any of you have ever involved in the dev of Linux Kernel? I've been kernelnewbies.org, it's a great website.

 

[gdotone]

Here is about C language, so I think people here might know something about Linux Kernel.



Recently I have a interest in Linux Kernel, but I don't think my C programming skill is able to handle it, I'm just going to read the code in Github..



So any of you have ever involved in the dev of Linux Kernel? I've been kernelnewbies.org, it's a great website.

i would like to suggest you try reading Minix3.

from what i have seen of it, the code looks clean.
like, perhaps, what you would expect to see after acing your C class followed by that A you got in data structures. ;-)

Minix3.org

there is a video of the creator giving a talk on youtube.
i think he did a great job. (he's presentation)

there's a book too for Minix3.

whatever you do good luck with it.

 

[郭é–]

在 2013å¹´8月26日星期一UTC+8上åˆ10æ—¶23分14秒，[email protected]写é“：

i would like to suggest you try reading Minix3.



from what i have seen of it, the code looks clean.

like, perhaps, what you would expect to see after acing your C class followed by that A you got in data structures. ;-)



Minix3.org



there is a video of the creator giving a talk on youtube.

i think he did a great job. (he's presentation)



there's a book too for Minix3.



whatever you do good luck with it.

I did read minix3's code yesterday, I think the code there is neat and simple, not complicated like Linux Kernel.

So the data structures of a program or kernel is important?

 

[Stephen Sprunk]

So the data structures of a program or kernel is important?

"Show me your code and conceal your data structures, and I shall
continue to be mystified. Show me your data structures, and I won't
usually need your code; it'll be obvious."
--Eric S. Raymond, The Cathedral and the Bazaar

 

[Andrew Smallshaw]

Here is about C language, so I think people here might know something about Linux Kernel.

Recently I have a interest in Linux Kernel, but I don't think my C programming skill is able to handle it, I'm just going to read the code in Github.

So any of you have ever involved in the dev of Linux Kernel? I've been kernelnewbies.org, it's a great website.

A few points come to mind. First of all at the risk of triggering
some huge and ultimately pointless flame war the Linux kernel
probably isn't the best place to look in the first instance. I've
only limited experience of it but it huge and gets turned upside
down on a regular basis as entire subsystems come and go. I seem
to remember coming accross a statistic a while back to the effect
that different revisions of the 2.6 kernel differ by more lines of
code than are actually in any of the modern BSD kernels. Also the
nature of Linux development with at least 10x the number of developers
working on it than any of the BSDs make it quite inconsistent
internally.

There are any number of good books on kernel internals. If you
look at Linux make sure to cross-reference it against the specific
version under consideration and don't be surprised if things have
changed. If this is purely for academic interest and historical
versions could be considered (not a bad option since they tend to
be a lot simpler) Lions' Commentary on Unix 8th Edition by John
Lions and The Design and Implementation of the 4.{234}BSD Unix
Operating System by Leffler/McKusick/Karels/Quartermann are both
legendary. I did work through Leffler et al cover to cover a few
years back and while it's a little dry in places and makes no sense
at all with a source listing (easy enough to download) most of it
is easy enough reading and you do feel you've spent your time
productively at the end of it.

 

[Kenny McCormack]

legendary. I did work through Leffler et al cover to cover a few
years back and while it's a little dry in places and makes no sense
at all with a source listing (easy enough to download) most of it

ITYM, "without".

 

[郭é–]

在 2013å¹´8月27日星期二UTC+8上åˆ4æ—¶54分47秒，Andrew Smallshaw写é“：

A few points come to mind. First of all at the risk of triggering

some huge and ultimately pointless flame war the Linux kernel

probably isn't the best place to look in the first instance. I've

only limited experience of it but it huge and gets turned upside

down on a regular basis as entire subsystems come and go. I seem

to remember coming accross a statistic a while back to the effect

that different revisions of the 2.6 kernel differ by more lines of

code than are actually in any of the modern BSD kernels. Also the

nature of Linux development with at least 10x the number of developers

working on it than any of the BSDs make it quite inconsistent

internally.



There are any number of good books on kernel internals. If you

look at Linux make sure to cross-reference it against the specific

version under consideration and don't be surprised if things have

changed. If this is purely for academic interest and historical

versions could be considered (not a bad option since they tend to

be a lot simpler) Lions' Commentary on Unix 8th Edition by John

Lions and The Design and Implementation of the 4.{234}BSD Unix

Operating System by Leffler/McKusick/Karels/Quartermann are both

legendary. I did work through Leffler et al cover to cover a few

years back and while it's a little dry in places and makes no sense

at all with a source listing (easy enough to download) most of it

is easy enough reading and you do feel you've spent your time

productively at the end of it.



--

Andrew Smallshaw

(e-mail address removed)

Yes some months I read some parts of Linux Kernel on Github but had no mindon it. 2 days before, I read Minix3's code, I found it neat and simple, I don't mean it easy but simpler than Linux Kernel.

I may be purely for academic interests on *nix kernel code. And as you mentioned, Lions' Commentary on Unix, which I knew from Hackers & Painters, written by Paul Graham. I may try it out later.

 

[Tim Rentsch]

"Show me your code and conceal your data structures, and I shall
continue to be mystified. Show me your data structures, and I won't
usually need your code; it'll be obvious."
--Eric S. Raymond, The Cathedral and the Bazaar

This quote is actually from (or perhaps paraphrased from)
/The Mythical Man-Month/, by Fred Brooks.

(And /The Cathedral and the Bazaar/ gives an attribution
to that effect.)

 

[Jorgen Grahn]

This quote is actually from (or perhaps paraphrased from)
/The Mythical Man-Month/, by Fred Brooks.

Paraphrased. My copy of TMMM is at home, but googling seems to
indicate that Brooks wrote

Show me your flow charts and conceal your tables and I shall
continue to be mystified, show me your tables and I won't usually
need your flow charts; they'll be obvious.

which amounts to the same thing, except it's also an attack on flow
charts; Brooks found them useless.

There's also Rob Pike, in "Notes on C Programming":

Data dominates. If you've chosen the right data structures and
organized things well, the algorithms will almost always be
self-evident. Data structures, not algorithms, are central to
programming.

(And /The Cathedral and the Bazaar/ gives an attribution
to that effect.)

/Jorgen

 

[Jorgen Grahn]

A few points come to mind. First of all at the risk of triggering
some huge and ultimately pointless flame war the Linux kernel
probably isn't the best place to look in the first instance. I've
only limited experience of it but it huge and gets turned upside
down on a regular basis as entire subsystems come and go.

[BSD, Lions, Leffler/McKusick/Karels/Quartermann]

Another thing is, if you just want to *accomplish* something, doing it
yourself in the Unix kernel should be a last resort. Everything
becomes so much harder there: building, debugging, licensing,
portability ...

/Jorgen

 

[郭é–]

在 2013å¹´8月27日星期二UTC+8下åˆ3æ—¶50分41秒，Jorgen Grahn写é“：

A few points come to mind. First of all at the risk of triggering

some huge and ultimately pointless flame war the Linux kernel

probably isn't the best place to look in the first instance. I've

only limited experience of it but it huge and gets turned upside

down on a regular basis as entire subsystems come and go.

[BSD, Lions, Leffler/McKusick/Karels/Quartermann]



Another thing is, if you just want to *accomplish* something, doing it

yourself in the Unix kernel should be a last resort. Everything

becomes so much harder there: building, debugging, licensing,

portability ...



/Jorgen



--

// Jorgen Grahn <grahn@ Oo o. . .

\X/ snipabacken.se> O o .

I don't understand, you mean that coding in Linux/Unix is hard work?

 

[Jorgen Grahn]

??? 2013???8???27????????????UTC+8??????3???50???41??????Jorgen Grahn?????????

Please fix your newsreader.

I don't understand, you mean that coding in Linux/Unix is hard work?

No. I mean writing and maintaining Linux /kernel/ code is a lot harder
than doing it in user space.

(Of course some problems must obviously be solved by kernel
programming, but sometimes you have a choice and then you need to be
aware of the cost difference.)

/Jorgen

 

[Les Cargill]

Please fix your newsreader.



No. I mean writing and maintaining Linux /kernel/ code is a lot harder
than doing it in user space.

(Of course some problems must obviously be solved by kernel
programming, but sometimes you have a choice and then you need to be
aware of the cost difference.)

/Jorgen

There is a compromise; write a device driver. You don't even need a
"device" to drive; just twiddle bits in a 'C' statically allocated
patch of RAM.

The kernel proper has developed into a fairly arcane subculture. If
you want to write your own microkernel to sit on another
type O/S there are examples of that, too.

 

[James Kuyper]

Please fix your newsreader.

He's using Google Groups - I don't think that's an option. Are you sure
it's his newsreader that's at fault? According to mine, using the "View
Source" command, his message says:

Content-Type: text/plain; charset=UTF-8

and the line that bothers you so much is rendered as:

=E5=9C=A8 2013=E5=B9=B48=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CUTC+=
8=E4=B8=8B=E5=8D=883=E6=97=B650=E5=88=8641=E7=A7=92=EF=BC=8CJorgen Grahn=E5=
=86=99=E9=81=93=EF=BC=9A

In the main screen, it displays those UTF-8 characters on my screen as
Chinese characters corresponding the ? characters in your message. Those
characters translate literally as

I don't know the relevant internet standards very well - is his
newsreader inserting Chinese text into the message incorrectly, or is
your newsreader just failing to recognize it as such - probably because
you don't have any Chinese fonts installed? There's no reason why you
should have them installed if you don't read Chinese, but if that's the
reason, it's not a problem with his newsreader.

 

[Stephen Sprunk]

=E5=9C=A8
2013=E5=B9=B48=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CUTC+=
8=E4=B8=8B=E5=8D=883=E6=97=B650=E5=88=8641=E7=A7=92=EF=BC=8CJorgen
Grahn=E5= =86=99=E9=81=93=EF=BC=9A

In the main screen, it displays those UTF-8 characters on my screen
as Chinese characters corresponding the ? characters in your message.
Those characters translate literally as

I don't know the relevant internet standards very well - is his
newsreader inserting Chinese text into the message incorrectly, or
is your newsreader just failing to recognize it as such - probably
because you don't have any Chinese fonts installed?

It displays properly on my system, though that's no guarantee that it's
standards-compliant, of course. The MIME RFCs would be the relevant
group, if you want to look it up and be sure.

I've never noticed the combination of UTF-8 charset and quoted-printable
encoding before, but AFAIK that is valid. My newsreader is configured
for "8bit" encoding, i.e. raw UTF-8, but in theory an archaic news
server that isn't 8-bit clean could choke on that.

(NNTP assigns special meaning to certain control characters in the
message body, so strictly speaking no server is 8-bit clean, but by
design, UTF-8 text won't cause problems. Non-text attachments need
base64 encoding, though.)

There's no reason why you should have them installed if you don't
read Chinese, but if that's the reason, it's not a problem with his
newsreader.

My system came with pre-installed fonts for most world languages, and I
thought that was normal these days. Even if users can't read Chinese,
IMHO rendering Chinese text is better than replacement characters
because the latter implies something in the path is broken.

S

 

[Tim Rentsch]

Paraphrased. My copy of TMMM is at home, but googling seems to
indicate that Brooks wrote

Show me your flow charts and conceal your tables and I shall
continue to be mystified, show me your tables and I won't usually
need your flow charts; they'll be obvious.

which amounts to the same thing, except it's also an attack on flow
charts; Brooks found them useless.

I didn't take this comment as an attack on flowcharts. It's
true Brooks thought flowcharts were overrated, but I don't
think the quoted statement was meant to speak to that issue;
it could just as well have been "algorithms" or "pseudo-code"
for the point he was making.

There's also Rob Pike, in "Notes on C Programming":

Data dominates. If you've chosen the right data structures and
organized things well, the algorithms will almost always be
self-evident. Data structures, not algorithms, are central to
programming.

One of my favorites is also from Mythical Man-Month:

Representation is the essence of programming.

 

[Stephen Sprunk]

This quote is actually from (or perhaps paraphrased from)
/The Mythical Man-Month/, by Fred Brooks.

I was aware of the original quote and deliberately chose Raymond's
because the terminology is more modern; if I had quoted Brooks, I doubt
that éƒ­é– would have understood the relevance of flowcharts and tables
to his question.

(And /The Cathedral and the Bazaar/ gives an attribution
to that effect.)

.... and I attributed /The Cathedral and the Bazaar/, which is sufficient
to find the attribution to Brooks if anyone had cared.

S

 

[Tim Rentsch]

This quote is actually from (or perhaps paraphrased from)
/The Mythical Man-Month/, by Fred Brooks.

I was aware of the original quote and deliberately chose Raymond's
because the terminology is more modern; if I had quoted Brooks, I
doubt that [OP] would have understood the relevance of flowcharts
and tables to his question.

Brooks and MMM still deserve the credit. If you think the
quote needs paraphrasing for contemporary usage, paraphrase it
yourself. Attributing Eric Raymond is misleading.

... and I attributed /The Cathedral and the Bazaar/, which is
sufficient to find the attribution to Brooks if anyone had cared.

The problem with that idea is no one will think to look, and
people will come away with the wrong impression. I looked it
up only because I recognized the quote as being from Mythical
Man-Month.

 

[Jorgen Grahn]

On 28-Aug-13 13:25, James Kuyper wrote:

[snip lots]

My system came with pre-installed fonts for most world languages, and I
thought that was normal these days. Even if users can't read Chinese,
IMHO rendering Chinese text is better than replacement characters
because the latter implies something in the path is broken.

You both miss the most obvious: inserting Chinese text in a message
to an English newsgroup is a bug. And that was not even the reason
for my complaint; the double line spacing bug was.

/Jorgen

 

[Jorgen Grahn]

I didn't take this comment as an attack on flowcharts. It's
true Brooks thought flowcharts were overrated, but I don't
think the quoted statement was meant to speak to that issue;
it could just as well have been "algorithms" or "pseudo-code"
for the point he was making.

Yes, I agree code vs. data structures is the core of that quote.

(Or code versus external representation; I find that file formats and
protocols should be designed even before the C data structures for
work to flow smoothly.)

/Jorgen