Date: Sun, 17 Oct 1999 13:16:01 -0600 From: Warner Losh <imp@village.org> To: Doug <Doug@gorean.org> Cc: Marcel Moolenaar <marcel@scc.nl>, arch@freebsd.org Subject: Re: make world issues Message-ID: <199910171916.NAA04821@harmony.village.org> In-Reply-To: Your message of "Sun, 17 Oct 1999 11:58:48 PDT." <380A1C68.BF17ED9F@gorean.org> References: <380A1C68.BF17ED9F@gorean.org> <3808BC30.2699465B@scc.nl>, <199910162136.PAA01266@harmony.village.org> <38099CCB.99EE1C97@scc.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <380A1C68.BF17ED9F@gorean.org> Doug writes: : The simple solution for that problem was already suggested by someone : else, but may have been lost in the noise. You require a define to : incorporate the shims. Make the define a stock part of the "make : upgrade," or whatever we want to call it from 2.2.x/3.x to 4.x, and put : it in UPDATING so that -current -> later -current upgraders can also use : it. While they're there they're harmless, and/or necessary, and once : your system is all upgraded they go away on the next kernel rebuild. I like this. It can even be completely automated. It is a big PITA to have to rebuild a kernel before building world. : With proper comments in the code as to what they are there for, and a : recommended time of nuking (say, one year after 4.0-Release) all of the : admittedly possible scenarios you mention vanish. I've done exactly this : on some other projects I've worked on and never had a problem with it. In a past live, I've shot obsolete APIs in the head with what in FreeBSD would be expressed as #include <osreldate.h> /* * Allow osignal stuff until FreeBSD 5, which will be one major * release after they are added. */ #if __FreeBSD_version < 500000 extern int osignalbaz(int, ...); #else #error Please delete stale code. #endif This automatically kills osignalbaz when FreeBSD 5 is created and also tells the reader that this was explicitly limited to version < 5. The comments add to this and tell why the magic number 5 was picked. We've never really supported going from major release n to n + 2 in one step, although that has worked from 1.x -> 3.early. I'm not sure that it will still work, however. Combining this technique with the one above would ensure that the code disappears in the future. When the OI library had an API that went out of use, we deleted the code. When I was doing things on the OI library, I didn't use the #else clause above, that just occuring to me as I'm tying here. The argument that shims are evil and will last forever is one of ignorance of techniques to automatically kill them in the future. It is my perception of setting on the sidelines that each time Marcel has been given brief and a simple solution he's come up with a different excuse about why he hasn't provided backwards compatibility. It would be more honest to just say "I don't want to provide backwards compatibility, so you are SOL unless you or someone else wants to do it." There is precidence for this (witness CAM, which even change device names), but what I see as a constantly changing excuse rubs me the wrong way. I believe this will cause the problem to fester rather than being dealt with, imho. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910171916.NAA04821>