The information is basically taken from kldload(8).
Details
Details
- Reviewers
kib ziaee markj - Group Reviewers
docs manpages Contributor Reviews (src) - Commits
- rG1e2c9bcc4ed5: kldload.2: Provide more info about file argument
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/libsys/kldfind.2 | ||
|---|---|---|
| 51 ↗ | (On Diff #171431) | I'm not sure: maybe it's better to reference sysctl(3) here instead. |
Comment Actions
The information is basically taken from kldload(8).
This is basically what you want to avoid doing at all costs. Then if it ever changes, now we have to both change and remember to change twice as much stuff. It can easily grow so much it becomes not practical given our manpower. For example, last year we created a new filesystems ports category. I changed all the documentation in the src tree in six hours. The doc tree? There were thousands of references across all the different books, articles, and their translations. Nobody did it and nobody is going to do it. So, we want to keep the documentation down, and cross-reference carefully so we can maintain things. Think about the hierarchy of information flow, and not try to make every single page an exhaustive one stop shop.
That said, this is probably fine, we'll see what kib or markj says. You've just been sending a lot of manual changes lately (which is awesome, thank you!) and I wanted to share this.
Comment Actions
The system call is a better place for this info. But it's ok to have it botg places in this case
Comment Actions
This patch does not make sense (to me at least). kldfind(2) looks up kld from the loaded files in kernel, it does not search anything in the file system.
What the syscall does it strips the passed filename from the non-base path components, and then compares the base name with names of all loaded klds, returning the finding, if any.
kldload(2) part is probably fiine.
Comment Actions
Don't touch kldfind(2), leave changes only for kldload(2).
Thank you everyone for the feedback! I also don't really like duplicating the text, but in this case I believe it indeed can be done, because this is the description of the argument format. I don't think the reader must go into kldload(2) in order to find out how the format for the filename should be specified and vice versa.
| lib/libsys/kldload.2 | ||
|---|---|---|
| 42–55 | Would be nice to somehow explain what 'kld file' is. | |
| lib/libsys/kldload.2 | ||
|---|---|---|
| 42–55 | Right now all the kld*(2) man pages refer to them as just 'kld files' without any additional information. I guess then we should add such explanation in all these man pages? | |
| lib/libsys/kldload.2 | ||
|---|---|---|
| 49 | I didn't quite understand: did you mean 'loader tunable' here? As I can see, kern.module_path is almost always referred to as 'sysctl'. I couldn't find it as loader tunable neither in loader.conf(5), nor in tuning(7). Or did you mean 'tunable sysctl' in sense that this sysctl variable is writable? I think I'm a little confused by the terminology. | |
| lib/libsys/kldload.2 | ||
|---|---|---|
| 49 | It is loader tunable. | |
Comment Actions
Merged, thanks Artem! I trimmed the commit message title, some git tooling expects it to be under 51 characters, so try and shoot for that when possible.