From owner-freebsd-hackers Sun Nov 1 13:07:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06677 for freebsd-hackers-outgoing; Sun, 1 Nov 1998 13:07:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06666 for ; Sun, 1 Nov 1998 13:07:54 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA02784; Sun, 1 Nov 1998 14:07:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd002770; Sun Nov 1 14:07:42 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA26376; Sun, 1 Nov 1998 14:07:40 -0700 (MST) From: Terry Lambert Message-Id: <199811012107.OAA26376@usr05.primenet.com> Subject: Re: s/bpfilter/bpf/ To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 1 Nov 1998 21:07:40 +0000 (GMT) Cc: finrod@ewox.org, hackers@FreeBSD.ORG In-Reply-To: <5159.909675209@time.cdrom.com> from "Jordan K. Hubbard" at Oct 29, 98 07:33:29 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > While in Arnhem, I discussed renaming the bpfilter pseudo-device to > > bpf. There seemed to be agreement that it would be more consistent > > (amongst other items, the device nodes are named /dev/bpf*, and the > > man page is bpf(4)). > > I agree that this change is overdue, but I also wonder whether or not > you could do this so that ``pseudo-device bpfilter'' would continue to > be a synonym for bpf. It wouldn't appear in any documentation or be > suggested, but would at least continue to work for those with old > config files. When do deperecated things get removed? It seems that there is not an overall list of deprecated stuff such that things which are deprecated actually end up going away at some point. In other words, it seems that the answer to this question is "never, we just accumulate cruft until our head explodes". I would suggest one release cycle. I would also suggest managing this automatically, with something like (note the use of the word "like"): --------------------------------------------------------------------- #include #if (DEPRECATED > 2) #warning "This file contains obsolete code which should" #warning "be removed from the source repository." #else /* This code will be obsolete in release deprecation cycle 3*/ ... /* warn the user that (whatever) is going away next release*/ fprintf( stderr, "option 'bpfilter' is deprecated; use 'bpf' instead\n"); ... #endif /* DEPRECATED*/ --------------------------------------------------------------------- You would increment the value of the manifest constant DEPRECATED each time there is a release. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message