# Kernel build utilities



## zirias@ (Mar 27, 2016)

That's the spirit: Look around what others do, identify the things that are better, and take the inspiration  Not directly related, but what I really like looking at Linux is the kernel configuration system (including a curses-based tool), allowing you to configure a minimal set of kernel modules with automatic dependency checking and integrated help. Wouldn't THAT be nice on FreeBSD, too?


----------



## ANOKNUSA (Mar 28, 2016)

The menu-driven configuration exists because the Linux kernel is a giant mess of incomprehensible options and obsolete historical baggage that no one could work through in plain text. And most of the help is not at all helpful.

The simplicity of the FreeBSD kernel configuration compared to that of Linux is something I find pretty amazing. Think about it: is it really easier to build a minimal kernel by digging through a dozen nested menus and hitting the spacebar 100 times, than by just opening your editor of choice and deleting some lines?


----------



## zirias@ (Mar 28, 2016)

ANOKNUSA said:


> The menu-driven configuration exists because the Linux kernel is a giant mess of incomprehensible options and obsolete historical baggage that no one could work through in plain text. And most of the help is not at all helpful.


Although the premise is partially true -- configuring Linux using a text editor WOULD be a major PITA -- the conclusion isn't. Trying to build a FreeBSD kernel with ONLY the modules you are interested in requires YOU to track down all dependencies and write a working WITHOUT_MODULES or MODULES_OVERRIDE line. If you assess the situation without any prejudice about your preferred OS, you should see how this could be improved.

The help not being helpful, in my experience, yes that happens. It's NOT true for "most" of the options, but it happens and this is a problem. A problem to be solved 



ANOKNUSA said:


> The simplicity of the FreeBSD kernel configuration compared to that of Linux is something I find pretty amazing. Think about it: is it really easier to build a minimal kernel by digging through a dozen nested menus and hitting the spacebar 100 times, than by just opening your editor of choice and deleting some lines?


Well, no, although I love vim ... see above


----------



## wblock@ (Mar 28, 2016)

Zirias said:


> Trying to build a FreeBSD kernel with ONLY the modules you are interested in requires YOU to track down all dependencies and write a working WITHOUT_MODULES or MODULES_OVERRIDE line.


No, just include GENERIC and use nodevice entries in the kernel config.  See Simplifying FreeBSD Kernel Config Files for an example.


----------



## sidetone (Mar 28, 2016)

If I put

```
nodevice        eisa
```
 in my custom KERNCONF, will it act as removing all eisa and isa listings without them complaining and failing to compile the kernel?


----------



## zirias@ (Mar 28, 2016)

Oh wow ... that's what I meant about "the spirit" ... A menu-driven tool would just be *more user-friendly*, that's all  It is nothing that's TOO important, in fact, I'm quite happy with FreeBSD right now ... it's just an idea what to improve getting SOME inspiration from Linux.



wblock@ said:


> No, just include GENERIC and use nodevice entries in the kernel config.  See Simplifying FreeBSD Kernel Config Files for an example.


And NO, this will just prevent these drivers (or more general "parts") from being built INTO the kernel. It will NOT prevent them from being built *at all*.


----------



## wblock@ (Mar 28, 2016)

But that was what you said: 





> Trying to build a FreeBSD kernel with ONLY the modules you are interested in


----------



## sidetone (Mar 28, 2016)

Zirias said:


> And NO, this will just prevent these drivers (or more general "parts") from being built INTO the kernel. It will NOT prevent them from being built *at all*.



That doesn't answer my question, because if that's true, it will fail to build which negates that answer.

I found the examples for hardware, it's NOTES, under /usr/src/sys/conf/, /usr/src/sys/*/conf/, and the KERNCONF files themselves, which add "no" in front of it. Still I need to examine this, or get more examples on how to undo whole categories of hardware drivers that I don't want, aside from uncommenting them all individually as I normally do, if that's the case. I'll continue using parts of that suggestion, but if it doesn't undo categories of hardware, I'll continue using less negating options in KERNCONF's.

(If the kernel configuration comments are in the wrong thread, can someone move it to the right thread.)


----------



## zirias@ (Mar 28, 2016)

wblock@ said:


> But that was what you said:


