[svlug] some peoples thoughts on Linux kernel code walk-thru
freepalestin at dslextreme.com
Mon Nov 12 11:27:44 PST 2007
Paul, et al,
Three of us who were hugely disappointed with the
first meeting of the Linux kernel code walk-through
have been conversing via email.
I'm sending on our thoughts, concerns, suggestions
to the list in the attempt to see if others share
our view and want to do something about it - have
the Linux kernel code walk-through actually be a
code walk-through - delve into the code.
Are there people still interested in an actual
code walk-through of the Linux kernel?
Would people want to:
- tell Paul we want to delve into code and want
to have the time and space used for that
purpose - if there are a lot of us
- meet maybe at the back of the meeting space
Tuesday night - if there are only a few of us
Does anyone have other suggestions?
Are any of the people who know the kernel still
interested? Would any of you be willing to lead
Tuesday's session - either the lot of us or the
few of us?
Akkana had suggested going over the init directory.
Can people look at that by Tuesday night?
Do other people share our concerns? Do other
people want to delve into the code?
Please speak up!
Julie might have sent this on to Paul:
[begin Julie email]
Hi again Paul,
Thanks so much for clarifying your plans. If you'll allow me to play
devil's advocate for just a bit longer, I still have some concerns I'd
like to air that center around expectations and engaging the audience.
You stated this:
> > We have a mix of beginner, intermediate, and
> > advanced experience in the group, and therefore
> > we can't please everyone at once. My intuition
> > on this is that diving in too quickly would
> > quickly overwhelm the beginners and probably
> > some of the intermediate folks as well. I'm not
> > looking to lose them; I'd rather bring them up
> > to speed first, and once we're _all_ more
> > familiar with the kernel, the real fun can
> > start.
To summarize, I think you're saying that you wish to serve the needs
of everyone, and therefore we need to start out at the beginner level
and work our way up.
[Before I plunge into my concerns, I want to ask upfront that you all
please don't misunderstand me. This post is not in any way an attack
on beginners and I'm very enthusiastic about everyone at all levels
learning as much about the kernel as possible, including myself...]
Paul, I would like to understand what your definition of "beginner"
is. Are you assuming that beginners have at least some moderate level
of programming skill and the ability to read C code or is that not the
case? What are the expectations that the beginners themselves have?
What do they hope to learn?
I'm wondering if we don't actually have 2 very distinct groups here:
programmers who want to read kernel code and understand it and
non-programmers who want to deeply understand how the kernel works but
are not so interested in the code. If that's the case, then I'm
failing to envision how you'll eventually bring the two groups
together because they appear not to have the same goals in mind. I'm
also concerned that too many of the people with the most knowledge and
experience will drop off quickly while you're working with the
"beginners" and it may be hard to get them interested again later on.
Finally, I keep putting "beginners" inside of quotes because I'm not
convinced that it's accurate to portray the non-programmers as
"beginners". It's likely that they're not beginners at all in their
interest in Linux. They're just not programmers and are looking at the
kernel from a different perspective.
Where I'm coming from on this is that I taught Fortran in a university
for two semesters to non-computer scientist Freshmen and Sophomores
who were required to take the class but had zero interest in learning
how to write code. My experience says that it's very difficult to
teach programming to people who don't want to learn it and don't have
I think this finally brings me to my point, and I'm sorry I was so
slow to get here: the point is that by trying to serve two very
distinct groups at the same time, you're not actually serving either
group very well and the knowledgeable and experienced kernel hackers
that we need could become bored and discouraged and drop off if
they're not given a motivation to stick around. The altruistic notion
that the experienced ones are the teachers is nice but may not be
enough motivation to keep the group together.
Have you considered if it's possible to engage both groups
simultaneously? Have one group diving into code while the other dives
into how the kernel works at a non-code level? Could we still keep
both groups involved with each other? (which seems essential) I don't
have a miracle solution to offer, but I imagine you've already
considered much of this and I'd like to find out what your thoughts
Thank you for your time,
[end Julie email]
Akkana's response to Julie:
[begin Akkana's response to Julie]
About your letter: I like pointing out the two groups of people.
I don't think this would have any effect on Paul. I'd like to think
posting it might cause other people to think, but it looks like SVLUG
people just aren't interested in discussing this.
> > Finally, I keep putting "beginners" inside of
> > quotes because I'm not convinced that it's
> > accurate to portray the non-programmers as
> > "beginners". It's likely that they're not
> > beginners at all in their interest in Linux.
> > They're just not programmers and are looking
> > at the kernel from a different perspective.
Actually, despite being a programmer I would be very interested in
a kernel course that wasn't code based. I would absolutely love a
course that went into fundamentals (from a user's perspective)
of tuning the kernel, trade-offs among various options like
schedulers and tick options, details of how systems boot, ways
of loading and unloading modules when problems happen, network
tuning ... the list of interesting non-code kernel topics goes
on and on. That would be just as interesting to me as a kernel
source class (and clearly they're two separate classes). And neither
one of them would be a "beginner" class.
A "beginner" class would be more like the one Val taught on
Linuxchix way back when: you'd start with what a kernel is and
what it does, move into how to configure and build your own kernel,
etc. That's a very valuable thing and I'm sure there's a big
audience for that one too, though I'm not very interested myself.
What Paul is doing is none of these three. [snip]
> > how to write code. My experience says that
> > it's very difficult to teach programming to
> > people who don't want to learn it and don't
> > have any interest.
Not to mention that kernel source really isn't the best vehicle for
learning beginning programming.
Anyway: I'd love to see this posted but I understand why you might
not want to bother; I'm losing hope that there are enough engaged
people in SVLUG to make anything happen.
I guess I'll go ahead and read init/ and some of those links that
Alvin and Srihari posted (some of them look pretty useful) and
think about whether it's worth going on Tuesday, just in case it
turns out that anyone wants to discuss it.
[end Akkana's response to Julie]
[begin Julie's response to Akkana]
Why are all of the other members so silent? That's
really puzzling me.
[end Julie's response to Akkana]
Please let us know - if you are interested in the
Linux kernel code walk-through sessions delving
into the code. Please let us know if you know the
kernel or know someone who knows the kernel that
would be willing to lead a session Tuesday, 13th
Thank you for your attention, consideration,
and perhaps your participation,
More information about the svlug