wireless-2.6 status (25 January 2006)
All, This note is just to let you know what is going-on w/ the wireless-2.6 tree, now available here: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git You may have seen the pull requests I have sent to Jeff Garzik. I am actively merging patches for the code already in the upstream kernel. I then make them available for Jeff on the "upstream-jgarzik" branch, and I also pull from that branch into the "master" branch. The difference between those two branches is that I pull from Linus' kernel into the "master" branch as well, while I leave the "upstream-jgarzik" branch alone until Jeff gets it. I still have a number of other branches in the wireless-2.6 tree. I am using those branches to collect out of stream drivers and developments such as the softmac code and the alternative 802.11 stack from Devicescape. I have renamed the "softmac" and "dscape" branches as "softmac-all" and "dscape-all", mostly because I just liked those names better. I have redone the "dscape-upstream" and "dscape-all" branches to reflect Jiri's work in reforming his patches to allow the Devicescape stack to coexist with the existing stack in a single kernel tree. Finally, given that ieee80211+softmac and d80211 (aka Devicescape) can now live in the same tree, I have created a new "domesday" branch that includes all of the work from the other branches. This branch is not intended for upstream. Its purpose is to collect as much of the existing wireless work as possible in one place to ensure that we are all "on the same page" about what is available, how it works, etc. I think it is important to conduct this "Domesday census" to ensure we have all the information before making long-term 802.11-stack decisions (especially which one to use on a permanent basis). It is still a work in progress, as are some of the drivers I have included in the branch. It is certainly not for production use... For those who want to see the current state of things: git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git wireless-2.6 cd wireless-2.6 git checkout -f domesday If you plan to have an opinion about the wireless direction decisions coming "soon", I implore you to take a look at the code _now_. Thanks, John P.S. If you have patches for the code on the domesday branch but not yet upstream, I'll be happy to take those too... -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Hi John, On Wed, 25 Jan 2006, ext John W. Linville wrote: > I still have a number of other branches in the wireless-2.6 tree. > I am using those branches to collect out of stream drivers and > developments such as the softmac code and the alternative 802.11 > stack from Devicescape. I was wondering what's the reason for not having the madwifi stack there as well. I haven't seen anyone sending patches for it, but is that the only reason ? Cheers, Samuel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote: > On Wed, 25 Jan 2006, ext John W. Linville wrote: > > > I still have a number of other branches in the wireless-2.6 tree. > I was wondering what's the reason for not having the madwifi stack there > as well. I haven't seen anyone sending patches for it, but is that the > only reason ? Well, at least part of the answer is "I'm not done yet". I am still collecting code and figuring-out how to get it all into one tree. But, the main answer has to do with the intellectual property (i.e. copyright) issues concerning the HAL. My understanding is that the HAL currently used by the madwifi stack is not available under a license compatible with being included in the Linux kernel. Am I mistaken? I think it is very important to get a driver into the kernel which supports the Atheros hardware. At present, the driver from www.ath-driver.org seems the most promising. Although, some have expressed legal concerns about it as well. Anyone have any clarifying opinions about that driver? Are there any other options for supporting the Atheros hardware within the kernel? Thanks, John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
John W. Linville wrote: On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote: On Wed, 25 Jan 2006, ext John W. Linville wrote: I still have a number of other branches in the wireless-2.6 tree. I was wondering what's the reason for not having the madwifi stack there as well. I haven't seen anyone sending patches for it, but is that the only reason ? Well, at least part of the answer is "I'm not done yet". I am still collecting code and figuring-out how to get it all into one tree. But, the main answer has to do with the intellectual property (i.e. copyright) issues concerning the HAL. My understanding is that the HAL currently used by the madwifi stack is not available under a license compatible with being included in the Linux kernel. Am I mistaken? It appears to be the case. It might be technically possible to hack up madwifi as a module w/out the HAL and force end-users to download and install the HAL (and taint their kernel) to have a useful setup. That would go against much of what Linux stands for though, so I doubt it would be acceptable. If someone has a reverse-engineered HAL that might could be used as well. I think it is very important to get a driver into the kernel which supports the Atheros hardware. At present, the driver from www.ath-driver.org seems the most promising. Although, some have expressed legal concerns about it as well. Anyone have any clarifying opinions about that driver? Are there any other options for supporting the Atheros hardware within the kernel? None that I've found. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: > > It appears to be the case. It might be technically possible to > hack up madwifi as a module w/out the HAL and force end-users to > download and install the HAL (and taint their kernel) to have a useful > setup. That would go against much of what Linux stands for though, > so I doubt it would be acceptable. > If someone has a reverse-engineered HAL that might could > be used as well. I don't think that would fly based on past precedents. Leaving some kind of hook for the proprietary binary isn't allowed (see the PWC camera driver problems from a year or so back), and you can't have a module in the kernel that won't build unless you pull down another .o file to link against or whatever. What we have seen is permitted is a driver that requires a closed binary firmware to be loaded to operate (ipw2x00, prism54). I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. signature.asc Description: This is a digitally signed message part
Re: wireless-2.6 status (25 January 2006)
David Hollis wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: It appears to be the case. It might be technically possible to hack up madwifi as a module w/out the HAL and force end-users to download and install the HAL (and taint their kernel) to have a useful setup. That would go against much of what Linux stands for though, so I doubt it would be acceptable. If someone has a reverse-engineered HAL that might could be used as well. I don't think that would fly based on past precedents. Leaving some kind of hook for the proprietary binary isn't allowed (see the PWC camera driver problems from a year or so back), and you can't have a module in the kernel that won't build unless you pull down another .o file to link against or whatever. What we have seen is permitted is a driver that requires a closed binary firmware to be loaded to operate (ipw2x00, prism54). I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: > David Hollis wrote: > >I don't know the details of the Atheros chip to > >know if it might be possible to generate a firmware that users would > >have to install in /lib/firmware and let the driver load it up. If so, > >that would be the answer. > > The HAL is not real firmware..just normal kernel code. I wonder if you > could get around this by using a sort of CPU emulator and/or virtual machine > and load the HAL 'firmware' into that? Any chance the driver could be rearchitected w/ the HAL functionality moved into a userland helper? I haven't even looked at the driver to see if this could be practical...? -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
John W. Linville wrote: On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: David Hollis wrote: I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? Any chance the driver could be rearchitected w/ the HAL functionality moved into a userland helper? I haven't even looked at the driver to see if this could be practical...? It very well may be too time sensitive and it ends up fiddling with the NICs registers and such, which I'm not sure you can do through user-space. Might be worth asking some of the madwifi folks that know more though.. Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: > If someone has a reverse-engineered HAL that might could > be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). -- Greetings Michael. pgp14dkWxsSrf.pgp Description: PGP signature
Re: wireless-2.6 status (25 January 2006)
Michael Buesch wrote: On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: If someone has a reverse-engineered HAL that might could be used as well. From a quick look at the HAL asm code (mips-le), I think symbol names are obfuscated. So reverse engineering is Not Easy (tm). No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Friday 27 January 2006 00:10, you wrote: > Michael Buesch wrote: > > On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: > > > >>If someone has a reverse-engineered HAL that might could > >>be used as well. > > > > > > From a quick look at the HAL asm code (mips-le), I think > > symbol names are obfuscated. So reverse engineering > > is Not Easy (tm). > > No doubt. It also may be illegal (IANAL) to provide an open-source > HAL in the US due to FCC restrictions because it gives users > an easy way to screw up frequencies not legally available to > them. That seems to be the primary reason why it is binary-only > in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. -- Greetings Michael. pgpOQkcnDeRQl.pgp Description: PGP signature
Re: wireless-2.6 status (25 January 2006)
Michael Buesch wrote: On Friday 27 January 2006 00:10, you wrote: No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. I don't know. The bcm firmware may have a way to keep users from doing (very) wrong things, as evidently the intel wifi firmware does. It seems that the Atheros firmware is not smart enough to enforce enough restrictions. As to who could be found at fault..I'm not sure. But since all the rest of madwifi is open-source (and seems to get good support from Atheros), I can't really see why they'd close the HAL just for the hell of it. At any rate, any wisdom I might have on the matter was picked up from reading their FAQ..so you might want to just check that out directly. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Cum 27 Oca 2006 01:45 tarihinde, Michael Buesch şunları yazmıştı: > On Friday 27 January 2006 00:10, you wrote: > > Michael Buesch wrote: > > > On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: > > >>If someone has a reverse-engineered HAL that might could > > >>be used as well. > > > > > > From a quick look at the HAL asm code (mips-le), I think > > > symbol names are obfuscated. So reverse engineering > > > is Not Easy (tm). > > > > No doubt. It also may be illegal (IANAL) to provide an open-source > > HAL in the US due to FCC restrictions because it gives users > > an easy way to screw up frequencies not legally available to > > them. That seems to be the primary reason why it is binary-only > > in the first place. > > Uhm, So in your opinion the bcm43xx driver is illegal in the US, > because you can modify bcm43xx_radio_selectchannel() to tune > to illegal freqs? > I don't know the law, but I doubt that. > IMHO it is not the software, which does illegal things, but > the _user_, which tunes to these freqs. Well with a simple analogy, selling knife is illegal too, so you can go and kill someone with that knife... /ismail - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless-2.6 status (25 January 2006)
In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Buesch Sent: Thursday, January 26, 2006 3:46 PM To: Ben Greear Cc: David Hollis; John W. Linville; Samuel Ortiz; netdev@vger.kernel.org Subject: Re: wireless-2.6 status (25 January 2006) On Friday 27 January 2006 00:10, you wrote: > Michael Buesch wrote: > > On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote: > > > >>If someone has a reverse-engineered HAL that might could be used as > >>well. > > > > > > From a quick look at the HAL asm code (mips-le), I think symbol > > names are obfuscated. So reverse engineering is Not Easy (tm). > > No doubt. It also may be illegal (IANAL) to provide an open-source > HAL in the US due to FCC restrictions because it gives users an easy > way to screw up frequencies not legally available to them. That seems > to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Friday 27 January 2006 01:04, you wrote: > In order to get FCC certification the manufacturer must ensure there is > no easy way for the user to tune to illegal frequencies. Broadcom has > done their job - it was not easy to reverse engineer their driver. Now > the cat is out of the bag. The open source driver is not illegal - > although it may be illegal to use it - since the chipset and driver were > likely certified together. I'm no expert in FCC regulation, so take all > of this with a pinch of salt. Ah, I see your point. I remember something like the following from the old 2.4 days (no idea if it still applies to the 2.6 drivers). An MD5 checksum of the lowlevel HiSax ISDN drivers was certified. So if you modify the source (which is allowed by the GPL), you would loose certification. -- Greetings Michael. pgpFcQO1Obgsg.pgp Description: PGP signature
Re: wireless-2.6 status (25 January 2006)
John W. Linville wrote: On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: David Hollis wrote: I don't know the details of the Atheros chip to know if it might be possible to generate a firmware that users would have to install in /lib/firmware and let the driver load it up. If so, that would be the answer. The HAL is not real firmware..just normal kernel code. I wonder if you could get around this by using a sort of CPU emulator and/or virtual machine and load the HAL 'firmware' into that? Any chance the driver could be rearchitected w/ the HAL functionality moved into a userland helper? I haven't even looked at the driver to see if this could be practical...? OpenBSD has an open source HAL, IIRC. You could use that as reference, if nothing else. There are apparently several variant of the chip, making some level of abstraction useful in this case, not just for hiding hardware details. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Ben Greear wrote: Michael Buesch wrote: On Friday 27 January 2006 00:10, you wrote: No doubt. It also may be illegal (IANAL) to provide an open-source HAL in the US due to FCC restrictions because it gives users an easy way to screw up frequencies not legally available to them. That seems to be the primary reason why it is binary-only in the first place. Uhm, So in your opinion the bcm43xx driver is illegal in the US, because you can modify bcm43xx_radio_selectchannel() to tune to illegal freqs? I don't know the law, but I doubt that. IMHO it is not the software, which does illegal things, but the _user_, which tunes to these freqs. I don't know. The bcm firmware may have a way to keep users from doing (very) wrong things, as evidently the intel wifi firmware does. It seems that the Atheros firmware is not smart enough to enforce enough restrictions. As to who could be found at fault..I'm not sure. But since all the rest of madwifi is open-source (and seems to get good support from Atheros), I can't really see why they'd close the HAL just for the hell of it. This issue will come up again and again. Linux needs to provide functionality a la ieee80211_geo, whereby you can choose from acceptable frequencies for your location. As Alan Cox has pointed out, this may be a /etc setting, something that may be overridden by the AP. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
Hello John, Samuel, > Well, at least part of the answer is "I'm not done yet". I am still > collecting code and figuring-out how to get it all into one tree. > > But, the main answer has to do with the intellectual property > (i.e. copyright) issues concerning the HAL. My understanding is > that the HAL currently used by the madwifi stack is not available > under a license compatible with being included in the Linux kernel. > Am I mistaken? I think that Samuel's question had more to do with having the madwifi stack in your branch, rather than the driver proper. From having used it for the prism54-softmac project, the madwifi stack really can be used stand-alone, without any reference to the HAL. > I think it is very important to get a driver into the kernel > which supports the Atheros hardware. At present, the driver from > www.ath-driver.org seems the most promising. Although, some have > expressed legal concerns about it as well. Anyone have any clarifying > opinions about that driver? No opinion about ath-driver.org. But OpenBSD has an open-source HAL, which is meant to be a drop-in replacement for the closed-source HAL. This could be used at least as a basis for a clean-room implementation, which would clear all legal concerns. Code can be found on: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/ See ar files. As far as reverse-engeneering is concerned : The problem of the atheros HAL is that is does the transport of data to the card itself (DMA, register writes). Compare this with Connexant's 'umac' designs, where the binary code is transport-independent, and the transport is done by open-source code. With the HAL, you cannot intercept data going in and out of the binary-only part, leaving only decompiling as an option for reverse-engeneering. And it prevents moving this part to userland, as someone already said. > Are there any other options for supporting the Atheros hardware within > the kernel? This should be fairly easy, it seems, to completely rewrite a driver based on the above info. All the data's available in C, at least for the older chipsets - don't really know about newer ones. If only I had time for this :) Jean-Baptiste - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: wireless-2.6 status (25 January 2006)
On Thu, 26 Jan 2006, ext Simon Barber wrote: > In order to get FCC certification the manufacturer must ensure there is > no easy way for the user to tune to illegal frequencies. FCC verifies that a product running a certain software follows FCC rules in terms of frequencies, power level, signal bandwidth, etc... It doesn't check (and I don't see how it could check it) how difficult it is for a user to get out of range. > Broadcom has > done their job - it was not easy to reverse engineer their driver. I really doubt Broadcom made it difficult to reverse engineer their driver just to prevent users from breaking FCC rules. Cheers, Samuel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Thu, Jan 26, 2006 at 03:04:22PM -0500, John W. Linville wrote: > On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote: > > David Hollis wrote: > > > >I don't know the details of the Atheros chip to > > >know if it might be possible to generate a firmware that users would > > >have to install in /lib/firmware and let the driver load it up. If so, > > >that would be the answer. > > > > The HAL is not real firmware..just normal kernel code. I wonder if you > > could get around this by using a sort of CPU emulator and/or virtual machine > > and load the HAL 'firmware' into that? > > > > Any chance the driver could be rearchitected w/ the HAL functionality > moved into a userland helper? I haven't even looked at the driver > to see if this could be practical...? Folks, please stop these stupid ideas. There's a free driver, let's improve and merge it. That's a thousand times better than any half-free driver with buggy binary blobs. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Fri, Jan 27, 2006 at 09:17:50AM +, Christoph Hellwig wrote: > Folks, please stop these stupid ideas. There's a free driver, let's improve > and merge it. That's a thousand times better than any half-free driver > with buggy binary blobs. I presume you mean the ath-driver.org stuff? I'm perfectly open to using that code, but some had raised issues about the reverse-engineering process used to create it. Has that been resolved? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6 status (25 January 2006)
On Fri, Jan 27, 2006 at 07:33:05AM -0500, John W. Linville wrote: > On Fri, Jan 27, 2006 at 09:17:50AM +, Christoph Hellwig wrote: > > > Folks, please stop these stupid ideas. There's a free driver, let's improve > > and merge it. That's a thousand times better than any half-free driver > > with buggy binary blobs. > > I presume you mean the ath-driver.org stuff? I'm perfectly > open to using that code, but some had raised issues about the > reverse-engineering process used to create it. Has that been resolved? It is unclear. I'm in contact with lawyers from the institute for low and open source software here in Germany, who conducted an analysis on reverse engineering. The result of their analysis leaves more open questions than it answers. The first problem is that there appears to be no precedent whatsoever on the reverse engineering interoperability exceptions. Also, the wording of those exceptions seem to assume software/software interoperability, not software/hardware. Furthermore, the .de implementation on the EU directive on 'reverse engineering' explicitly states 'decompilation' is forbidden. Technically speaking, that's different from disassembly. But what would a court rule? Also, the interoperability exceptions seem to be written with closed-source software in mind, since the result of such conditionally allowed re-engineering is not allowed to be published. So for now, I personally would ignore the concerns. Please tell me how many Linux device drivers we would have, if nobody had ever looked into some disassembled proprietary driver? Don't get me wrong, I'm very much against any kind of 'carbon copying' code from a proprietary driver into a free one. However, merely looking at existing proprietary code in order to figure out which bit of a register resembles what function, and then implementing a driver from scratch using that information seems pretty safe to me. Actually, running the proprietary code in a simulator and just looking at the inputs/outputs of that simulator seems to be the safest way. Also, who will be able to prove that you actually looked at some assembly instructions rather than observing the proprietary program running in a simulator? -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) pgpY8sDn6yEHs.pgp Description: PGP signature
wireless geo stuff (was Re: wireless-2.6 status (25 January 2006))
Simon Barber wrote: In order to get FCC certification the manufacturer must ensure there is no easy way for the user to tune to illegal frequencies. Broadcom has done their job - it was not easy to reverse engineer their driver. Now the cat is out of the bag. The open source driver is not illegal - although it may be illegal to use it - since the chipset and driver were likely certified together. I'm no expert in FCC regulation, so take all of this with a pinch of salt. First, kernel developers should do the best they can to provide facilities to limit the frequencies, including sane and safe defaults for the softmac cases. It just makes sense to do that, from a "friendly neighbor" and "don't operate out of spec" perspective, if nothing else. It's damned _rude_ to use channels other than the ones selected by the Responsible Authority. Some ham radio operator -- like me -- might be using that frequency to carry on a pleasant Morse code conversation with someone else halfway across the world. Linux software shalt not be rude. :) Second, if someone takes steps to disable these safeguards we build in, that's akin to putting illegal crystals into a radio, or tuning a transmitter to police/emergency bands. Finally, binary-only software is clearly _not_ a barrier to this sort of circumvention. Reverse engineering x86 software is a skill that's very widespread, relative to other sorts of reverse engineering. Reverse engineering tools for the x86 are very mature these days, having had two decades to grow and flourish. If the _hardware_ can be programmed maliciously, there's not a whole lot you can do about it... particularly when the hardware manufacturer chooses a method of obfuscation (x86 code) practically designed for easy analysis. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
