ipw3945 status

ipw3945 status

[Pavel Machek]

Hi!

I'm unfortunate enough to have x60 with ipw card. Card works okay, but
driver is 16K LoC and needs binary daemon (ugh). Plus, it lives as an
external module...

Are there any plans to merge it into mainline? Is there any way I
could help?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ipw3945 status

[Matthew Garrett]

On Sun, Jul 30, 2006 at 12:40:42PM +0200, Pavel Machek wrote:

> I'm unfortunate enough to have x60 with ipw card. Card works okay, but
> driver is 16K LoC and needs binary daemon (ugh). Plus, it lives as an
> external module...

I have a mostly working replacement for the binary daemon, but it causes 
the firmware to crash at the point where it triggers an association. If 
anyone's keen on trying to figure out what's up, I'll clean up the code 
and stick it somewhere.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ipw3945 status

[Pavel Machek]

Hi!

> > I'm unfortunate enough to have x60 with ipw card. Card works okay, but
> > driver is 16K LoC and needs binary daemon (ugh). Plus, it lives as an
> > external module...
> 
> I have a mostly working replacement for the binary daemon, but it causes 
> the firmware to crash at the point where it triggers an association. If 
> anyone's keen on trying to figure out what's up, I'll clean up the code 
> and stick it somewhere.

I can't promise anything, but yes, seeing that code would be great.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ipw3945 status

[Jan Dittmer]

Matthew Garrett schrieb:
> On Sun, Jul 30, 2006 at 12:40:42PM +0200, Pavel Machek wrote:
> 
> 
>>I'm unfortunate enough to have x60 with ipw card. Card works okay, but
>>driver is 16K LoC and needs binary daemon (ugh). Plus, it lives as an
>>external module...
> 
> 
> I have a mostly working replacement for the binary daemon, but it causes 
> the firmware to crash at the point where it triggers an association. If 
> anyone's keen on trying to figure out what's up, I'll clean up the code 
> and stick it somewhere.

Why not get rid of the daemon like bsd did [0]? Otherwise in
5 years you'll have 42 daemons running which communicate with
the firmware of various devices, each having a different inter-
face.

Jan

[0] http://kerneltrap.org/node/6650

Re: ipw3945 status

[Matthew Garrett]

On Sun, Jul 30, 2006 at 01:34:19PM +0200, Jan Dittmer wrote:

> Why not get rid of the daemon like bsd did [0]? Otherwise in
> 5 years you'll have 42 daemons running which communicate with
> the firmware of various devices, each having a different inter-
> face.

Because it would involve a moderate rewriting of the driver, and we'd 
have to carry a delta against Intel's code forever.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ipw3945 status

[Kasper Sandberg]

On Sun, 2006-07-30 at 12:47 +0100, Matthew Garrett wrote:
> On Sun, Jul 30, 2006 at 01:34:19PM +0200, Jan Dittmer wrote:
> 
> > Why not get rid of the daemon like bsd did [0]? Otherwise in
> > 5 years you'll have 42 daemons running which communicate with
> > the firmware of various devices, each having a different inter-
> > face.
> 
> 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.
> 

Re: ipw3945 status

[Theodore Tso]

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.

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
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

Re: ipw3945 status

[Kasper Sandberg]

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
> 

Re: ipw3945 status

[Theodore Tso]

On Sun, Jul 30, 2006 at 05:00:54PM +0200, Kasper Sandberg wrote:
> 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.

Um, last time I checked we could still run some *minix* binaries from
before Linux was born, and we still can run statically linked a.out
programs created over a decade ago.  I don't think this is a serious
objection, given that historically the Linux kernel/userspace syscall
interface has been quite stable.  

Of course, I'd recomend against said driver using sysfs, but Greg K-H
tells us that all breakagaes are the fault of buggy device drivers
(just as supposedly all swsuspend problems are also about buggy device
drivers), so I guess we're OK.  :-)

							- Ted

Re: ipw3945 status

[Tomasz Torcz]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Sun, Jul 30, 2006 at 12:28:27PM +0100, Matthew Garrett wrote:
> On Sun, Jul 30, 2006 at 12:40:42PM +0200, Pavel Machek wrote:
> 
> > I'm unfortunate enough to have x60 with ipw card. Card works okay, but
> > driver is 16K LoC and needs binary daemon (ugh). Plus, it lives as an
> > external module...
> 
> I have a mostly working replacement for the binary daemon, but it causes 
> the firmware to crash at the point where it triggers an association. If 
> anyone's keen on trying to figure out what's up, I'll clean up the code 
> and stick it somewhere.

  Is your daemon somehow releated to wifi frequencies goegraphy database
proposed some time ago on netdev?

-- 
Tomasz Torcz                 "God, root, what's the difference?"
zdzichu@irc.-nie.spam-.pl         "God is more forgiving."


[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: ipw3945 status

[Matthew Garrett]

On Sun, Jul 30, 2006 at 05:57:34PM +0200, Tomasz Torcz wrote:

>   Is your daemon somehow releated to wifi frequencies goegraphy database
> proposed some time ago on netdev?

No. So far, I haven't implemented that at all.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ipw3945 status

[Kasper Sandberg]

On Sun, 2006-07-30 at 11:09 -0400, Theodore Tso wrote:
> On Sun, Jul 30, 2006 at 05:00:54PM +0200, Kasper Sandberg wrote:
> > 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.
> 
> Um, last time I checked we could still run some *minix* binaries from
> before Linux was born, and we still can run statically linked a.out
> programs created over a decade ago.  I don't think this is a serious
> objection, given that historically the Linux kernel/userspace syscall
> interface has been quite stable. 
thats besides the point, i was arguing the difference between loading a
firmware image and running a binary daemon.
> 
> Of course, I'd recomend against said driver using sysfs, but Greg K-H
> tells us that all breakagaes are the fault of buggy device drivers
> (just as supposedly all swsuspend problems are also about buggy device
> drivers), so I guess we're OK.  :-)
> 
> 							- Ted
> 

Re: ipw3945 status

[Jan Dittmer]

Theodore Tso schrieb:
> Personally, I don't see why the requirement of an external daemon is
> really considered that evil.  We allow drivers that depend on firmware

Well the problem is more the fear that when one vendor gets this in
the tree all others will follow. And there'll be several
incompatible userspace daemons for every possible wireless card which
you need to get the system to work (think boot cd, install over wlan).

So if this is done, there should be a clearly abstracted interface
for such a daemon. I don't see what the daemon is doing more than
echo 1 4 7 8 > /sys/.../allowed_channels and a control circuit for
tx/rx power.

> loaders, don't we?  I could imagine a device that required a digitally
> 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?

If it's done via a standard interface as the firmware loading
is, no objection.

Jan

Re: ipw3945 status

[Matthew Garrett]

On Sun, Jul 30, 2006 at 06:25:34PM +0200, Jan Dittmer wrote:

> So if this is done, there should be a clearly abstracted interface
> for such a daemon. I don't see what the daemon is doing more than
> echo 1 4 7 8 > /sys/.../allowed_channels and a control circuit for
> tx/rx power.

The daemon sets the list of acceptable channels, the transmission powers 
for each of them and modifies this based on things like the temperature.

Oh, yes, and it writes 802.11 scan frames that get passed straight to 
the firmware and broadcast. Insane crack. For reasons I don't as yet 
understand, various received frames also get passed back up to the 
daemon. I probably really don't want to know why.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: ipw3945 status

[James Courtier-Dutton]

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.
> 

Where can I find this FCC law that seems to be crippling open source 
wlan development?

I am not from the USA, so I don't have to comply with the FCC. Could we 
make a non-crippled totally open source driver for use by people outside 
the USA?

For example, here in the UK one can own radios that can transmit on any 
frequency one likes, but if you actually press the TX button without a 
the appropriate License, you break the law.

James

Re: ipw3945 status

[Kasper Sandberg]

On Sun, 2006-07-30 at 17:58 +0100, James Courtier-Dutton wrote:
> 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.
> > 
> 
> Where can I find this FCC law that seems to be crippling open source 
> wlan development?
> 
> I am not from the USA, so I don't have to comply with the FCC. Could we 
> make a non-crippled totally open source driver for use by people outside 
> the USA?
as with encryption, arent some of the encryption stuff widely used in
the opensource community also illegal in the united states?

> 
> For example, here in the UK one can own radios that can transmit on any 
> frequency one likes, but if you actually press the TX button without a 
> the appropriate License, you break the law.
im quite certain this is also the case in for example Denmark.
> 
> James
> 

Re: ipw3945 status

[Rene Rebe]

Hi,

it would be totally ok if the kernel had a country= command line switch
and the driver limitting functionality due that.

People that want to violate the local regulations would require to lie to
the kernel as they could install other country windows and drivers as
well.

Sure, people could modify the source as they could specify a wrong
country argument. But you can heedit the windows binary as well.

Yours,

-- 
  René Rebe - ExactCODE - Berlin (Europe / Germany)
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
  +49 (0)30 / 255 897 45

Re: ipw3945 status

[Alan Cox]

Ar Sul, 2006-07-30 am 10:53 -0400, ysgrifennodd Theodore Tso:
> Personally, I don't see why the requirement of an external daemon is
> really considered that evil.  We allow drivers that depend on firmware

An open source daemon doing the supervising seems fine. We do that for
IPv4 even (dhcpd, dhcpcd, routed, gated, zebra, ....) ;)

> loaders, don't we?  I could imagine a device that required a digitally
> 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?

If it controls the use of the device inappropriately then yes we should.
Suppose it passes down an RSA signed message that is computed by
verifying you are running a Red Hat Enterprise Linux 4 official shipped
kernel on an approved IBM platform and things like that - that would
annoy me.

Using GPG keys to verify code matches approved code is fine. The ISDN
layer has done this for many years and if its not the signed code
version it didn't have the old silly approvals stuff (Fortunately
nowdays even politicians have realised that if you need approval for
something to stop it doing bad stuff to the phone network then bad
people can do bad stuff anyway and this is bad for national security)

I think from a vendor perspective being able to ship a source set for
such a daemon which Intel has signed as "this source meets the rules" is
great. As an end user I want the flexibility to do other stuff except
where prohibited by law (not by Intel, not by paranoid lawyers and not
by FCC lack of clarity)

I also want to violate the power and other policy rules Intel wishes to
enforce on their hardware for legal and legitimate reasons. As a radio
amateur I am permitted in law to transmit certain classes of signals in
that frequency space at higher power than in the hands of a random UK
user of license exempt technology.

Alan

Re: ipw3945 status

[Kasper Sandberg]

On Sun, 2006-07-30 at 19:37 +0200, Rene Rebe wrote:
> Hi,
> 
> it would be totally ok if the kernel had a country= command line switch
> and the driver limitting functionality due that.
or simply state this in the help in Kconfig?
> 
> People that want to violate the local regulations would require to lie to
> the kernel as they could install other country windows and drivers as
> well.
besides, im not even sure that specifying in Kconfig is necessary,
wouldnt it only be illegal in countries, if people actually modified the
source?
> 
> Sure, people could modify the source as they could specify a wrong
> country argument. But you can heedit the windows binary as well.
> 
> Yours,
> 

Re: ipw3945 status

[Rene Rebe]

HI,

On Sunday 30 July 2006 20:03, Kasper Sandberg wrote:

> > it would be totally ok if the kernel had a country= command line switch
> > and the driver limitting functionality due that.
> or simply state this in the help in Kconfig?
> > 
> > People that want to violate the local regulations would require to lie to
> > the kernel as they could install other country windows and drivers as
> > well.
> besides, im not even sure that specifying in Kconfig is necessary,
> wouldnt it only be illegal in countries, if people actually modified the
> source?

I proposed a kernel command so distributors have a way to run-time
change this.

However now that I think about it a bit more, a simple sysfs attribute
would be way more useful so the gui tool of the the distribution can
switch the country immediatly and do not require a windows-al-like reboot.

