General configuration question

[hwestii]

I am very new to the FreeBSD world, but am really liking what I see so far. The notion of a standard, cohesive environment is quite new and welcome after the vaguely chaotic Linux world I've been swimming in for some time now.

I have just installed FreeBSD 12.0 on a Dell Latitude 7450 with i5, and I am bouncing between vt and sc for console drivers. One thing in the man pages that has confused me greatly is the use of "options" items. Both the vt and sc pages reference them (example would be "options SC_PIXEL_MODE" from the sc page). Thus far, I've found the configuration regime for FreeBSD pretty comprehensible, but I have no idea where these options items are to be added, and the best of my ability to tell, the man pages are silent on this. Most every topic I've run across has gone out of its way to be clear where changes are to be made, but I am still scratching my head on this. I've grepped the /etc/ directories for files containing the expression "^options", and have found a few, but they don't really help clear anything up for me. This is the first item I've encountered where knowledge I don't possess is presumed, and I'm feeling dumb and frustrated by it.

Any help on this will be greatly appreciated.

 

[T-Daemon]

I have just installed FreeBSD 12.0 on a Dell Latitude 7450 with i5

12.0 is end of life and unsupported on FreeBSD Forums. Please update to 12.1.

Chapter 26. Updating and Upgrading FreeBSD

Information about how to keep a FreeBSD system up-to-date with freebsd-update or Git, how to rebuild and reinstall the entire base system, etc

www.freebsd.org

Both the vt and sc pages reference them (example would be "options SC_PIXEL_MODE" from the sc page). .... I have no idea where these options items are to be added,

It's here:

sc(4) syscons(4)

DRIVER CONFIGURATION
   Kernel Configuration    Options
   ....
   SC_PIXEL_MODE
        Adds support for pixel (raster) mode console.  This    mode is    useful
        on some laptop computers, but less so on most other    systems, and
        it adds substantial    amount of code to syscons.  If this option is
        NOT    defined, you can reduce    the kernel size    a lot.    See the
        VESAMODE flag below.

Same for vt(4).

Chapter 10. Configuring the FreeBSD Kernel

This chapter covers how to configure the FreeBSD Kernel. When to build a custom kernel, how to take a hardware inventory, how to customize a kernel configuration file, etc

www.freebsd.org

But there is no need to add that option to the kernel, it is already in there:

[base] Contents of /releng/12.1/sys/amd64/conf/GENERIC

svnweb.freebsd.org

 

[hwestii]

Yes, I understand where to find those items in the man pages. My broader question is "where are those items to be applied during general use?".

It seems to me that you are saying that these "options" items are kernel configuration options and are used only when recompiling a new version of the kernel. Is that correct?

How common would you say it is for FreeBSD users to be customizing their kernels for general use? I don't think I compiled a new Linux kernel since the 2000s. Or maybe this is just a difference in documentation culture between the two communities.

 

[T-Daemon]

Yes, I understand where to find those items in the man pages. My broader question is "where are those items to be applied during general use?".

I don't want to appear rude, but if you know where to find the "items" in the man pages, then the line "Kernel Configuration Options" should have give you the clue where those items ( options ) are to be applied.

It seems to me that you are saying that these "options" items are kernel configuration options and are used only when recompiling a new version of the kernel. Is that correct?

Yes.

How common would you say it is for FreeBSD users to be customizing their kernels for general use?

Almost never. On rare occasions a device, a port may need a customized kernel. Example, port multimedia/makemkv:

Requirements:

* A custom FreeBSD kernel with sg devices (Linux' "scsi generic" interface) is
  required to use makemkvcon. To build such a kernel, add "device sg" to your
  kernel configuration and follow the instructions at
  https://www.freebsd.org/doc/handbook/kernelconfig-building.html

 

[a6h]

Most of us including me, don't need to compile a custom kernel, building from the ports or use 3rd party installer such as GhostBSD or FuryBSD to install FreeBSD.
As a side note, I have to mention that the whole process may sound more complicated, but in reality it is more straightforward than Linux. One port/package/repo system, and there's no need to find/add/remove different repos/AUR/etc to for example, just install a simple program like lang/fasm. I use fasm as an example, because I faced the horror of dealing with these Linux complexities in the past.

On one side different distro and different package management, and on the other finding the right repo (source or binary), then facing wide range of incompatible semi-de facto setting on different distro. On FreeBSD pretty much everything has a consistence procedure for different solution and architecture. You should take a look at man/doc/handbook of previous versions (EOF) of FreeBSD and you're going to grasp my point clearly. This consistency is also apply to, lets say some less-common areas such as RPI, ARM or even supported Atmel-family.

To wrap up, one thing I hate the most is the unnecessary surprises, and now I reach the point that, I'm sure FreeBSD is never going to surprise me. It follows the protocols.

 

[Jose]

How common would you say it is for FreeBSD users to be customizing their kernels for general use? I don't think I compiled a new Linux kernel since the 2000s. Or maybe this is just a difference in documentation culture between the two communities.

I've compiled a lot more Linux than Freebsd kernels. Last time was long, long ago. Faint memory is that I had to because of an unusual network setup.

 

[ekvz]

It's pretty easy though and i'll probably do it BECAUSE I CAN and because i'll bullshit myself into believing that -march=native -mtune=native -O3 is somehow making my stoneage hardware less sad

 

[hwestii]

I don't want to appear rude, but if you know where to find the "items" in the man pages, then the line "Kernel Configuration Options" should have give you the clue where those items ( options ) are to be applied.

It wasn't clear to me whether the "kernel configuration" mentioned was something done dynamically at runtime, like through RC.CONF, or statically, at compile time, as seems to be the case.

 

[T-Daemon]

It wasn't clear to me whether the "kernel configuration" mentioned was something done dynamically at runtime, like through RC.CONF, or statically, at compile time, as seems to be the case.

I see. In your first posting it wasn't obvious that you meant that. If you haven't done it yet, I suggest you read sysctl(8), sysctl.conf(5), loader(8) and loader.conf(5). Those man pages give you an idea how configuration can be passed to the kernel driver through "SYSCTL TUNABLES" ( also during runtime ) and "LOADER TUNABLES" ( see vt(4) man page ).

And please read rc.conf(5) again.