Missing 'make modules' command
- Only if you don't invoke the default
maketarget, or otherwise modified the makefile. See
make help. Maybe we could note that this article infers "vanilla" sources, per instructions. If you want to add a section for patching, and how this may modify the instructions, go for it. T1nk3r3r (talk) 06:44, 25 February 2014 (UTC)
Missing 'make bzImage' command
- Not if you follow instructions to the letter. See previous reply. T1nk3r3r (talk) 06:46, 25 February 2014 (UTC)
Keeping this article
Keeping the traditional method would be beneficial, as a) not being distro-specific it can be applied to any Linux distro, and b) It's another option and another string in a given user's bow. Carlduff (talk) 17:09, 12 March 2016 (UTC)
- I also agree that it adds basic Linux know-how which many users will value, even if they are just reading it and use ABS anyway. Related: Merging content with Kernels/Arch Build System will make maintenance of both more difficult, if one really wants to cover (some) extra points from the "traditional" method. Simpler to keep both in that respect as well. It might be useful to move this article to Kernels/Traditional or (my preference) Kernels/Traditional compilation to get rid of its second-level subpage, i.e. I vote to change the merge to a move template.
- As another optional idea to distinguish the two articles on compilation more: it may be very interesting for readers, if Kernels/Compilation/Traditional#Make initial RAM disk would be transformed into the "traditional" kernel method. I.e. don't use mkinitcpio but show how to create an initrd according to kernel doc.
- --Indigo (talk) 10:01, 13 March 2016 (UTC)
- Sounds good to me. The proposed new structure also makes sense. This article also has a lot of potential for expansion, e.g. applying patches, AUFS, and perhaps at least an overview of key modules/configs for kernels, etc. If someone doesn't add this content first, I can do so after I've learned a bit more. I'll certainly look at the alternative to mkinitcpio. Carlduff (talk) 11:18, 13 March 2016 (UTC)
- Good ideas. I like an example for applying a patch most from them. Regarding AUFS, there is a lot of effort involved; seems better for users who need/want it to contribute to Kernel modules. Configs: similar thought. I would think the "traditional" way are preferably the menu-driven options the Linux kernel offers. This also because the more "Arch foreign" ready-made configs are mentioned in this article, the more difficult it all gets. The Arch default config is very very well tested against the repo packages (dependencies etc). I'd say if a user wants a special patchset config, we have Kernels#AUR packages for starters (one could suggest recycling configs of the existing packages in Arch universe - much less painful than a full "traditional diy"). --Indigo (talk) 14:55, 22 March 2016 (UTC) AUR. Regarding an overview of modules/configs, well .. modules should be same as the official kernels for starters; any info that might be missing may be better suited in the regular articles, e.g.