[asterisk-dev] GSM trunks & Dahdi - New funcionality Request for discussion

[Odicha]

Artem Makhutov escribió:
> Hi,
> 
> On Thu, Nov 19, 2009 at 06:16:05PM +0000, Odicha wrote:
>> Tzafrir Cohen escribió:
>>> On Thu, Nov 19, 2009 at 03:06:00PM +0000, Odicha wrote:
>>>
>>>> In a abstraction layer environment with an own library and AT
>>>> translation at dahdi driver it would be somethig like this:
>>>>
>>>> case SEBI_STATE_PRE_ANSWER
>>>> 	if (h == CALL_ANSWER_ACK)
>>>> 		sebi->ev.e = SEBI_EVENT_ANSWER_ACK
>>>> 		....
>>>>
>>>> and the "translation" between "AT^DDSETEX=2\r" and CALL_ANSWER_ACK would
>>>> be done at dahdi driver level. So in hdlc frames between library & dahdi
>>>> won't have AT commands but our own signalling abstraction layer events
>>>> and frames.
>>> Is there a good reason to do this translation in kernel space?
>>>
>>> One potential good reason: if the driver needs to allocate resources
>>> that may be used by different userspace processes and needs to
>>> understand the AT commands in order to do so.
>>>
>> Suppose we finished this. It's working fine into trunk. Brand X (better
>> Y... some brands starts with X here ;-) Brand Y wants make a GSM card
>> for asterisk. Their GSM module has an AT commands pool different from
>> those that are already into the library. They might make a new module
>> for AT library, be tested, added to svn and later into trunk.
>> If we put AT translation into kernel space and work with a standard AT
>> abstraction layer, they can make a driver that uses existent library.
>> John Todd told me that a good way could be via some .conf file, but for
>> make the same thing one module uses one AT command and another three, so
>> I don't see it...
> 
> Don't put this into kernel space.
> All AT-Command translation and "normalization" should be done in user space.
> 
> All the AT commands of the Huawei sticks are not documentated.
> You don't know for sure what could be happend. Something unpredictible
> could crash the whole server.
> 
> Also the debugging, installation and so on would be more complicated.
> You will have to recompile the kernel modules on a kernel update and so on...
> 
> I don't see any reasons to put this into kernel space.
> 
> Regards, Artem
> 

Ok. "A" model but with AT translation into library then?

> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev