Richard Wackerbarth wrote:
> On a released system, I may not have the sources to recompile the module.
> It might be a proprietary module that I got with the hardware, for example.
> That is why STABLE INTERFACES are so IMPORTANT to USERS.
>
> "Current" is a sandbox. Lower expectations are part of that game.
> But released systems are stone houses, not sandcastles.
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.
2. Significant enhancements are often worth the price in needing to rebuild
modules. The SMP fixes are quite significant and, IMHO, are very worth
the possible short-term instability induced by them. (Although it looks
like they're quite stable.) Consider me a customer that is very interested
in these fixes even though my bread-and-butter system will need to be
rebuilt.
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.
4. No system, released or otherwise, is a "stone house." At best it's a
wooden house (to use your terminology), since defect fixes might require
changes to internal interfaces. I know, I do this for a living.
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.
Number six is probably better unsaid.
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message