Create deprecation management functions.
ClosedPublic
Actions

Authored by imp on Jan 10 2018, 12:59 AM.

Details

Reviewers: None
Commits: rS328523: Tag the current round of deprecated drivers.

Summary

gone_in(majar, msg); If we're running in FreeBSD major, tell

			the user this code may be deleted soon.
			If we're running in FreeBSD major - 1,
			the the user is deprecated and will
			be gone in major.
			Otherwise say nothing.

gone_in_dev(dev, major, msg) Just like gone_in, except use device_printf.

New tunable / sysctl debug.oboslete_panic: 0 - don't panic,
1 - panic in major or newer , 2 - panic in major - 1 or newer
default: 0

if NO_OBSOLETE_CODE is defined, then both of these turn into compile
time errors when building for major. Add options NO_OBSOLETE_CODE to
kernel build system.

This lets us tag code that's going away so users know it will be gone,
as well as automatically manage things.

Diff Detail

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 14237
Build 14400: arc lint + arc unit

Event Timeline

imp created this revision.Jan 10 2018, 12:59 AM

Harbormaster completed remote builds in B14234: Diff 37704.Jan 10 2018, 12:59 AM

And of course the same comments for _gone_in_dev() as in _gone_in().

sys/kern/subr_bus.c
5608	"Manage deprecated / obsolete code."
5632	Use `P_OSREL_MAJOR()` rather than doing it by hand.
5636	The "running" seems... not right. "Obsolete code; will be removed soon" sounds better to me.
sys/sys/systm.h
468	"API for managing deprecated / obsolete code."

rpokala added inline comments.Jan 10 2018, 1:24 AM

sys/kern/subr_bus.c
5632	For that matter, shouldn't `m` be a static variable (or a #define) outside of the scope of either of these functions, since it's a constant value used by both of them?