Re: ipw3945 status

[Kasper Sandberg <lkml@metanurb.dk>]

On Sun, 2006-07-30 at 10:53 -0400, Theodore Tso wrote:
> On Sun, Jul 30, 2006 at 03:01:17PM +0200, Kasper Sandberg wrote:
> > > Because it would involve a moderate rewriting of the driver, and we'd 
> > > have to carry a delta against Intel's code forever.
> >
> > without knowing this for sure, dont you think that if a largely changed
> > version of the driver appeared in the tree, intel may start developing
> > on that? cause then they wouldnt be the ones that "broke" compliance
> > with FCC(hah) by not doing binaryonly.
> 
> It's just as likely that their lawyers would tell them that they would
> have to pretend that the modifications don't exist at all, and not
> release any changes for any driver (like OpenBSD's) that bypassed the
> regulatory daemon.  The bigger worry would be if they decided that
> they couldn't risk supporting their current out-of-tree driver, and
> couldn't release Linux drivers for their softmac wireless devices in
> the future.
i think, that if no driver exists, there would be further incentive for
people to reverse engineer, as i also believe that if nvidia didnt
release their closed driver, there would be a project that would have
created a working driver for it(also supporting 3d)
> 
> Personally, I don't see why the requirement of an external daemon is
> really considered that evil.  We allow drivers that depend on firmware
> loaders, don't we?  I could imagine a device that required a digitally
thats entirely different, if some firmware image is loaded into a card,
thats that, but running a userspace daemon is just entirely different,
what would happen if intel for some reason stopped supporting earlier
cards(as hardware manufactureres do after some time), and linux
kernel/userspace gets some change, preventing the binary daemon from
running? then what? we have lost. but i do not believe any change can
really be made, that would mean the existing binary firmware images
could not be loaded into the hardware.
> signed message (using RSA) with a challenge/response protocol embedded
> inside that was necessary to configure said device, which is
> calculated in userspace and then passed down into the kernel to be
> installed into the device so that it could function.  Do we really
> want to consider that to be objectionable?
> 
> 						- Ted
> 

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