lkml.org 
[lkml]   [2006]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ipw3945 status
From
Date
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/

\
 
 \ /
  Last update: 2006-07-30 17:03    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site