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.
> "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
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.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to