Page MenuHomeFreeBSD

sysctl: deprecation notices
AcceptedPublic

Authored by kevans on Sep 15 2019, 1:45 AM.

Details

Summary

First stab at adding the capability of tagging sysctls for deprecation. Unsure who to tag, so I'm going with some folks generally involved in these discussions in the past, or that are generally interested in killing things... the downside to this approach is that, for instance, sysctl(8) will actually hit a node's handler anywhere from two to five times depending on what you're doing.

Instead of trying to indicate major version and taking up a couple of precious sysctl flag bits, just generically say "this is deprecated and will be removed in a future version". I would think that sysctl getting deprecated would either be generally unused or easy enough to transition away from (compared to, say, whole drivers) that "it's going to go away" and any advice offered in relnotes would be sufficient.

net.link.tap.user_open will be our first victim; this sysctl will be deprecated in favor of just letting node permissions control access as we do pretty much everywhere else.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 26501

Event Timeline

kevans created this revision.Sep 15 2019, 1:45 AM
rgrimes accepted this revision.Sep 15 2019, 4:23 PM

This is defanitly needed. Only two comment, you elude to having a version, it would indeed be nice to have a thing like the gonein(13) functionality, how to do that I do not know, and I would commit this in 2 parts, the new functionality, and then its first use.

This revision is now accepted and ready to land.Sep 15 2019, 4:23 PM

This is defanitly needed. Only two comment, you elude to having a version, it would indeed be nice to have a thing like the gonein(13) functionality, how to do that I do not know, and I would commit this in 2 parts, the new functionality, and then its first use.

@imp and I discussed that a bit... it ends up burning a couple more bits, and I'm not sure how useful.

As for the first user, I'm actually going to end up revising it a little bit because it needs an UPDATING and I'm going to go ahead and add an option for those that might still want it restricted to superuser since it's lightweight and easy to add.