Subject: Re: ZFS
To: Iain Hibbert <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/05/2006 11:58:04
Content-Type: text/plain; charset=us-ascii
On Sat, Sep 02, 2006 at 08:12:15PM +0100, Iain Hibbert wrote:
> On Sat, 2 Sep 2006, Garrett D'Amore wrote:
> > 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.
> 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=
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=
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=
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.
> I have two complaints with blobs.
> 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,=
which obviously doesn't depend on the NetBSD architecture. aht(4) doesn't.=
So everything that the microcontroller does is done by the host CPU. Thus=
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
> 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=
problem here is we're talking about the network drivers. Network installs=
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
> > 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.
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----