--0/kgSOzhNoDC5T3a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 02, 2006 at 08:12:15PM +0100, Iain Hibbert wrote:
> On Sat, 2 Sep 2006, Garrett D'Amore wrote:
>=20
> > Of course I would prefer to have _source_, but I also recognize there
> > are cases for binary blobs.  I believe ath(4) is one such case.
>=20
> What is the case for that, exactly?  I dont have any ath hardware, but as
> far as I am aware its to do with the restrictions that the manufacturers
> claim that the regulatory body in the USA places on them with regards to
> users being able to tweak the device beyond its regulated limits?

I don't think that the regulatory bodies in the US are the only ones that=
=20
do this, though they could well be the only ones that get mentioned.

And there are issues about what regulators really require, and what legal=
=20
departments require to ensure that there are no problems in the future.=20
And it could also be a convenient way to keep all of the discussion of the=
=20
hardware under NDA.

As an aside, I like the fact that ath() hardware documentation is=20
available to someone who can make blobs for everything that can use it.

> > My biggest complaint with blobs is lack of portability, but in at least
> > one case (ath(4)) the supplier has gone out of his way to make sure the
> > blob is available for any platform that might have the hardware.
>=20
> I have two complaints with blobs.
>=20
> a) The sys/contrib/dev/ath directory (eg) is 8Mb of uuencoded binary
> bloat, and every time another platform wants to add ath(4) support, more
> bloat ensues. How big is the source for a wireless device driver anyway?
> (as a reference, there seems to be 150k of wi(4) related source)

One difference between the two is that wi(4) has a microcontroller and=20
ath(4) doesn't. So the wi(4) code has a firmware for the microcontroller,=
=20
which obviously doesn't depend on the NetBSD architecture. aht(4) doesn't.=
=20
So everything that the microcontroller does is done by the host CPU. Thus=
=20
all of that functionality has to be handled by the host driver, and it's=20
larger and architecture-specific.

The up-shot is that I don't think a lines-of-code comparison is correct.

As to the size, I think one idea would be to gzip the blobs before=20
uuencoding.

> b) NetBSD is an open source operating system. While I dont think that we
> should be saying 'Hey, we wont deal with these evil blobs' I dont think
> they should be distributed as part of the source code.

For most things, I think it'd be ok to have the blob driver in pkgsrc. The=
=20
problem here is we're talking about the network drivers. Network installs=
=20
have always been very useful (I've done them a number of times). The=20
problem is that net nowadays often is wireless. So if we don't have=20
wireless drivers in the tree, it's hard to make install kernels that can=20
net install.

> > I totally disagree with any stance we take that prevents binary blobs
> > from being used with the operating system.  It will prevent NetBSD from
> > being used in a number of scenarios going forward.
>=20
> I think there is a correct place for these binary blobs, and that is to be
> brought in via a pkgsrc package when required.  That may be inconvenient,
> but maybe it would inspire somebody to make kernel modules beautiful for
> the rest of us :)

As above, my personal preference is that network drivers are a bit=20
special. :-)

Take care,

Bill

--0/kgSOzhNoDC5T3a
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFE/ci8Wz+3JHUci9cRAmQNAJ9sHY11Z62u7PbYawzOb2nBr03j+QCgiHOf
FyjirTC+jl89BcTCm4e1O6k=
=y9Jl
-----END PGP SIGNATURE-----

--0/kgSOzhNoDC5T3a--