
Ideas for getting started in the Linux kernel - ashitlerferad
http://www.labbott.name/blog/2016/08/15/ideas-for-getting-started-in-the-linux-kernel
======
tayo42
I feel like this underestimates how hard it is to get started. I've started
playing around with the kernel and making small modifications. It's not
straight forward. For me just getting it complied in a vm was an ordeal. Most
books are pretty old and if you go google for what ever you want you end up
with a lot of very dense resources. Then you need to figure out if that
article you found actually applied to whatever current kernel your using and
what's changed since then. Ive been doing like hours of reading for a few line
change here and then.

And somewhat off topic. I think it will be interesting to see what happens to
linux in the long term. Are that many new/young programers getting into kernel
development? Id imagine there's not to many people getting into programing now
that are writing c or working on the kernel. Who is going to replace the
kernel developers of today? Or am I just totally off?

~~~
zbuf
> For me just getting it complied in a vm was an ordeal

You're right, the process of building and _installing_ a custom kernel is much
harder than it used to be 10-15 years ago.

And I believe this is a problem that impacts a certain kind of contribution.
Because even for the most experienced and competent of programmers, the bar
for entry is too high.

The distributions are partly to blame here. The complexity of initrd setups
have meant that testing even a small or single line change is an ordeal. The
wrapping in package managers like RPM makes incremental builds of a kernel
impossible.

My personal setup is based on Slackware without an initd; a kernel build
resembles a 'make; make install' like it has been for the past 15+ years. I've
been unable to achieve anything similar in reasonable time on a CentOS system.

~~~
fit2rule
I dunno, I've been a Linux kernel guy since Linus posted to the minix-list,
and I have to say that things seem easier than ever. I mean, pick your distro,
figure out how it boots the kernel, use it to build a new kernel, boot it.
Repeat, ad infinitum.

The problem seems to be a rather hefty "NIMBY" factor, imho. If you want to
get into the kernel these days, you have to realize: its a done thing. Nobody
cares if you're a rockstar.

Learn the tooling and methodology, or gtfo...

