[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1228432165.3970.2.camel@johannes.berg>
Date: Fri, 05 Dec 2008 00:09:24 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Inaky Perez-Gonzalez <inaky@...ux.intel.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 00/39] merge request for WiMAX kernel stack and i2400m
driver v2
On Thu, 2008-12-04 at 11:21 -0800, Inaky Perez-Gonzalez wrote:
> The implementation details are not the problem, there I totally agree
> with you. The problem is how to establish the cutline. What you are saying
> is exactly how I envision it to happen and the direction I'd like it to
> take, but I just don't want to do it until at least we have two vendors
> talking.
> > Here's where I disagree, obviously, I think you should at least define a
> > subset of the imaginable interface, which is, in my opinion, _much_
> > better than defining no interface at all and hoping for the next guy to
> > figure it out, which is unlikely to happen when you haven't started with
> > something the next guy can understand.
>
> No wait, I don't want guy #2 to define it--I want to work together to define
> it, to make sure it works for him and for me without having to throw to
> the garbage something I did on my own that won't work.
But, but, you have to throw away all your 'behind-the-private-call'
things anyway, at that point.
I think my point here really is that you're defining an API that's
intentionally private because you don't want to define a public one even
though that should be extensible enough. And then we get to the stuck
with the private API because all the userland uses it, and the next guy
will invariably implement it that way too, simply because you did and it
works that way and is much easier than getting it right (he'll just say
that because his is somewhat similar to yours he wants to wait for the
third implementation... ;) )
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists