From owner-freebsd-current Mon Apr 24 10: 0:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 68EFF37BA1C for ; Mon, 24 Apr 2000 10:00:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70763; Mon, 24 Apr 2000 10:00:24 -0700 (PDT) (envelope-from dillon) Date: Mon, 24 Apr 2000 10:00:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200004241700.KAA70763@apollo.backplane.com> To: "Jacques A . Vidrine" Cc: Richard Wackerbarth , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility References: <00042409270400.09338@nomad.dataplex.net> <20000424101314.A76089@spawn.nectar.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Mon, Apr 24, 2000 at 09:27:04AM -0500, 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. : :How real is this? What modules are we talking about? The last time :I queried on `-stable' for users of third-party modules, only one was :revealed. : :Are all modules effected, or only those that use certain interfaces? : :> That is why STABLE INTERFACES are so IMPORTANT to USERS. : :Agreed. :-- :Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org Many kernel interfaces are macros. So while the API stays the same, the actual implementation winds up buried in the module code. If the implementation has to change (even though the API does not), those modules must be recompiled. This is an unfortunate fact of life when it comes to kernel loadable modules and is true of both Linux and FreeBSD. I've done a quick audit of the spl code and I think I'm actually wrong there... it looks like the SPL code is in fact implemented as a procedure ( I remembered it being a macro but it actually isn't from the point of view of modules that use it). So I think we're safe in this particular case. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message