Kernel build utilities

Status
Not open for further replies.
zirias@

zirias@

Developer
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?
 
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?
 
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.
Click to expand...
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?
Click to expand...
Well, no, although I love vim ... see above ;)
 
If I put
Code: 
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?
 
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.
Click to expand...
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.
 
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.
Click to expand...

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.)
 
wblock@ said:
But that was what you said:
Click to expand...
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 :)
 
sidetone said:
(If the kernel configuration comments are in the wrong thread, can someone move it to the right thread.)
Click to expand...

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 :)
 
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.
 
Zirias said:
The modules that is (which is different from what is built into the kernel). Why do you get so defensive?
Click to expand...
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.
 
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.
Click to expand...
That might be an equally good idea, still something that doesn't exist right now, as far as I know?
 
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@ 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.
Click to expand...
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.
 
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?
 
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?
Click to expand...
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 :)
 
Zirias said:
I personally like the make oldconfig tool of Linux, too.
Click to expand...

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).
 
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).
Click to expand...

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.
 
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.
 
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?
 
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?
Click to expand...
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.
 
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?
Click to expand...

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).
Click to expand...

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.

 
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.
 
Status
Not open for further replies.
Back
Top