On Mon, 2010-09-13 at 16:37 +0200, Benny Halevy wrote: > On 2010-09-13 14:29, Trond Myklebust wrote: > > On Mon, 2010-09-13 at 13:24 +0200, Benny Halevy wrote: > >> On 2010-09-11 03:07, Trond Myklebust wrote: > >>> On Fri, 2010-09-10 at 19:58 -0400, Christoph Hellwig wrote: > >>>>> +EXPORT_SYMBOL(pnfs_register_layoutdriver); > >>>> > >>>> Al exports from nfs.ko needs to be _GPL - this is in no way a public > >>>> API, just an internal subdivision of the nfs client. > >>> > >>> ACK. We're not committing to supporting a stable ABI here in any way, > >>> shape or form... > >> > >> OK, not yet. > >> > >> However, on the longer run I'd like us to consider formalizing > >> the kABI for non-GPLed layout drivers. > >> > >> I think that this is a great selling point as it fully materializes the > >> extensibility of the layout-type / layout-driver design model. > > > > No. I'm not committing to a kabi, ever... > > Care to explain your reasoning in some more details? It has already been laid out in Documentation/stable_api_nonsense.txt. It boils down to the following: 1) I don't _ever_ want to have to deal with debugging problems that might involve binary-only modules. 2) I want to be able to change interfaces in order to optimise/improve the code as needed without having to check in with a bunch of out-of-tree maintainers about whether or not it is 'OK' to do so. 3) I don't see a need for linking to non-GPLed code. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