The *modules* that is (which is different from what is built *into* the kernel). Why do you get so defensive? This thread started about some linux-centered mention of the FreeBSD documentation as being great and something to take example. I suggested something the other way around. Is this really bad? It's just about ideas how to further improve FreeBSD


----------



## zirias@ (Mar 28, 2016)

sidetone said:


> (If the kernel configuration comments are in the wrong thread, can someone move it to the right thread.)



I really didn't mean to "hijack" this thread, I'm very sorry. I guess my last reply explained my motivation to post here, but for any "spinoff" regarding FreeBSD kernel configuration, yes, some other thread might be needed


----------



## sidetone (Mar 28, 2016)

That's not the detail I was referring to. Well, if it's hijacked, several of us did that. I just know that wblock@ likes keeping threads organized by subject, and I don't know where the best relating discussion is of where he posted his writing about custom KERNCONF files. He's free to move it, if he thinks it doesn't belong here.

Can I suggest splitting the thread, because I can't find a place for it. The threads are either too old, or are about a specific release, one of which is not supported yet.


----------



## wblock@ (Mar 28, 2016)

Zirias said:


> The *modules* that is (which is different from what is built *into* the kernel). Why do you get so defensive?


It's not defensive at all. You asked a question about a building a kernel with only particular modules and then only later specified that they would not only not be built into the kernel, but not be built at all.

My experience is that messing with src.conf is usually only worth it when building for something really, really small, typically an embedded system.

As far as some sort of utility to help with configuring either a kernel config file or src.conf, I'd rather have some sort of dependency checker that would detect a misconfigured file rather than a GUI.


----------



## zirias@ (Mar 29, 2016)

wblock@ said:


> As far as some sort of utility to help with configuring either a kernel config file or src.conf, I'd rather have some sort of dependency checker that would detect a misconfigured file rather than a GUI.


That might be an equally good idea, still something that doesn't exist right now, as far as I know?


----------



## tomxor (Mar 29, 2016)

So are dependencies dealt with by using the nodevice entries that wblock@ mentioned? The Simplifying FreeBSD Kernel Config Files page doesn't mention this explicitly.

Existing or not it's an interesting idea, although I think a "UI" is a separate question and feature. ANOKNUSA makes a good point about the necessity of this feature only for complex configurations. While needlessly adding features is bad, I feel that in general dependency resolution brings more utility than simply "managing complexity", (so long as it doesn't add too much).

NOTE: I'm a kernel newbie who's only just started playing with building the FreeBSD kernel (a very smooth and pleasant experience by the way) so give my opinions a very low weight


----------



## wblock@ (Mar 29, 2016)

tomxor said:


> So are dependencies dealt with by using the nodevice entries that wblock@ mentioned?


No, the only way you will know is failed kernel builds and experience, like removing SCSI stuff and finding USB storage doesn't compile any more.


----------



## zirias@ (Mar 29, 2016)

wblock@ said:


> No, the only way you will know is failed kernel builds and experience, like removing SCSI stuff and finding USB storage doesn't compile any more.


And thinking about that, isn't it a good example for the benefit of a config-system like the Linux kconf? Actually _having_ to use it could be seen as a drawback, so yes, a good start would be just a tool to check a config file. But if you'd find a way to have your kernel configuration _optionally_ menu-driven, I think this would be great stuff  I personally like the `make oldconfig` tool of Linux, too.


----------



## SirDice (Mar 30, 2016)

If I remember correctly the old FreeBSD 3.x kernels had an option to configure the kernel at boot. You could enable and disable modules. Somewhere along 4.0 this got removed. Would bringing that back help?


----------



## zirias@ (Mar 30, 2016)

SirDice said:


> If I remember correctly the old FreeBSD 3.x kernels had an option to configure the kernel at boot. You could enable and disable modules. Somewhere along 4.0 this got removed. Would bringing that back help?


At boot? Well, not for me, I'm talking about build configuration. My personal reason for not wanting to build/install unneeded modules is I use full disk encryption and want a minimal-sized boot partition on my USB drive. There might be other reasons for attempting a "minimal" build. Just saying Linux makes this (IMHO) a bit easier


----------



## ANOKNUSA (Mar 30, 2016)

Zirias said:


> I personally like the  make oldconfig tool of Linux, too.



