On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser <s...@freebsd.org> wrote: > > Am 15.11.20 um 20:41 schrieb Kyle Evans: > > This is a separate (valid) problem, but not directly related to > > Scott's work here. sysctlbyname now goes directly to the kernel with > > no chance for the user.* sysctls to intercept. That should > > independently be fixed to maintain the illusion that they're real > > sysctl's. > > user.localbase is a real sysctl, but with a default value returned > when sysctl(3) is used. >
Yup. > The getlocalbase() function should not depend on this default value, > since it contains an identicl default value that can be returned if > sysctlbyname fails (or rather returns a zero length string in case > no other value has been written to the kernel). > I don't care about this particular application, to be honest, but about the general problem. libc has a sizable chunk of code in sysctl(3) dealing with user.* sysctls, and sysctlbyname will never see it. This isn't documented in the manpage, and IMO it's really just an oversight; libc should still be able to provide the values as seen in ^/lib/libc/gen/sysctl.c whether you've invoked sysctl() or sysctlbyname(). At a glance, it looks like localbase is the only one that's also tunable, most of these don't really even need to take a trip to the kernel to read. Thanks, Kyle Evans _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
