Hi Tim, thanks for your email.
On Friday 14 February 2003 13:17, Tim Woodall wrote:
> 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 disagree. Of course it would be better for everyone to have the specs rather
than just a few, however I think this argument is weak. After all, the developers
on this list already try to fix problems that they themselves don't have. Having
the specs would give insight. For example, if we knew what software buffering
is (how it works in the modem) we would be better able to decide if (1) it is of
any interest, and (2) what the problem might be. It is true that the code would
become harder for other people to work with, but it is not yet clear how serious
a problem that would be.
> 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)
I don't understand your comment. Suppose we added all kinds of optimizations
and extra stuff to the driver, making it interact with the modem in a more complicated
way. Suppose Thomson produces a new modem. The obvious thing to do is turn
off all the extra stuff and see how things work with the new modem with the minimum.
Of course this requires that the driver be written in such a way that extra stuff can
be
easily turned off, but that is more a question of good design.
> 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 };
This kind of thing is indeed a problem with an NDA. It depends very much on how
the NDA is phrased. If it is ok to add a comment saying "turn on software
buffering" or "performance optimization" without giving details then it is already
a bit better. But for sure, if there is too much of this kind of thing then it becomes
quite hermetic for people who do not have the specs.
> 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.
I disagree. Not all NDAs are equal. It needs to be clear in the NDA that the
specs will be used for writing an open source, publically available driver. It also
needs to be clear what is OK to go in the code, and what is giving away too much.
I too would not sign an NDA which meant I could not reasonably improve the open
source drivers. But I might sign an NDA which was more lenient.
> 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? */
I think you mean 0xec. Maybe if we had the specs we would know. For me,
the worst bit about only a few people having access to the specs is that it excludes
everyone else who would like to do something with the modem or the drivers. For
example, the modem contains an ARM processor. I can imagine someone wanting
to boot linux on the modem! Crazy, I know, but we can't know what someone might
want to do. Without the specs, playing around with the modem becomes almost
impossible. I don't want there to be a "chosen few". I want to give power to the
people!
But if there is no other way, then maybe that is how it will have to be.
> 3. From Thompson's point of view.
>
> GiveDeveloperSpec();
> usleep(1);
> DeveloperLeakSpec();
I think you are exagerating.
> 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.
It is easy to autodetect whether you have a speedtouch USB or a speedtouch 330
from the USB info. So then you can selectively turn on strange optimizations that
depend on the hardware. I think it is good to exploit the hardware as much as
possible, rather than go for lowest-common-denominator code.
All the best,
Duncan.
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
