lkml.org 
[lkml]   [2006]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: wpa supplicant/ipw3945, ESSID last char missing
    Jean Tourrilhes wrote:
    > On Wed, Oct 04, 2006 at 11:38:19AM -0700, Linus Torvalds wrote:
    >>
    >> On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
    >>> You can't froze kernel userspace API forever. That is simply
    >>> not workable
    >> Stop arguing this way.
    >>
    >> It's not what we have ever done. We've _extended_ the API. But we don't
    >> break old ones.
    >
    > Old APIs get deprecated, and people are forced to the new API,
    > which is exactly the same as far as userspace is concerned. This
    > transition is exactly the same as what you propose, both kernel API
    > coexist for some time, except it happens in userspace instead of in
    > kernel, which is an implementation detail.
    > So, my question is when can I remove the old ESSID API.
    >
    >> I don't even see why you argue. Even the people directly involved with
    >> this thing seem to say that it should have some simple translation layer
    >> and do the internal format thing. We've had major subsystem that do that,
    >> and I don't see why you think wireless is so different, and so special in
    >> this respect.
    >
    > The Wireless people (Jouni, Dan) decided to change the
    > *userspace* API. We could translate the new *userspace* API to the old
    > kernel API, but I don't see the point.

    Kernel API and userspace API are two vastly different things. We change
    the kernel API all the time. We _don't_ change the userspace API,
    except when "change" is defined as an additional to an existing API.


    >> If you need to break something, you create a new interface, and try to
    >> translate between the two, and maybe you deprecate the old one so that it
    >> can be removed once it's not in use any more.
    >
    > That's exactly what it hinges on. What is your criteria for
    > removing the old ESSID API. My understanding was 6 months.

    There is no reason why the old ESSID API cannot live on for years and
    years. Just like stat(2) version 1 doesn't support modern time
    granularity, old ESSID API won't support the full range of modern
    ESSIDs. So what? That's what a new API -- living alongside the old one
    -- is for.

    Jeff



    -
    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-10-04 21:15    [W:3.593 / U:0.620 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site