Building your own kernel LQ wiki working thread
 

I think a good start is probably to work out what kind of content and structure the new wiki article should have.

A rough draft structure could be something like this:
[*]intro/description

...
[*]preparing your system for building/prerequisites

-development tools
-development packages for kernel build
-etc

*do we have a separate section for building with LLVM/Clang?*

...
[*]configuring the kernel for building

-answering all questions from the kernel build system
-copying current kernel config over to new kernel

...
[*]steps to build new kernel

...
[*]installing the built kernel modules and kernel

...
[*]configuring the newly built kernel for use with your system

...
[*]problems/issues that might arise

*or should that be incorporated into a section above?*

...

===================

What do you think about that example structure of the new wiki article Hazel?

The biggest section would probably be configuration, because there are different ways to achieve this and also different starting points.

You can start with:
a) the existing configuration for your distro's kernel. But this is a stock configuration designed to run on any hardware and containing loads of drivers that you don't actually need. You will need to remove a lot of this if you don't want a long compilation time.
b) the output of make defconfig. This gives you a kernel with sensible defaults which you can then customise.
c) a kernel seed from a website. The best known are Pappy's seeds. You answer a few simple questions about your hardware and get a sensible default kernel configuration that you can adapt further.
d) The configuration file for the last kernel you built. This is ideal but obviously not available for your first build.

The actual configuration can be done with:
1) make config. You answer a long string of questions. If you make a mistake, you have to go back to the beginning. This is how kernels used to be built in the bad old days.
2) make menuconfig or make nconfig. This gives you a pseudo-graphical set of menus that you can navigate with your arrow and tab keys. If you make a mistake anywhere, you can go back and fix it. Disadvantages: it's ugly and you need to learn the navigation key bindings.
3) make xconfig or make gconfig. These give you a fully graphical menu which you can navigate with your mouse. Disadvantage: it needs a graphical desktop so you can't do it from the console.

Something should be said at this point about the wonderful kernel help system. Most online help only tells you what an option is for. Kernel help often tells you whether you need it or not. Novices should be encouraged to press H for any option they don't understand.

Also of course the fundamental rule: don't change anything unless you know what you are doing, or you'll get a kernel that can't boot.

Something should be said about building things as modules versus building them in. For example, if you don't want to use an initrd, you must build in your disk controllers and root filesystem driver.

Building with clang is a specialist topic, so if you include it, it should go in an appendix.

While I knew about the rest of what you said, I've never heard of a "kernel seed" before. What exactly is that?

The issues there are that, you need to provide extra arguments to make to get the kernel to actually build with LLVM/Clang. There is also a kernel config option I had to disable to get it to complete the build. So that's the reason I was asking about a separate section for building with LLVM/Clang, or we have a "problems/issues" section to deal with those issues, or do you think what you already suggested could deal with that (given the extra make arguments and disabling a option so it completes the build)?

I agree with the rest of what you said about the content for the configuration section though.

So I take it the very rough structure I done looks ok to you?

It's basically the same kind of thing that defconfig does. It provides a .config file with sensible defaults. The difference is that sites can include scripts that collect basic hardware parameters, so you get a default configuration that is a bit more tailored than the one the kernel team provide.
I think that will only confuse people. Anyone who hasn't built a kernel before will want to build it with the standard method. Anyone who is experienced in building kernels probably won't read the wiki. Actually I think a separate wiki page is the best way to deal with a clang build.
Yes, though I'm not sure what you mean by "configuring the kernel for use with your system". If you configured it properly before building it, no further configuration should be needed. You have to configure the bootloader of course but that's a different matter.

Perhaps in the intro section we can give at least a brief intro to the fact you can use purely the GNU toolchain, or you use LLVM/Clang to build the kernel - albeit having to use the GNU linker if you opt for the latter route?

