Messages in this thread | | | Subject | Re: ipw3945 status | From | Kasper Sandberg <> | Date | Sun, 30 Jul 2006 17:00:54 +0200 |
| |
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/
| |