`oldconfig` is a great option when building Linux, but again, it's only really useful _for Linux_. It doesn't fit into FreeBSD, where significant kernel config changes are either non-existent-to-rare (-RELEASE and -STABLE) or something you really should not defer (-CURRENT).


----------



## zirias@ (Mar 31, 2016)

ANOKNUSA said:


> `oldconfig` is a great option when building Linux, but again, it's only really useful _for Linux_. It doesn't fit into FreeBSD, where significant kernel config changes are either non-existent-to-rare (-RELEASE and -STABLE) or something you really should not defer (-CURRENT).



Oh, really? From time to time, there is a _new_ release. So even if you're not messing with -CURRENT (in which case I could follow the argumentation of "you absolutely should know what you do"), there _will_ be situations when something like `oldconfig` would come in quite handy. I didn't say anything about a strong _need_ to have it, but just because something isn't necessary doesn't mean it isn't _useful_.

Heck, I just learned even some Linux `udev` magic _can_ come in quite handy, depending on your situation ... I had to access the serial console of my XEN server to get some network interface back up and running and had a hard time finding the correct module for my USB/RS-232 converter without checking Google (all networking was down due to the failed interface), ending up with `kldload /boot/kernel/*.ko` just to get this *?#%&)=ing* converter to work ... `udev` would have had the driver loaded for me as soon as I plugged in the converter. So although this is the kind of magic I'm in general quite unhappy with, even THIS has its legit uses, and I'd love to see something like it as an _optional_ feature. (better make it optional on Linux, too, but I guess the quest for this would be too late ...)

This thread started as a "spinoff" (it quickly grew to off-topic to stay in ONE thread) on some positive mention of the FreeBSD documentation in a "Linux-centric" place. And hey, I _really_ think: why not have a look at what Linux does very well? I STILL think kernel configuration IS a strong point.


----------



## sidetone (Mar 31, 2016)

FreeBSD is made for the command line. I wouldn't like GUI or Ncurses based tools for the kernel. However, it would do good to have dependency checking, or a quick scan to make sure that the kernel options have dependencies enabled before it starts building.

It would probably do you good to look at a FreeBSD book, to understand this is how FreeBSD allows a lot from the command line. This is the style FreeBSD uses.


----------



## zirias@ (Mar 31, 2016)

Well, I guess you _do_ realize that `oldconfig` doesn't use curses, only `menuconfig` does. curses not being "command line" is a bit of a bold statement, one you _could_ discuss. But I don't think this would lead anywhere when all else you have to say is basically I neither understand FreeBSDs nor command lines? I mean, really? Just because I talk about _some_ things that could be done more comfortable?


----------



## Maxnix (Mar 31, 2016)

Zirias said:


> That's the spirit: Look around what others do, identify the things that are better, and take the inspiration  Not directly related, but what I really like looking at Linux is the kernel configuration system (including a curses-based tool), allowing you to configure a minimal set of kernel modules with automatic dependency checking and integrated help. Wouldn't THAT be nice on FreeBSD, too?


Personally, I would not like or need a curses/ncurses based tool. I prefer the $EDITOR configfile approach, but if something like that would be added, well, good for those who like it.


----------



## sidetone (Mar 31, 2016)

Zirias said:


> Well, I guess you _do_ realize that `oldconfig` doesn't use curses, only `menuconfig` does. curses not being "command line" is a bit of a bold statement, one you _could_ discuss. But I don't think this would lead anywhere when all else you have to say is basically I neither understand FreeBSDs nor command lines? I mean, really? Just because I talk about _some_ things that could be done more comfortable?





ANOKNUSA said:


> `oldconfig` is a great option when building Linux, but again, it's only really useful _for Linux_. It doesn't fit into FreeBSD, where significant kernel config changes are either non-existent-to-rare (-RELEASE and -STABLE) or something you really should not defer (-CURRENT).



This is FreeBSD. I'm not a Linux fanatic. A lot is not difficult to do on the command line, and configurations can be saved and backed up easily because of this. https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html, but other FreeBSD books go into better detail. I also use the suggestion Simplifying FreeBSD Kernel Config Files, by using 2 KERNCONFs. One is copied from GENERIC and only trimmed down, and the other only has additions and it references the trimmed KERNCONF.


----------



## zirias@ (Mar 31, 2016)

