Page MenuHomeFreeBSD

Update getenv(9) manpage to reflect the new world order
Needs ReviewPublic

Authored by davide on Oct 17 2014, 5:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 1, 1:17 AM
Unknown Object (File)
Oct 22 2024, 9:46 PM
Unknown Object (File)
Oct 20 2024, 11:30 PM
Unknown Object (File)
Oct 18 2024, 1:23 AM
Unknown Object (File)
Oct 18 2024, 1:23 AM
Unknown Object (File)
Oct 18 2024, 12:59 AM
Unknown Object (File)
Oct 2 2024, 9:32 PM
Unknown Object (File)
Oct 2 2024, 10:09 AM
Subscribers

Details

Reviewers
jhb
Group Reviewers
manpages
Summary

r273174 renames in-kernel version of getenv/setenv to kern_setenv/kern_getenv.
This commit updates the manpage accordingly.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

davide retitled this revision from to Update getenv(9) manpage to reflect the new world order.
davide updated this object.
davide edited the test plan for this revision. (Show Details)
davide added reviewers: Doc Committers, jhb.
davide added a subscriber: markj.

The manpage changes are ok, but I'm not a huge fan of this change in general. You have kern_getenv(), but the rest of the functions are getenv*() so that is confusing. Also, there is a userland unsetenv(3), yet you didn't rename the kernel unsetenv(), so the change isn't complete either. :(

I would rather find another way to solve this problem if possible then obfuscating all of the kernel source code. sys_foo() was annoying but tolerable-ish, but this is much more annoying. These routines at least have very similar semantics (and getenv() has the same API/ABI). How are you handling malloc() and free()? Those seem like a much larger problem (and renaming those would also be far more invasive and something I would oppose).

unsetenv is not used anywhere in the kernel -- just in the loader. As you may see the loader code was unchanged.
Do you have an alternative to handle the whole thing in your mind?