linux-kernel - Re: libertas (private) ioctls vs. nl80211

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181861758.23567.26.camel@xo-28-0B-88.localdomain>
Date:	Thu, 14 Jun 2007 18:55:58 -0400
From:	Dan Williams <dcbw@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	johannes@...solutions.net, linux-wireless@...r.kernel.org,
	hs4233@...l.mn-solutions.de, linux-kernel@...r.kernel.org
Subject: Re: libertas (private) ioctls vs. nl80211

On Thu, 2007-06-14 at 23:31 +0100, Christoph Hellwig wrote:
> On Thu, Jun 14, 2007 at 06:22:35PM -0400, Dan Williams wrote:
> > And that's what I did in the last pull you got from John; all pointless
> > and duplicated ioctls were removed.  The only ones left are mesh
> > tweakables, an LED GPIO control ioctl, and a regulatory region/domain
> > thing.  I agree the interface is somewhat ugly (like the
> > char-128/char-128 ones that return information from the mesh forwarding
> > table), and I also agree that we need to move to using netlink for this
> > sort of stuff in the future.  There are _no_ ioctls that duplicate WEXT
> > functionality.
> 
> The problem is not any kind of duplication.  The problem is that the
> interface is plain and simply bad.  If anyone else would come in with
> an ioctl interface using pointer indirections and subfunctions which
> is horribly complex and not 32on64 clean they would get beaten up.

I agree that it's suboptimal; I tried to clean it up and bashed my head
against the current iwpriv system for about 2 days before concluding
that the iwpriv stuff is just too insane to actually use.  We both want
a well-defined, clean, generic 802.11s-type interface, make no mistake.
Unfortunately, we don't have any framework which that interface could
use (ie, nl80211 or cfg80211).  That's unlikely to land until 2.6.23 or
even later.  And the regulatory stuff is still probably 6 months away
from agreement.

So if everybody is objecting to _any_ new private ioctls, even if they
don't duplicate WEXT functionality, whatever; rip them out and we'll
maintain them out-of-kernel or something until there's a nicer framework
to piggy-back the mesh tune-ables on.

Dan

> So even if the interface is not going to be generic it needs to be
> done properly and document.  And once it's documented you've actually
> layed down the first building block have it generic.  If no other
> driver actually implements the same kind of non-standardized mesh
> interface it'll stay that way, if other pop up they can implement
> the same interface and eventually we'll grow a generic layer helping
> out with it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/