Date: Mon, 6 Oct 1997 20:31:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gurney_j@resnet.uoregon.edu Cc: tlambert@primenet.com, luigi@labinfo.iet.unipi.it, freebsd-current@FreeBSD.ORG Subject: Re: how to detect different kernel code (select or poll) Message-ID: <199710062031.NAA24338@usr04.primenet.com> In-Reply-To: <19971006124156.64153@hydrogen.nike.efn.org> from "John-Mark Gurney" at Oct 6, 97 12:41:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > IMO, the best way is for the code to become part of the official source > > distributions. > > > > But, I agree that there are some cases where this isn't possible; namely > > commercial code that would prefer not to donate code, even though they > > know that, if they did, it would relieve them of the maintenance burden > > for things like this (there are a *lot* of things like this). > > Terry, what does this message have to deal with a solution to the problem > that we posted?? all it does is restate what we are trying to do... It provides a soloution: check the code in, and let normal maintenance migrate it across the interface changes for you. I think the GPL camp doesn't understand what a strong incentive this is toward contribution, without forcing it. I'm sure Dennis gets annoyed any time there is a change that hits his serial drivers, but he eats the overhead on the principle that that's the price of not putting the code into the main line source tree: he gets to shoulder the maintenance burden of hundreds of active developers changing his interfaces on him. Maybe he will eventually get annoyed enough to contribute the driver, and rely on the quality of his hardware for sales. ;-). Or, he might just split the driver so the pieces that get maintained are on the other side of an interface from his real code. If Adaptec didn't have the name trademarked, he could call the interface "HIM". 8-) 8-). You may also want to look at the other soloution I posted, which was to look for a manifest constant for "poll" to feature test instead of version test to let you know the feature is present. I don't like it because it makes no sense in the context of code intended to be integrated at some point. Really, I don't see why the 2.2 code could not go into the 2.2 tree right now. My other point was that, whatever you do, you will have to rip out later if you intend to integrate the code into FreeBSD: it makes no sense for a file under a tag known to contain a feature to do any feature testing whatsoever: the feature test is implicit in the tag chosen to check out the code. It's redundant, and the fail-test code for either tag will end up being dead code at all times given any particular tag. In any case, if you are looking toward __FreeBSD__, you are looking in the wrong place. I think my if_de.c example proves that. The if_de.c code is variant based on which OS revision the compiler was built under, instead of being variant based on the tag it was checked out under. This is *broken*, big-time. Don't commit the same crime. The __FreeBSD__ test is not useful until the version information is obtained from the system instead of being manifestly defined at the time the compiler or preprocessor was built. Even then, it is only useful for user space code, and then only user space code targetted to the OS version doing the compilation. People who write user space code that depends on a particular OS revision are writing non-portable user space code. People who write kernel space code that depends on a particular OS revision are fine, so long as they don't attempt to duplicate revision control using #ifdef's. Feel free to take me out of context again, though... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710062031.NAA24338>