On Thursday 04 December 2008, Johannes Berg wrote:

On Tue, 2008-12-02 at 18:07 -0800, Inaky Perez-Gonzalez wrote:

quoted

For scanning, some devices require to be told exactly where to scan in
(as in which combination of band, fft width and coloring of the
band). Some others don't.

But things like these are fairly easy to cover, just allow netlink
attributes to specify where to scan, and allow drivers to disregard
them, no harm caused. Maybe include a capability bit, like I'm adding to
nl80211 in my scanning patch (not included yet) that includes a
capability for how many SSIDs it can scan actively at once.

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.

quoted

Then of course, the scan results might be
operators? Network Service Providers? Network Access Providers?  base
station IDs? how do you stitch'em together? You need information to
map from one to the other, and that is device specific depending on at
which level they work. How to stich that information together depends
on the network too (OMA-DM and provisining information help to compose
this). If it is done at the device/firmware level or at the host level
is device specific.

I have no idea about these things, obviously. But what's wrong with just
defining the scan operation with netlink attributes as you need them now
(say the scan returns NSPs) and then later when somebody needs to return
NAPs add a new attribute? Userspace will easily be able to figure out
which one it got by looking at which attributes are present.

Call me chicken :) [more below]

quoted

Connect has exactly the same levels of issues as scan: what do I
connect to? A base station? a NAP or an NSP?

So back to the original question: I have no information to define such
an interface at low level, so I am not defining it. Simple :/

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.

quoted

quoted

This really means you're putting the actual "driver", the piece that
does the hardware abstraction, into userspace. And in a binary daemon
even, afaict. This was quickly shot down with ipw3945/4965, not sure
why nobody has cared here so far. Maybe because you're actually
planning to open source that part.

Nope. I am putting the part that knows how to scan and connect in user
space because it does not belong in kernel space. It is big and complex,
needs permanent storage, requires complex crypto code and can really
use a OMA-DM client to communicate with the network.

Ok, I guess that makes sense then, I'm not aware of all the details.

quoted

Not a binary, btw. Currently the supplicant is a binary, but that will
change. The OMA-DM client daemon is also a binary as of now and we
are still thinking how to fix that situation, as there are no open
source equivalents. Luckily, it is kind of optional.

Ok, thanks for the explanation.

johannes

-- 
Inaky