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

[Artem Makhutov]

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