> On the _other_ hand:
> 1. 4.0 hasn't been out long enough for there to be any significant support
> for it in proprietary systems. It takes more lead time than this.
Unfortunately, many vendors will simply install from the 4.0-RELEASE CD
and build their modules there.
> 3. Any proprietary module that depends so heavily upon kernel internals is,
> IMNSHO, broken by definition. If one is writing a proprietary module,
> particularly for an open-source system, one should write to the lowest
> common denominator and _not_ to internal interfaces that could change
> out from under you at any moment.
Er. spl() is a public interface.
> 5. The SMP stuff is about _internal_ interfaces, not external ones. External
> interfaces are the ones that are fixed in any OS, not the internal ones.
> Otherwise, how do we make progress? The Linux ABI, btw (to refer to your
> previous message on the subject), is a set of _external_ interfaces, not
> internal ones.
Steve Passe actually argued quite eloquently against his own decision;
the "real work" that actually depends heavily on this foundation is
almost certainly never going to come back to the 4.x branch. Since these
changes don't actually bring any real improvements in and of themselves,
there's little point in merging them for their own sake.
The _only_ reason to bring these changes back is if we're contemplating
massive changes in 4.x's SMP support, and if we're willing to live with
the significant compatibility churn this is going to cause. Nobody yet
has suggested that this is the case, and I do not believe that it is.
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message