lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