On Saturday 25 February 2006 03:41, Christoph Hellwig wrote:
>On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos wrote:
>> As a result of this change, some of the capabilities currently
>> required to be provided on the host include enforcement of
>> regulatory limits for the radio transmitter (radio calibration,
>> transmit power, valid channels, 802.11h, etc.) In order to meet the
>> requirements of all geographies into which our adapters ship (over
>> 100 countries) we have placed the regulatory enforcement logic into
>> a user space daemon that we provide as a binary under the same
>> license agreement as the microcode. We provide that binary
>> pre-compiled as both a 32-bit and
>
>the regualatory problems are not true. they are completely focused on
>the users. Someone who wants to change it can always do it, may it be
>by binary patching. I don't know of a single country that forbids
>implementing those bits in source code shipped, and in those countries
>we alredy couldn't distribute the kernel.
>
>A binary daemon is completely unacceptable and unless you fix that
> there is zero chance the driver could get into mainline. I'd also
> like to urge the distributors to not put this crap in to weaken our
> free drivers future. Intel, please stop this madness and play by the
> rules.
As someone (a broadcast engineer with 40+ years of carrying what used to
be a 1st phone) obviously more familiar with the FCC R&R than you
apparently are, Christoph, I'll have to argue that point. Intel has no
legal choice in the matter because the FCC had decreed that the stuff
to enforce the radiation limits either has to be in a custom made for
each country chip, or in binaries that check themselves for tampering
by secure crc, md5sum or similar methods. If the modules crc changes,
it must do an instant disable of the transmitter functions and exit or
crash, thereby precluding any 'hot rodding' of the chipset.
So basicly, you can accept it with the wrappers Intel provides, or linux
will not have access to the use of these devices, any of them that fit
in the category of "software radios". Intel et all has NO choice in
the matter in this country by FCC decree, and I believe its copycatted
by the Canadien DOC by treaty. Other locales may change the rules
slightly and often do, hence the requirement for manufacture of the
software radio, one thats totally controlled by the software issued for
that locale's use.
The fact that they are furnishing a wrapper, somewhat in the ndiswrapper
style, says that Intel would like a piece of this market, but with the
choice you are giving them with this arbitrary statement, they have no
choice but to quietly fold up their tents and go home. You are asking
Intel to break the laws designed to enforce the use of the 802-11 bands
in a legal manner.
So you might want to rethink your objections. I agree that it should
never become a piece of the kernel because it can't be audited, nor
even dissed without a DMCA prosecution, but we've been using nvidia's
stuff in modular fashion for quite some time, usually with decent
results. Its up to the user to install it of course, but thats
precisely the same scenario here with the Intel code. Intel will have
to put it someplace where the *user* can download it, meaning a server
setup someplace as opposed to handing the kernel developers one copy,
but thats the breaks as we've chosen to do it. Intel will also be
expected to supply a method of fileing bugs in case it doesn't work. A
publicly postable list that is actually supported for any and all bug
claims posted. Its an expense for intel of course but thats their
price of having a dog in this fight.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
