lkml.org 
[lkml]   [2006]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC/PATCH 1/2] in-kernel sockets API
    Date
    On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote:

    > Yes, and the long list of open source licenses listed on the FSF website
    > as incompatible with the GPL.

    Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the
    reason of enabling drivers to offer functionality to the kernel -- not for
    people who want to turn the kernel into applications. (Consider for example
    how netfilter is exposed as GPL. You can build applications [routers] out of
    it, but in that case you're doing a work derived off of Linux, and you should
    be abiding by its GPL licensing terms)

    > > Then would offering a 'stable API in disguise' not be a disaster and an
    > > irritation to these people? If the kernel doesn't specify that an
    > > in-kernel interface is stable, then there is no reason to expect it to
    > > be. It might not change, but there won't be too much sympathy for
    > > out-of-tree users if it does. The kernel comes with big warnings about
    > > the lack of a stable API for a reason.
    >
    > In fact most core kernel facilities (spin lock, memory caches, character
    > and block device interface, even core file system) have had a very stable
    > API (way back to early 2.4 kernels). An in fact most of them are derived
    > from some variant or precursor to UNIX. For example, memory caches are a
    > Sun Solaris concept.

    I'm not advocating changing the API for no reason / just to piss off out of
    tree developers. I'm just trying to make clear that in these cases, 'stable'
    is just an observation -- not something you can count on.

    > It is the lack of an ABI that is most frustrating to these users.

    And the presence of an ABI would be _very_ frustrating to core developers. Not
    only would these people suffer, everyone would -- developer time would be
    wasted dealing with cruft, and forward progress would be slowed.

    > > > Another thing to consider is that the first step for many organizations
    > > > in opening a driver under GPL is to release a proprietary module that
    > > > at least first works.
    > >
    > > If the driver is an old-tech Linux port, then it seems there isn't too
    > > much stopping them from doing this today (aside from the fact that some
    > > people think proprietary modules are murky anyway). In this case, we
    > > don't want a stable API/ABI, because then we leave them with little
    > > incentive to open the code.
    >
    > "old-tech"? No, these are high-tech drivers supported by commercial RTOS,
    > from which Linux stands to benefit. And, by not allowing these
    > organizations to take the first step (generate a workable Linux driver)
    > such a policy provides them little incentive to ever move the driver to
    > Linux, and cuts them off from opening it.

    Perhaps another term may have been more appropriate. What I mean by 'old tech'
    is more 'existing code' -- ie, something you would port.

    And these organizations _are_ afforded the opportunity to take the first step
    -- that's why interfaces critical to drivers are currently EXPORT_SYMBOL().

    > I don't think that it is fair to say that an unstable API/ABI, in of
    > itself, provides an incentive to open an existing proprietary driver.

    Sure it does, depending on your perspective and what you're willing to
    consider. The lack of a stable API/ABI means that if you don't want to have
    to do work tracking the kernel, you should push to have your drivers merged.

    > > We're not as perfect as I wish we were. But the lack of stable API (dead
    > > horse) is something that is fairly well established and understood. I
    > > think most people feel that the cost-benefit analysis, for Linux anyway,
    > > strongly favors no stable API.
    >
    > Well, the lack of a stable ABI is well known. The API is largely stable
    > (but not sacrosanctly so) for the major reason that changing it within a
    > large code base is difficult and error prone at best.

    Perhaps, but calling it 'stable' in any sense other than idle observation is a
    disaster, because the idea leads to pain and suffering when you do have a
    major reason to change the API.

    Thanks,
    Chase
    -
    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/

    \
     
     \ /
      Last update: 2006-06-14 02:56    [W:3.208 / U:0.660 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site