Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wg.4: document kernel config option #1597

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

llfw
Copy link
Contributor

@llfw llfw commented Feb 12, 2025

wg(4) can be compiled into the kernel (device wg), but the wg.4 manpage does not document this. adjust it to mention this like other drivers do.

@llfw
Copy link
Contributor Author

llfw commented Feb 12, 2025

cc @kevans91

wg(4) can be compiled into the kernel (device wg), but the wg.4 manpage
does not document this.  adjust it to mention this like other drivers
do.
Copy link
Contributor

@concussious concussious left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can wg be loaded with kld_list? We're recommending rc.conf lately for things that don't need to be at early boot.

I really adore the style of vt(4). You might be interested in what I did here for another if_module 1.

Could we doing something like that here? I think this style is more consistent with how synopsis is in other sections of the manual and other BSDs.

Footnotes

  1. https://reviews.freebsd.org/D48905

@llfw
Copy link
Contributor Author

llfw commented Feb 15, 2025

i don't have a strong preference for wording here, but i was following the example of other drivers, e.g. ix(4), cxgbe(4), epair(4) and tun(4), which all have the same wording i've used here referencing loader.conf.

if we want to recommend using kld_list instead, then i think we need to:

  • decide if this should be recommended for all network interfaces (e.g. ix, cxl, ...) or only software interfaces (wg, epair, ...)
  • agree on a standard wording for the SYNOPSIS section
  • update all the affected manpages at once

since hardware drivers can sometimes be required before the root filesystem is mounted (e.g., for NFS root) my feeling is we should only recommend kld_list for the software drivers.

alternatively, we would need to document both loader.conf and kld_list options for the hardware drivers, which i'm not opposed to, but it would make the synopsis quite wordy.

does that sound reasonable? what do you think?

@llfw
Copy link
Contributor Author

llfw commented Feb 15, 2025

possible sample wording based on vt(4):

NAME
     wg – WireGuard protocol driver

SYNOPSIS
    device wg

    In rc.conf(5):
    kld_list="${kld_list} if_wg"

    In loader.conf(5):
    if_wg_load="YES"

although i like how concise this is, i'm a bit concerned that a new FreeBSD user will type man 4 wg and not know what device wg means or where it should go, especially since the vast majority of users do not compile a custom kernel nowadays.

@concussious
Copy link
Contributor

The way you have written it is good by me. If @sergio-carlavilla and/or @mhorne consent, I can commit this as is. It follows what we've generally been doing the last decade or so perfectly.

I am jealous of the other BSDs elegant synopsis style, and think vt(4) sets the example to achieve this elegance for FreeBSD.

I think explaining what "device wg" means should be part of a new intro(4). The other BSDs just have a kernel configuration line in synopsis with no explanation for all drivers, as do commands in FreeBSD.

As for loader/rc.conf, I really like that both because it's showing the ways it can be used, but I think it would need to go in intro(4) something about "kernel interfaces should be enabled via one of three methods". The redundancy could easily confuse people.

@concussious
Copy link
Contributor

I think it would need to go in intro(4)

This kind of stuff historically was in section 0, and I heard there are fundamental design issues which make bringing back section 0 unrealistic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants