Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: [RFC/PATCH 1/2] in-kernel sockets API | Date | Tue, 13 Jun 2006 17:07:40 -0700 (PDT) |
| |
Followup to: <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse> By author: Chase Venters <chase.venters@clientec.com> In newsgroup: linux.dev.kernel > > > > Why not? Not all non-GPL modules are proprietary. Do we lose > > something by making a nice stable api available to non-derived > > modules? > > Look out for that word (stable). Judging from history (and sanity), > arguing /in favor of/ any kind of stable module API is asking for it. > > At least some of us feel like stable module APIs should be explicitly > discouraged, because we don't want to offer comfort for code > that refuses to live in the tree (since getting said code into the tree is > often a goal). >
The much bigger problem is that there is a substantial cost to maintaining a stable API. The VFS in Linux, for example, was relatively stable from long before the 1.0 days until the 2.0 series. However, in 2.1 there was a radical change -- the dcache -- which broke every filesystem driver in fundamental ways. This was followed by quite a bit of instability as all the various filesystems adapted, and sometimes fed back requirements to the original code.
This type of iterative programming is by definition forbidden if the API is to be stable, and is substantially harder if it has to be done in a coordinated fashion. It took long enough as it is.
Stable *ABIs* are even worse, and are hard even for userspace to deal with, and generally involve adding costly conversion layers.
So it is all a matter about what you expect from a "stable" API.
-hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |