atheros driver - desc
Subsystems (2)
Hi list members,
I just post the code for review for anyone interested.
I would be more than pleased to hear some feedback from you on the code.
Im sending a series of 8 patches splitted and diffed as in SubmittingPatches documentation.
The driver is not yet fully working because I didn't finish kernel integration yet. Almost all driver I/O ops are reverse engineered independently of openbsd openhal which is missing just too much.
Ok, enough talking. Most of the atheros 5212 hal is now open :)
sending patches...
Mateusz
Hi.
Quoted 2 lines · Mateusz Berezecki
Im sending a series of 8 patches splitted and diffed as in SubmittingPatches documentation.
Patch 4/8 is missing here.
Bye, Mike
Signature · 3 lines
Use PGP/GPG! My key: http://keys.indymedia.org/cgi-bin/lookup?op=get&search=62C29B94 Fingerprint: BC2E 79BF 0C8F 0282 864B 9CEC 8343 5169 62C2 9B94
Quoted 2 lines · Mateusz Berezecki
The driver is not yet fully working because I didn't finish kernel integration yet.
How far from working is it? I have a miniPCI Atheros card and would be interested in helping out with bringing the driver up, but it would be good to know what to expect first :-)
<b
Quoted 7 lines · Mateusz Berezecki
Hi list members,
I just post the code for review for anyone interested.
I would be more than pleased to hear some feedback from you on the code.Im sending a series of 8 patches splitted and diffed as in SubmittingPatches documentation.
Quoted 7 lines
The driver is not yet fully working because I didn't finish kernel integration yet. Almost all driver I/O ops are reverse engineered independently of openbsd openhal which is missing just too much.
Ok, enough talking. Most of the atheros 5212 hal is now open :)
sending patches...
It's a good start. When you get a basic working driver, I'll push it into ieee80211 branch, and further review and work can occur.
Jeff
Quoted 7 lines · Mateusz Berezecki
The driver is not yet fully working because I didn't finish kernel integration yet. Almost all
driver I/O ops are reverse engineered independently of openbsd openhal which is missing just too much.Ok, enough talking. Most of the atheros 5212 hal is now open :)
This is great news. An open source Atheros driver which could be included to Linux is really needed.
But how was the reverse engineering done? I noticed that forcedeth driver was implemented using the clean room design[1] and Linux Broadcom 4301 driver project[2] seems to be using the same method.
The reason I'm asking this is that I just wouldn't want see the same happening this with this driver as happened during reverse engineering of pwc Philips Webcam driver (some parts of the driver were removed from kernel, but I believe the situation is now solved).
Actually, what are requirements to get a reverse engineered driver included to Linux? Is clean room design an absolute must? It seems that reverse engineering is needed if we want Linux support for most of the WLAN cards on the market :(
[1] http://en.wikipedia.org/wiki/Clean_room_design
[2] http://linux-bcom4301.sourceforge.net/go/progress
Signature · 1 line
Kalle Valo
It is certainly preferred that someone write a document describing the hardware, and then a totally separate team write the driver, based on that document.
Jeff
Quoted 4 lines · Jeff Garzik
It is certainly preferred that someone write a document describing the hardware, and then a totally separate team write the driver, based on that document.
No question to that. However, I think it largely depends on _where_ the actual re-engineering is done.
Here in Germany, the copyright law is perfectly fine with reverse engineering, as long as you don't actually decompile. The intent of the law is to prevent you from gaining access to the source code (which isn't possible in heavily optimized compiled languages anyway). There is no problem with trying to learn how the program works and what it actually does.
All over the EU, the EUCD states that you are explicitly allowed to do _any_ kind of re-engineering for the purpose of compatibility / interoperability (and you want to make that card interoperable with the linux OS...) All you need to do is to ask the copyright holder for the required documentation. If they don't produce it within a given timeframe (IIRC one month), then you can go and start re-engineering without the approval of the copyright holders.
Also, lots of the low-level driver routines are not copyrightable works anyway. If you need to set up the registers of a device in a certain sequence in order to get it work, then there is no other way of doing so. Therefore the corresponding source code is not the result of a creative process of the author.
I don't want to turn this list into a list of legal discussion, but since I'm heavily dealing with exactly those issues during my gpl-violations.org efforts, I thought I share some of the facts.
So in general, at least if you're doing that kind of work within the EU, I wouldn't be worried all that much.
Signature · 4 lines
- Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
_______________________________________________
Kernel-mentors mailing list
[email protected]
http://selenic.com/mailman/listinfo/kernel-mentors
Quoted 3 lines · Harald Welte
I don't want to turn this list into a list of legal discussion, but since I'm heavily dealing with exactly those issues during my gpl-violations.org efforts, I thought I share some of the facts.
Thanks for your answer, it cleared up things. I also don't want to discuss legal things here, we can discuss it more privately. But I'll just ask one more question in public:
Quoted 2 lines
So in general, at least if you're doing that kind of work within the EU, I wouldn't be worried all that much.
That's good news. But what about inclusion to the official Linux kernel? Can a driver reverse-engineered in EU be included to the kernel? (Big part of Linux is developed in US, I guess.)
Signature · 1 line
Kalle Valo
Quoted 10 lines · Kalle Valo
Quoted 3 lines · Harald Welte
I don't want to turn this list into a list of legal discussion, but since I'm heavily dealing with exactly those issues during my gpl-violations.org efforts, I thought I share some of the facts.
Thanks for your answer, it cleared up things. I also don't want to discuss legal things here, we can discuss it more privately. But I'll just ask one more question in public:
Quoted 6 lines
Quoted 2 lines
So in general, at least if you're doing that kind of work within the EU, I wouldn't be worried all that much.
That's good news. But what about inclusion to the official Linux kernel? Can a driver reverse-engineered in EU be included to the kernel? (Big part of Linux is developed in US, I guess.)
I will consult my legal counsel about this. My current naive position on this is that only the actuall process of the re-engineering matters, not the result.
I'll get back as soon as I have a reply from my legal counsel.
Signature · 4 lines
- Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
_______________________________________________
Kernel-mentors mailing list
[email protected]
http://selenic.com/mailman/listinfo/kernel-mentors
Quoted 3 lines · Harald Welte
I will consult my legal counsel about this. My current naive position on this is that only the actuall process of the re-engineering matters, not the result.
Which countries is this advice valid for? Does someone need to chase this inside the US in parallel?
Quoted 8 lines · Chris Wedgwood
Quoted 3 lines · Harald Welte
I will consult my legal counsel about this. My current naive position on this is that only the actuall process of the re-engineering matters, not the result.
Which countries is this advice valid for? Does someone need to chase this inside the US in parallel?
I'll see whether I can get Eben Moglen to comment on that matter.
Signature · 4 lines
- Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
_______________________________________________
Kernel-mentors mailing list
[email protected]
http://selenic.com/mailman/listinfo/kernel-mentors
[OT] legal status of re-engineering (was Re: atheros driver - desc)
In reply to Harald WelteSorry for again posting something OT, but I think the result of this discussion will in the end provide valuable input to a lot of driver authors.
Quoted 11 lines · Harald Welte
Quoted 10 lines · Kalle Valo
Quoted 3 lines · Harald Welte
I don't want to turn this list into a list of legal discussion, but since I'm heavily dealing with exactly those issues during my gpl-violations.org efforts, I thought I share some of the facts.
Thanks for your answer, it cleared up things. I also don't want to discuss legal things here, we can discuss it more privately. But I'll just ask one more question in public:
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
So in general, at least if you're doing that kind of work within the EU, I wouldn't be worried all that much.
That's good news. But what about inclusion to the official Linux kernel? Can a driver reverse-engineered in EU be included to the kernel? (Big part of Linux is developed in US, I guess.)
I will consult my legal counsel about this.
Ok, as it seems the matter has not yet been investigated thoroughly
enough from a legal point of view. The German institute for law and
opensource software (http://www.ifross.org/) is interested in writing up and publishing a legal article on that subject, but that will certainly take some time for legal research, etc. I'll be advising them on technical matters and get back to you as soon there is some result.
The analysis will be based on the EU copyright directive and should therefore be more-or-less valid for all EU member states.
The US is totally different. As indicated before my holidays (just got back yesterday), I'll contact Eben Moglen about this, but first want to write up some explanations, questions, ... to give him the correct input.
Signature · 4 lines
- Harald Welte <[email protected]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
_______________________________________________
Kernel-mentors mailing list
[email protected]
http://selenic.com/mailman/listinfo/kernel-mentors
Kalle Valo <[email protected]> wrote:
| | This is great news. An open source Atheros driver which could be | included to Linux is really needed. | | But how was the reverse engineering done? I noticed that forcedeth | driver was implemented using the clean room design[1] and Linux | Broadcom 4301 driver project[2] seems to be using the same method.
Reverse engineering was done by dissassemblying binary HAL and in harder parts by running it in userspace(yes, that is possible) and analysing input and produced output. The crucial part was to discover the meaning of hidden part of the structure describing device state. Once this was done it will be a little if no problem to me to provide updates for this driver, unless the whole binary HAL changes dramatically. That's one of the reasons I do this work myself.
| | The reason I'm asking this is that I just wouldn't want see the same | happening this with this driver as happened during reverse engineering | of pwc Philips Webcam driver (some parts of the driver were removed | from kernel, but I believe the situation is now solved).
If get into trouble I write documentation :-) I promise.
| Actually, what are requirements to get a reverse engineered driver | included to Linux? Is clean room design an absolute must? It seems | that reverse engineering is needed if we want Linux support for most | of the WLAN cards on the market :( |
Sad but true. The problem is not at vendors' side though. Look at FCC regulations... :/
kind regards
Mateusz