Messages in this thread | | | Date | Sun, 08 Aug 1999 04:30:33 +0000 | From | Steve Underwood <> | Subject | Re: no driver change for 2.4? |
| |
Hi,
Rik van Riel wrote:
> On Fri, 6 Aug 1999, Linus Torvalds wrote: > > > It is over. I refuse to see this continue. The ISDN people need to > > open up, and stop the ridiculous practice of having closed lists and > > closed releases, and not feeding them back until it's basically too > > late. > > Unfortunately, the phone companies don't allow you to connect to > the network with uncertified hardware/driver combo's. Opening up > the ISDN development could bring all sorts of legal trouble with > it :( > > At least, this is what I gathered from various sources. ISDN > development is just as opaque to me as it seems to be to you > so I could be very wrong on this one...
This is an issue for ISDN cards, and an even bigger issue with Winmodems, but it varies a lot from country to country. If you read the telecoms approval regulations for some countries carefully you cannot get approval for modules - only for complete systems. That means a modem approval says its approved for use with a model XYZ computer. Use with any other computer breaks the approvals. That means almost every user is breaking the approval. Dumb, huh?
For an ISDN card or modem maker to get approval in most countries they need to comply with three groups of specs. - electrical safety, spectral quality, and network signalling compatibility.
Electrical safety is generally a pure line interface hardware issue - the hardware either meets or does not meet the spec., and software plays no part.
Spectral quality is mostly controlled by the line interface hardware and the DSP software, whether running in a dedicated DSP or on a host's CPU. To get approval the vendor _cannot_ permit the end user to tamper with the approved configuration. This ties the arms of the makers of pure software WinModems, and may affect the Winmodems with a DSP, and ISDN cards too. The vendors are not just being difficult when they refuse to release code and information, although I suspect most of them are difficult by nature. If sufficient work is performed by code embedded in the product the approvals problems go away, and the host code can be open. The dividing line varies between countries, though.
The last approval issue is network signalling compatibility, and this often shows the biggest variance between countries. For example, some countries still insist a modem may only be allowed to redial a single number up to X times in Y hours, with no possibility of user override. Giving the end user source code for even the back end controller section of the modem or ISDN card would be a problem here. Again, the dividing line between what approvals bodies require to be fixed, and what can be freely altered varies greatly between countries, and makes the vendor's life pretty hard.
With both modems and ISDN cards the approvals issues depend a lot on the design of the card. If sufficient work is done by code embedded in the card approvals should be OK. If it relies too much on code the end user can change you have serious problems with any level of openness in most countries. Some of this is due to pointless regulation. Some has a valid basis. Consider what happens if someone tampers with the DSP code for a modem. Will they have the necessary test facilities to check if they have adversely affected the spectral output of the unit?
The bottom line is don't be too hard on the ISDN and modem people, as approvals cause them serious difficulties. On the other hand don't be too soft on them - if they had a genuinely open attitude they would adequately explain these issues, and try to open up whatever is possible within the constraints imposed by approvals.
Now, how does this relate to the ISDN4Linux work? I believe the cards they currently support are approvable at the card level in most countries. In fact, considering the "anti-tamper" requirements in a number of telecoms specs., that would appear to be a precondition for freely releasing legal ISDN4Linux drivers. I, therefore, doubt this issue has anything to do with the reluctance of the ISDN4Linux people to make timely progressive releases of their source code.
Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |