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
On Fri, 2005-08-05 at 04:55 +0200, Mateusz Berezecki wrote:
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
From: Jeff Garzik <hidden> Date: 2005-08-05 17:46:30
Mateusz Berezecki wrote:
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...
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
From: Kalle Valo <hidden> Date: 2005-08-06 19:57:49
Mateusz Berezecki [off-list ref] writes:
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
--
Kalle Valo
From: Jeff Garzik <hidden> Date: 2005-08-06 20:53:08
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
Kalle Valo [off-list ref] 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
From: Harald Welte <laforge@gnumonks.org> Date: 2005-08-06 21:45:44
On Sat, Aug 06, 2005 at 04:53:08PM -0400, Jeff Garzik wrote:
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.
--
- Harald Welte [off-list ref] http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From: Kalle Valo <hidden> Date: 2005-08-07 07:32:07
Harald Welte [off-list ref] writes:
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:
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.)
--
Kalle Valo
From: Harald Welte <laforge@gnumonks.org> Date: 2005-08-07 15:01:34
On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote:
Harald Welte [off-list ref] writes:
quoted
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
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.
--
- Harald Welte [off-list ref] http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From: Chris Wedgwood <hidden> Date: 2005-08-12 07:37:55
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:
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?
From: Harald Welte <laforge@gnumonks.org> Date: 2005-08-12 11:45:31
On Fri, Aug 12, 2005 at 12:37:55AM -0700, Chris Wedgwood wrote:
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:
quoted
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.
--
- Harald Welte [off-list ref] http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
From: Harald Welte <laforge@gnumonks.org> Date: 2005-08-25 16:36:35
Sorry 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.
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote:
On Sun, Aug 07, 2005 at 10:32:07AM +0300, Kalle Valo wrote:
quoted
Harald Welte [off-list ref] writes:
quoted
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
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.
--
- Harald Welte [off-list ref] http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)