On Fri, 14 Feb 2003, Duncan Sands wrote:
> I can see three possibilities:
> (1) they refuse to release the specs
> (2) they release the specs to a limited group of developers
> (3) they release the specs publically.
>
> Is (2) acceptable?
>
Not really. If it is the only option then it's better than 1 but it
has a number of problems:
1. E.g. software buffering - it works for some, it doesn't for others,
nobody knows what it does or why it doesn't work, it is just magic numbers.
Once the code has dozens/hundreds of these "quirks" it becomes unsupportable
except by people who have the specs and also have the particular problem
people are seeing.
I got the speedtouch 330 working without access to a 330. Could I have
done that if there had been hundreds of incomprehensible commands being
sent to the modem? I suspect not as one or more of them would almost
certainly not have been correct for the 330. (With help from others who
could try my patch together with the "And try this if it doesn't work"
instructions)
2. Some of the commands can be "reverse engineered" from the code. Again,
take the software buffering. Either there will have to be comments in
the code in which case the developer with the specs will be violating
the NDA or there will be a
/* Yes, its crazy but it works for me (tm) and I can't tell you what it does.
* Tough if it doesn't work for you
*/
NDA_command1[] = { 0x45, 0x42, 0xFF, 0xFF, 0x01 };
I would not be prepared to sign an NDA for specs for a device where the
device driver would be open source as it is almost impossible to write
code based on specs without "leaking" a lot of the information in the spec
into the codebase.
3. We already have some magic in the usermode driver - the cell header
CRC calculation. When someone started having some problems I spotted that
the code to calculate the CRC had been removed and a constant (0xcb IIRC)
was being used instead. This looked like a bug to me and I wasted some
time writing some code to calculate and cache the CRC values. I now notice
that this magic number is in (and was probably always in) the kernel mode
driver and I suspect it was "pinched" from there. Maybe the person who
put this magic constant into the usermode driver should have put a comment
but what could they have put? /* The kernel mode driver does it this way.
It seems to work. If you start getting errors then it may or may not be
this magic number, who knows? */
3. From Thompson's point of view.
GiveDeveloperSpec();
usleep(1);
DeveloperLeakSpec();
Following on from this, just the spec for the Speedtouch USB wouldn't be
a great idea unless we also know that the 330 ``should'' be backwards
compatible with all the commands. Otherwise we are likely to end up with
a code fork. As it is, many people are now running older versions and the
software buffering has caused them problems when they upgrade.
Just my 0.02EUR
Tim.
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