Yours,

-- 
  René Rebe - ExactCODE - Berlin (Europe / Germany)
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
  +49 (0)30 / 255 897 45

Re: ipw3945 status

[Kasper Sandberg]

On Sun, 2006-07-30 at 22:09 +0200, Rene Rebe wrote:
> HI,
> 
> On Sunday 30 July 2006 20:03, Kasper Sandberg wrote:
> 
> > > it would be totally ok if the kernel had a country= command line switch
> > > and the driver limitting functionality due that.
> > or simply state this in the help in Kconfig?
> > > 
> > > People that want to violate the local regulations would require to lie to
> > > the kernel as they could install other country windows and drivers as
> > > well.
> > besides, im not even sure that specifying in Kconfig is necessary,
> > wouldnt it only be illegal in countries, if people actually modified the
> > source?
> 
> I proposed a kernel command so distributors have a way to run-time
> change this.
> 
> However now that I think about it a bit more, a simple sysfs attribute
> would be way more useful so the gui tool of the the distribution can
> switch the country immediatly and do not require a windows-al-like reboot.
> 
or perhaps people should just not install/use stuff illegal in their
country.

> Yours,
> 

Re: ipw3945 status

[Pavel Machek]

Hi!

> > > 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.
> 
> 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

Well, drivers that depend on external, non-redistributable firmware
(aka ipw2200/ipw2100) already are evil, but at least I do not run
untrusted code on my CPU. (And yes, firmware in ipw2200 crashes a
_lot_).

Plus, that regulatory daemon probably contains security hole (or two)
inside, and I can't properly audit it. (Yes, firmware in ipw2200
probably contains security holes, too, but at least those are more
"interesting" to exploit).

And... Intel will not even tell you WTF that daemon does. They claim
it is for FCC, but it seems to be doing more than that. So maybe I'm
not _that_ paranoid.

(Of course, binary-only kernel module would be even uglier).

Ouch and binary-only daemon will conviently prevent me from using that
wireless card in ppc machine.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: ipw3945 status

[Alan Cox]

Ar Sul, 2006-07-30 am 23:02 +0200, ysgrifennodd Kasper Sandberg:
> or perhaps people should just not install/use stuff illegal in their
> country.

Most users really don't understand the issues around wireless and
country specific rules. Some wireless implementations also don't deal
with moving between countries live (as happens all the time today in
Europe).

That means as a distribution vendor its really important to ship people
something that by default does the right thing and the legal thing here.
If people want to recompile kernels or hack firmware thats their
business, but out of the box it should behave.

Re: ipw3945 status

[Kasper Sandberg]

On Mon, 2006-07-31 at 00:44 +0100, Alan Cox wrote:
> Ar Sul, 2006-07-30 am 23:02 +0200, ysgrifennodd Kasper Sandberg:
> > or perhaps people should just not install/use stuff illegal in their
> > country.
> 
> Most users really don't understand the issues around wireless and
> country specific rules. Some wireless implementations also don't deal
> with moving between countries live (as happens all the time today in
> Europe).
> 
> That means as a distribution vendor its really important to ship people
> something that by default does the right thing and the legal thing here.
> If people want to recompile kernels or hack firmware thats their
> business, but out of the box it should behave.
as it will never do properly requiring a binary daemon, distributions
are having a hard enough time to try and redistribute those firmwares
where its legal, some even wont, but a userspace daemon is out of the
question for most.
> 
> 

Re: ipw3945 status

[Alistair John Strachan]

On Monday 31 July 2006 00:12, Pavel Machek wrote:
[snip]
> And... Intel will not even tell you WTF that daemon does. They claim
> it is for FCC, but it seems to be doing more than that. So maybe I'm
> not _that_ paranoid.

Agreed, from what Matthew's said it seems like the daemon is being used to 
hide intellectual property, not something we should really be encouraging.

I think the title "regulatory daemon" has multiple meanings, it REGULATES your 
frequencies to FCC specs, it REGULATES your wireless card's power and 
temperature levels, and it REGULATES your right to use the hardware ;-)