Yes, the bootloader was one of the things I meant, since while the makefile did attempt to configure LILO, it didn't add any GRUB entry - I had to do that myself. I also had to build the initrd myself as well. So namely those things was what I was referring to regarding that section. But I suppose we might be able to include that info elsewhere though. To be clear, I think that info, along with the info about clang should be included in the same wiki page since we are talking about building the kernel and all of that is still relevant to the kernel. There's also the fact that once LLVM/Clang become more accepted with other distro's it's probably likely that we'll see more of them at least providing those options, and not just a "pure" GNU toolchain.

So we need a section called "Making your new kernel bootable". This will cover where you need to copy it to, whether or not you need to make an initrd (you should be able to avoid that in a hand-built kernel) and how to make lilo, elilo or grub see the kernel.

Yeah, that sounds like a far better title and idea than I come up with before. Agreed, if you're happy with that.

I was also thinking that in the "preparing your system for building/prerequisites" we could perhaps include something about the skills required to build the kernel (be that with just the GNU toolchain or using clang). So for example:

-basic command-line skills - preferably using development tools such as make, etc
-a basic understanding of what "building from source" means - preferably being comfortable compiling software (doesn't have to be any previous kernel building experience)
-basic troubleshooting skills

Because let's face it, a complete newbie who is terrified of using the command-line/terminal isn't likely to attempt to build a kernel in the first place. So it's going to really require somewhere between beginner and intermediate skills to be able to have the basic prerequisites required. So I think that's probably who we should aim the article at, and perhaps make that clear in the intro, that before attempting any of the steps to try and build the kernel, the reader should make sure they have at least the basic skills needed?

LFS does something like that in its introductory matter. See http://www.linuxfromscratch.org/lfs/...equisites.html. But remember, the kernel building environment is quite different from the standard autotools. To build an autotools package, you have to have some idea of what "configure" and "make" actually do. You don't really need that for the kernel; in fact having it won't particularly help you. And if you use a graphical configuration menu, you don't even need command line skills until you come to installing the thing.

But you would still need to issue the make command to build the kernel after you've configured it, and you would need to supply extra arguments to make if building with clang though.

In any case, it might be wise to just make the point that there is a certain level of skill involved, albeit not a particularly advanced level of skill per se, certainly you don't need to be a kernel developer to be able to build it and then install it.

I've created a stub page https://wiki.linuxquestions.org/wiki...n_Linux_kernel so that we can start adding actual text. btw where is everyone else?

Put me in the simply curious category. Eagerly waiting.

8bit

Looks good Hazel, you'll have to forgive me for thinking that you've done this before, yes? ;)

It might be a good idea if we focus on a section at a time in regards to content.

I think the intro section looks fairly complete and probably good enough, so in relation to the "Prerequisites for the build" section: while I think we should explicitly list the development packages for building the kernel itself like, "libelf" (and obviously the devel package for it) for one example, in regards to the development tools themselves; should we just state for example, "GNU toolchain" or gcc, ld, make, etc and actually list the individual development packages for the various tools themselves?

I think if you list too many tools, you'll frighten people off! I know that in Debian distros, you only need one metapackage called build-essential, Arch has something called base-devel, and I assume Red Hat distros also have the like. Slackware of course has everything you need if you do the full install. I'll see if I can cook up a paragraph that covers the ground.

I think mentioning the metapackage for the development tools rather than the tools themselves individually is a good idea, but there are a few devel packages apart from the tools themselves that you need, that may not be installed by default in all distros. So I do think that those devel packages should be explicitly mentioned in the prerequisites section, as this wiki page is supposed to be a complete guide, and I'd think that if someone is serious about building the kernel themselves, a full list of devel packages required (excluding the development tools themselves once again) should be included. Like the devel package for libssl as well as libelf, and while you did mention libelf, I think it would be better if we explicitly state the devel package of libelf (as well as libssl), not just the library itself.

But apart from that, I think the prerequisites section is about right from the look of it I just had, so again, nice work.

OK, I'm only writing drafts. Feel free to edit what you don't like. It's your project.