Just for the record, I know quite well how to configure and build a FreeBSD kernel (well uhm, among some other things btw ...) and wasn't asking about how to do it. The one thing that's not possible in a practical way (yes, manually maintaining a MODULES_OVERRIDE list with all dependencies just doesn't count as a practical way) is building only *some* modules. That might not matter to you, but I'd be interested as mentioned above. The Linux config tools are just a nice possibility to do for example exactly that, so what's your intention writing "I'm not a Linux fanatic"? Do you imply that I am? Or does it mean "It's a Linux idea, so it can't be good"? Having tools to help with configuration doesn't automatically mean changing the config file format.


----------



## sidetone (Mar 31, 2016)

I said, I'm not. I'm implying that I'm focused on what FreeBSD does, which is why I'm on a FreeBSD forum. There's no expectation for me to know details about Linux's configurations, even if I used it in the past. I also have no need for that type of tool, except dependency checking. curses/ncurses will cause a headache and constant problems for people who have to adjust a lot to fix a minor change for a constantly current update. It would take away the finite resources that FreeBSD has, when it's simpler to edit the file. This way also allows me to save it as a file, instead of curses interfering with it. Also, making everything as automated as it can be, is for the Ubuntu user; FreeBSD users are expected to learn about their OS, not have automation for thousands of files and their endless configuration options. Other reasons were explained.


----------



## tobik@ (Mar 31, 2016)

Zirias said:


> Heck, I just learned even some Linux  udev magic _can_ come in quite handy, depending on your situation ... I had to access the serial console of my XEN server to get some network interface back up and running and had a hard time finding the correct module for my USB/RS-232 converter without checking Google (all networking was down due to the failed interface), ending up with  kldload /boot/kernel/*.ko just to get this *?#%&)=ing* converter to work


It sounds like there's a missing entry in /etc/devd.conf for your USB/RS-232 converter. Normally the driver should have been loaded automatically. Maybe submit a bug/patch for this.


----------



## tomxor (Apr 1, 2016)

Zirias said:


> Having tools to help with configuration doesn't automatically mean changing the config file format.



I think this kinda sums it up? obviously replacing manual configuration is not gona happen, i'm sure sidetone's preferences and concerns are shared by many, probably most, and replacing that simplicity and flexibility makes no sense.

Maybe the only nice way for this tool to exist would be as an optional and completely separate (port?). Instead of replacing configs maybe it can just generate them... Also I wonder if it's practical to infer "dependencies" from existing source without modification, or if some kind of extra annotation would be required, the former would be nice n' passive.


----------



## zirias@ (Apr 1, 2016)

sidetone said:


> This way also allows me to save it as a file, instead of curses interfering with it.


A Linux configuration is indeed one text file, too.


sidetone said:


> Also, making everything as automated as it can be, is for the Ubuntu user;


Hahahahaha. Never used that one, but I see where you come from ... so it's not 1337 enough unless you invested too much time without appropriate benefit, right?


sidetone said:


> FreeBSD users are expected to learn about their OS, not have automation for thousands of files and their endless configuration options.


Yep right, kind of reminds me of "watching shit scroll by makes me a Linux expert over night" statements from Gentoo users. Well, I develop software for a living, I know lots of operating systems, and more than a single one from "hacking" their source as well ... do you? If not, please kindly take a step back, thanks.



tobik said:


> It sounds like there's a missing entry in /etc/devd.conf for your USB/RS-232 converter. Normally the driver should have been loaded automatically. Maybe submit a bug/patch for this.


Thanks a lot for *this* useful hint, I really thought automatic module loading was intentionally left out. Now I know where to look for it and I'll definitely do that.


----------



## zirias@ (Apr 1, 2016)

tomxor said:


> I think this kinda sums it up? obviously replacing manual configuration is not gona happen, i'm sure sidetone's preferences and concerns are shared by many, probably most, and replacing that simplicity and flexibility makes no sense.


Yes, of course, but as stated earlier, the Linux configuration is "just a text file" as well. It typically doesn't look nice (like with structure and comments) but of course it COULD, if anyone would bother hand-writing it 



tomxor said:


> Maybe the only nice way for this tool to exist would be as an optional and completely separate (port?). Instead of replacing configs maybe it can just generate them... Also I wonder if it's practical to infer "dependencies" from existing source without modification, or if some kind of extra annotation would be required, the former would be nice n' passive.


Just some quick thoughts on this:

A port probably wouldn't do, because ...
trying to infer dependencies from the source would be complicated and error-prone. There should just be some nice and easy-to-write (-edit) metadata that actively enumerates them. "Done right" (TM), this shouldn't really bother kernel devs because the extra effort to maintain this data would be minimal.
and it wouldn't "replace" anything, I mentioned that before several times, but generating a config file is exactly what the Linux `make {xyz}config` utils do as well.


----------



## sidetone (Apr 1, 2016)

Why don't you develop it, instead of complaining?



Zirias said:


> so it's not 1337 enough unless you invested too much time without appropriate benefit, right?


 Did you miss where I said, it will conflict with the edited file? and it will be a hassle for developers to update constant rolling code.


----------



## zirias@ (Apr 1, 2016)

So, where exactly do I complain? And what are you doing here? And did you ever try to find out what I develop? Why don't you shut up instead of trying to kill any discussion?

*edit:* just to get that straight: You say you don't need what I'm suggesting -- that's fair and I don't have any objections about that. But please leave it at that. Others said they wouldn't want to use a menu-driven tool, but would value some dependency checking. That's a fair statement as well, and discussing is *of course* about opinions. Just please don't talk like your view is the only sensible one and stop assuming anyone not supporting your point of view is "ugly and stupid", like Linus does sometimes .... and just as a quick reminder: automation is in fact what most IT systems are about.


----------



## sidetone (Apr 1, 2016)

Ubuntu is for you.


----------



## zirias@ (Apr 1, 2016)

No it isn't. But with your attitude, discussion forums obviously aren't for you.


----------



## sidetone (Apr 1, 2016)

FreeBSD books epitomize that FreeBSD is a file edited operating system, with powerful abilities. Obviously putting a driven menu in, will hinder this. Secondly, this is a FreeBSD forum, not a Linux forum. Thirdly, you've ignored answers from several people, then keep continuing. Fourthly, you're the one who's getting upset, when I implied I'm at a FreeBSD forum, and not a Linux forum.



sidetone said:


> automation for thousands of files and their endless configuration options.


 will be a strain on developers, when FreeBSD users take pride in learning how to configure their system to their needs.

Ubuntu is for you.


----------



## zirias@ (Apr 1, 2016)

sidetone said:


> FreeBSD books epitomize that FreeBSD is a file edited operating system, with powerful abilities.


Oh really? So you must hate `bsdinstall`.


sidetone said:


> Obviously putting a driven menu in, will hinder this.


No, it won't.


sidetone said:


> Secondly, this is a FreeBSD forum, not a Linux forum.


Right, that's why this whole thread came from some Linux-centric publication talking about FreeBSD documentation. But hey, your world is an island, isn't that nice?


sidetone said:


> Thirdly, you've ignored answers from several people, then keep continuing.


No, I didn't.


sidetone said:


> Fourthly, you're the one who's getting upset, when I implied I'm at a FreeBSD forum, and not a Linux forum.


No, I'm just and only upset about you for ...


sidetone said:


> Ubuntu is for you.


... obviously being a total jerk.


----------



## sidetone (Apr 1, 2016)

ANOKNUSA said:


> The simplicity of the FreeBSD kernel configuration compared to that of Linux is something I find pretty amazing. Think about it: is it really easier to build a minimal kernel by digging through a dozen nested menus and hitting the spacebar 100 times, than by just opening your editor of choice and deleting some lines?





sidetone said:


> have automation for thousands of files and their endless configuration options.


, which is a strain on developers for rolling sources, when there's hundreds of options that can be viewed using `grep`. and there's lacking simplicity, when a menu is going to conflict with it, unless there's an overload of complexity.

You're arguing for the sake of arguing, and it's you who got testy. I'm at a FREEBSD Forum, where there isn't an expectancy to know about Linux `old-config`. You belong in Ubuntu.


----------



## zirias@ (Apr 1, 2016)

This is getting utterly ridiculous, therefore I'm ignoring your posts on this thread from now on. have fun.


----------



## sidetone (Apr 1, 2016)

Good.


----------



## SirDice (Apr 1, 2016)

I suggest everybody calms down and takes a chill pill. Please read rules #2, #3 and #4: Thread 38922/

Thread closed as it's going nowhere fast.


----------