Ultimately the question remains, will we open this can of worms by accepting 
drivers that depend on proprietary software (i.e. they will not function at 
all without it). I'm fairly sure the answer should be "No".

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: ipw3945 status

[Kasper Sandberg]

On Mon, 2006-07-31 at 01:23 +0100, Alistair John Strachan wrote:
> On Monday 31 July 2006 00:12, Pavel Machek wrote:
> [snip]
> > And... Intel will not even tell you WTF that daemon does. They claim
> > it is for FCC, but it seems to be doing more than that. So maybe I'm
> > not _that_ paranoid.
> 
> Agreed, from what Matthew's said it seems like the daemon is being used to 
> hide intellectual property, not something we should really be encouraging.
> 
> I think the title "regulatory daemon" has multiple meanings, it REGULATES your 
> frequencies to FCC specs, it REGULATES your wireless card's power and 
> temperature levels, and it REGULATES your right to use the hardware ;-)
> 
> Ultimately the question remains, will we open this can of worms by accepting 
> drivers that depend on proprietary software (i.e. they will not function at 
> all without it). I'm fairly sure the answer should be "No".
I entirely agree that this should not be merged, those will accept these
kindof things, can use intels out of tree driver.

i sincerely hope for a forked/rewritten driver which does not depend on
closed userspace daemons.
> 

Re: ipw3945 status

[Alon Bar-Lev]

On 7/31/06, Kasper Sandberg <lkml@metanurb.dk> wrote:
> I entirely agree that this should not be merged, those will accept these
> kindof things, can use intels out of tree driver.
>
> i sincerely hope for a forked/rewritten driver which does not depend on
> closed userspace daemons.

I personally think that this also violates the GPL license...
The GPL part cannot stand by it-self and require none GPLed component
in order to make it work.

The fact that the regularity daemon work using external sysfs
interface without linkage requirements does not escape derived work in
this case.

Best Regards,
Alon Bar-Lev

Re: ipw3945 status

[Rene Rebe]

Hi,

On Monday 31 July 2006 02:19, Kasper Sandberg wrote:
> On Mon, 2006-07-31 at 00:44 +0100, Alan Cox wrote:
> > Ar Sul, 2006-07-30 am 23:02 +0200, ysgrifennodd Kasper Sandberg:
> > > or perhaps people should just not install/use stuff illegal in their
> > > country.
> > 
> > Most users really don't understand the issues around wireless and
> > country specific rules. Some wireless implementations also don't deal
> > with moving between countries live (as happens all the time today in
> > Europe).
> > 
> > That means as a distribution vendor its really important to ship people
> > something that by default does the right thing and the legal thing here.
> > If people want to recompile kernels or hack firmware thats their
> > business, but out of the box it should behave.
> as it will never do properly requiring a binary daemon, distributions
> are having a hard enough time to try and redistribute those firmwares
> where its legal, some even wont, but a userspace daemon is out of the
> question for most.

Sure not. That is why I wanted to direct the discussion in what country
enforcing scheme we should go.

-- 
  René Rebe - ExactCODE - Berlin (Europe / Germany)
  http://exactcode.de | http://t2-project.org | http://rene.rebe.name
  +49 (0)30 / 255 897 45

Re: ipw3945 status

[Kasper Sandberg]

On Mon, 2006-07-31 at 09:06 +0300, Alon Bar-Lev wrote:
> On 7/31/06, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > I entirely agree that this should not be merged, those will accept these
> > kindof things, can use intels out of tree driver.
> >
> > i sincerely hope for a forked/rewritten driver which does not depend on
> > closed userspace daemons.
> 
> I personally think that this also violates the GPL license...
> The GPL part cannot stand by it-self and require none GPLed component
> in order to make it work.
> 
> The fact that the regularity daemon work using external sysfs
> interface without linkage requirements does not escape derived work in
> this case.
i tend to agree, however if a generic interface was created for
"regulatory daemons" this may be different, but if what i hear is true,
the intel daemon does more than that, and then, well...

> 
> Best Regards,
> Alon Bar-Lev
> -
> 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/
>