Re: [RFC/PATCH 1/2] in-kernel sockets API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Followup to:  <[email protected]>
By author:    Chase Venters <[email protected]>
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux