--k+w/mQv8wyuph6w0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 22, 2006 at 11:38:50AM +0100, Ricardo Correia Pinto wrote:
=20
> 	While catching up with the latest changes, I've noticed
> wpa_supplicant's BSD driver already implements scanning using the ioctl's
> I mention in the PDF (It's also mentioned in tech-kern by rpaulo). It also
> has a control interface wich can be used to trigger scans, and perform
> some wpa-related tasks.
>=20
> 	This raises a question: reinvent the wheel by implementing the
> scanning functions of wpa_supplicant or use the functions offered by it?

While I definitely agree that code reuse is a Good Thing, let me play
devil's advocate for a second..

There are two approaches (presumably) to using wpa_supplicant: copying
their scanning code over into this project; or interfacing with the
wpa_supplicant daemon.  There might be some problems with both of these.

Since wpa_supplicant is licensed under the GPL, importing their source
would require this project to be licensed under the GPL.  I don't know
if this is desirable.

If there is a way to interface with the daemon, this would not force
these licensing constraints.  However, it would require all users to run
this extra daemon, whether they are using WPA or not.  The
wpa_supplicant page [1] indicates support isn't global across chipsets
and drivers.  Of course, it may not be possible to support all chipsets,
but I would assume we'd want to go with the broadest coverage possible.

 [1] http://hostap.epitest.fi/wpa_supplicant/

--=20
boom shanka,
  .oliver

--k+w/mQv8wyuph6w0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (NetBSD)

iD8DBQFESkogNtBooygWxWcRAkJbAJsENBftszKUUC4cmDU+WTn8XBB0KQCg1TXr
I6dF12yGKG7PVDo1w4xDJ8Q=
=1SQu
-----END PGP SIGNATURE-----

--k+w/mQv8wyuph6w0--