git: 866c8b8d5ddb - main - kldload(8): Add note about using kld_list in rc.conf(5)

[Daniel Ebdrup Jensen]

On Mon, Feb 08, 2021 at 09:22:25AM -0600, Kyle Evans wrote:
>On Mon, Feb 8, 2021 at 9:07 AM Eugene Grosbein <eugen at grosbein.net> wrote:
>>
>> 08.02.2021 21:58, Kyle Evans wrote:
>>
>> >>>> kld_list cannot do that.
>> >>>
>> >>> Huh? kld_list accepts a full pathname, which is the same kind of
>> >>> specification you'd need to do with one from port in loader with
>> >>> *_name.
>> >>
>> >> Good, but seems to be undocumented.
>> >>
>> >
>> > In what sense? Is there some other place that kld_list is even
>> > documented than kldload(8)?
>>
>> Naturally: rc.conf(5), also in /etc/defaults/rc.conf
>>
>
>Wow, that documentation is just flat wrong for multiple reasons.
>
>     kld_list    (str) A whitespace-separated list of kernel modules to load
>                 right after the local disks are mounted, without any .ko
>                 extension or path.  Loading modules at this point in the boot
>                 process is much faster than doing it via /boot/loader.conf
>                 for those modules not necessary for mounting local disks.
>
>The second part of the first sentence is a self-imposed limitation,
>and an incredibly unimportant one at that. Specifying a .ko will only
>break the existing "Is it loaded" behavior and cause it to always try,
>which is mostly a nuisance at best because it will get rejected if the
>kldstat inquiry is wrong -- the kld rc script will append .ko whether
>the path has one or not, so this should be fixed. Despite that, a path
>will work just fine for the most part; kldstat -v shows the fully
>qualified path. If it wanted to be improved, it just needs to basename
>what it was given to be able to detect if it was loaded from any other
>path and pass that in as the -e argument to load_kld if it really was
>a file.
>
>It's not wrong about loading modules being faster here, and at some
>point in the past it was even necessary due to loader(8) being too
>early or problematic in some terrible cases (e.g. nvidia modsetting
>bits), but the second half of that sentence should probably just be
>omitted or reworked to more vaguely refer to "... those modules not
>necessary for booting the system, including those required for
>mounting the root filesystem." The key changes being that there are
>other reasons you might need to load something early enough in boot,
>and that root isn't always a local disk. It's OK to call out the more
>common case for folks, but this feels a lot more absolute than it
>needs to be.
>_______________________________________________
>dev-commits-src-main at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main
>To unsubscribe, send any mail to "dev-commits-src-main-unsubscribe at freebsd.org"

Hi folks,

I'd originally replied to imp@ when he sent me a comment about this,
although because of a misconfiguration I hadn't seen it was also sent to
a different list, but in it I remarked the same things about
nvidia-modesetting and the speed, however I do think Kyle is right that
it's better to rework the sentence because mountroot isn't really
docuemented in the extant manual pages.

I'm not sure about wanting to document the other details outlined here,
because I'm not entirely sure I understand them - plus, it's in a
different manual page, so it's free for anyone with an active commit bit
and an understanding to persue. :)

I'll try and work something out and do a Phabricator review, but let's
try and keep the bike-shedding to a minimum.

Yours,
Daniel Ebdrup Jensen

P.S. We all know the best colour is purple. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/dev-commits-src-all/attachments/20210208/f4920046/attachment.sig>