------
a3_nm
As for books about the Linux kernel, I'd recommend
[https://github.com/0xAX/linux-insides](https://github.com/0xAX/linux-insides)
(which, oddly, didn't seem to be linked)

~~~
bgilroy26
I would recommend Robert Love's Quora answers as an additional low barrier
starting point

[http://qr.ae/TNK9UD](http://qr.ae/TNK9UD)

------
d33
One thing I hadn't seen said here yet:

Do we really need that many kernel developers? I'm getting the impression that
a lot of dev power is wasted just to maintain drivers that should be produced
by hardware vendors. The vendors won't do that because there's no stable ABI,
which means that people need to reinvent the wheel.

One could argue that it adds better quality control and all in all, we get
open source implementations of what would instead be proprietary drivers, but
in the end, complex drivers aren't good enough anyway (see Nouveau). As for
quality control... many say that Linus's view on security is questionable. For
one, I don't like the concept of pluggable /stackable security mechanisms
(selinux, apparmor, etc) where one consistent system would do. It just feels
cluttered.

~~~
the_why_of_y
> The vendors won't do that because there's no stable ABI, which means that
> people need to reinvent the wheel.

This is utter nonsense; I suggest you have a good look at a "git log" of some
driver files source files in linux.git, here's just an example:

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/amd)

Edit: In particular, there not being a stable ABI _prevents_ vendors from re-
inventing various wheels because they can just argue for and submit
enhancements and changes to various core kernel subsystems so that they better
match the requirements of their hardware / driver, instead of putting extra
code into every driver like they have to do on other systems where they have
to live with whatever ABI was declared stable by the OS vendor a decade ago.

~~~
wolfgke
Concerning the argument:

> In particular, there not being a stable ABI _prevents_ vendors from re-
> inventing various wheels

Here it depends on what you consider as "wheel": If a hardware vendor has to
write two versions of the driver (one using the existing wheel in the Linux
kernel and one with an own wheel on other OSes (Windows, OS X)) this clearly
leads to reinventing various wheels. On the other hand inside the Linux kernel
there is only one subsystem wheel that is used by all drivers using it instead
of reinventing this wheel for all drivers of some fixed type.

~~~
the_why_of_y
Yes, it always depends...

NVIDIA's huge blob is probably a case where they re-invented lots of wheels in
order to share the same driver between different OSes. For something as
complicated as a modern GPU driver, this could well make sense from an
engineering point of view (legal objections notwithstanding).

On the other hand, 10 years ago there were various out-of-tree Linux WLAN
drivers, and each of them contained a full independently developed 802.11
stack, perhaps one shared across drivers for multiple OSes by the same vendor
- surely having this much duplication of generic infrastructure that dwarfs
the actual model-specific part of the drivers is quite pointless.

IMHO only GPUs have an inherent complexity that is high enough that one could
think about alternatives to just using the shared infrastructure that's
already in Linux. But even in this area you see companies like AMD moving
towards a Linux-specific kernel driver approach with their new "amdgpu"
driver.

------
voltagex_
I second the recommentation for the Eudyptula Challenge although the "rule"
about not asking/posting for help is probably why I have been on Challenge 5
for about a year.

~~~
rrmm
Lots of good suggestions on the list. I would add a few (maybe advanced ones)
that I don't think I saw:

* write a device driver for a real or virtual device; hook into the various kernel virtual filesystems that allow userspace interaction.

* write a small network stack (for example a raw protocol on top of ethernet).

* add a scheduling algorithm or mess with an existing one; analyze its performance impact.

Lots of new-to-me tools in that list were interesting. Back in my day, we had
to use a serial port console, and if we were fancy we would set it up so that
you could remotely cycle the computer's power when it hung up (uphill both
ways in the snow).

~~~
voltagex_
Everything old is new again - serial port debugging has been invaluable for me
when I was messing with the Dreamplug, and then the Raspberry Pi.

I think I'd add using a serial-based terminal to that list too. Embedded
hardware can be infuriating, but fun.

------
amboar
An approach that's worked well for me was to first hack qemu to add some new
(emulated) hardware, then write the kernel drivers using qemu to test
(followed by running on the hardware). That does leave you with two problems
instead of one, but is quite flexible when you are trying to track down bugs
and can increase your hack/compile/test velocity.

~~~
andrey_utkin
Which kinds of drivers you have developed this way? I guess it's not possible
to test driver code unless probe() succeeds, which requires actual hardware to
be in place. You say you had "emulated" hardware - what this means, exactly?

Thanks in advance for explanations.

~~~
amboar
> You say you had "emulated" hardware - what this means, exactly?

Software pretending it is hardware, for example QEMU:
[http://wiki.qemu.org/Main_Page](http://wiki.qemu.org/Main_Page)

> Which kinds of drivers you have developed this way?

As an example, this approach helped me develop a pin-controller driver[1]. I
first added a new bare-bones SoC and machine to QEMU[2] to give me enough of a
environment to start adding other models, such as the SoC's System Control
Unit[3], which in-turn contains the registers the pin-controller driver pokes
at. Using QEMU I could control the initial values in the registers and
exercise the pin controller driver's implementation.

> I guess it's not possible to test driver code unless probe() succeeds, which
> requires actual hardware to be in place.

Not entirely - if you are writing the driver you can always pretend it
succeeds! Ideally you want to get some gratification as soon as possible - if
that means making some assumptions and nasty hacks, that's fine (as long as it
won't smoke something!) Then start iterating to iron them out. At least,
that's the kind of approach that works for me.

[1] [https://lkml.org/lkml/2016/7/20/69](https://lkml.org/lkml/2016/7/20/69)

[2] [https://lists.nongnu.org/archive/html/qemu-
devel/2016-03/msg...](https://lists.nongnu.org/archive/html/qemu-
devel/2016-03/msg03667.html)

[3] [https://lists.gnu.org/archive/html/qemu-
devel/2016-06/msg070...](https://lists.gnu.org/archive/html/qemu-
devel/2016-06/msg07042.html)

------
known
TODO [http://www.google.com/search?q=todo&sitesearch=lxr.free-
elec...](http://www.google.com/search?q=todo&sitesearch=lxr.free-
electrons.com/source&gws_rd=cr&ei=KdSyV7KdDYekjwPl6K6IBQ)

------
andrey_utkin
It's not that getting started with Linux kernel is inherently hard. It's just
what a lot of people want to have as "getting started with Linux kernel" (see
motivation part of this article) is hard, but that's not about Linux kernel
itself. Some people get this wrong and start thinking that Linux kernel or its
community itself is the problem (Maybe kerneldevs and Linus himself are
aggressive picky bullies unfriendly to newcomers? Maybe you should ditch C and
rewrite kernel in better language? Maybe Linux development process is wrong
and they should change it? Maybe Linux maintenance organization structure is
bad? Maybe ...)

There is also common frustration about friction at getting your patch
accepted. But I believe in most cases maintainers are right and there are some
issues to fix in any patch, so author has something to do on it more.
Maintainers have reasons to care - they are who improve subsystems API and
modify ALL drivers in the tree, so they'd better have all drivers as perfect
as possible.

> Are you interested in knowing how operating systems work in general? Do you
> want to know how parts of Linux specifically work?

An undertaking which a lot of novices take for reasons unknown to me. I was
always fine without this.

I follow #kernelnewbies IRC channel (good source of help, BTW) and see which
questions are being asked. Surprisingly many novices decide to start with
understanding kernel codebase in its entirety. Such people should just
understand that their aim is inherently hard. Any large codebase has non-
obvious and/or complex things, a lot of indirection, etc.

    
    
      - I don't understand how this internal kernal mechanism works, please explain!
      - It's complicated for outright explanation. If in trouble, read the code. And just trust that it works. What are you trying to achieve?
      - I'm just studying how kernel works.
    
    

> Is your hardware broken?

Regarding device drivers, a lot of opportunities are missing because most of
devices don't have datasheets good enough to allow third-side developer to
make a driver. So you just have no way to know how to give commands to your
piece of hardware. It's a shame, but this shame is not on Linux, it is on
manufacturers. Even if you are stubborn enough to get in touch with
manufacturer, you may end up with something like

    
    
      - The development team was dismissed N years ago and people don't work here anymore, so nobody to ask, but if you want NNNNNNN pieces order, we can make new research team for this.
    

You can reverse-engineer something, of course, but as somebody having
experience of reverse-engineering heavily obfuscated _sources_ of Linux v2.6
driver, I'd say the amount of wasted time and frustrations is tremendous.

> Do you just want to make an Open Source contribution? Do you want a high
> five?

Oh yeah, kernel is a fantastically reputable place to have open source
contribution. Your bros will respect you as coolest guy ever, your
girlfriend/boyfriend will praise you as superhero, hiring managers will want
you. Because they don't know that contributing to kernel is not THAT hard.

~~~
vonmoltke
>> Are you interested in knowing how operating systems work in general? Do you
want to know how parts of Linux specifically work?

> An undertaking which a lot of novices take for reasons unknown to me. I was
> always fine without this.

I'm probably atypical, but my motivation for wanting to get involved is that
many of the jobs I really want demand Linux kernel development experience. I
have good systems-level experience at all levels _except_ the kernel, and I
want to fill that hole.

~~~
andrey_utkin
Good luck, but in my opinion there's very little room for improvements in
__core __code which could be found and undertaken by newcomer. It is more
realistic to get first kernel-related experience by working on drivers - they
tend to be much less perfect. For drivers work, all you need is usage of
provided API and communication with maintainers and mentors. That 's my point.

------
copser
Is there any kernel that was written and maintained using python language?

I assume that the C and C++ is a must to learn to this, but is it or we can
work with karnel using python.

~~~
jm547ster
Beside performance and safety concerns even a kernel written in C needs to to
jump down to native assembly for certain parts, so I don't believe this
would/could have been done

