[Asterisk-Dev] Re: ztdummy? is it necessary?
Christian Richter
christian.richter at beronet.com
Thu Dec 29 01:52:54 MST 2005
North Antara wrote:
> Jason DiCioccio wrote:
>
>> It sounds like it's basically a choice between supporting the OS's
>> driver APIs (which, in my experience, break more often between OS
>> releases) and CPU architecture quirks, versus supporting the RTC APIs
>> for each OS (which, from what I'm gathering, isn't standardized).
>>
>> What makes choice B better than choice A?
>
>
> I'll try to expand on what Eric was saying. Somebody correct me here
> if I'm wrong.
>
> If asterisk (and each function, application, resource, etc, that
> currently {or in the future} uses zaptel timing) had to support every
> OS/configuration, you'll get the same/similar code repeated in quite a
> few places. With ztdummy, asterisk only has to know how to do one
> thing - and the rest can be abstracted into ztdummy. Yes, ztdummy may
> have to change every time one of the BSDs or Solaris or <insert
> obscure OS> changes their interface, but it would only be ztdummy that
> needs to be updated - not 30 different places, which might require a
> recompile of half the asterisk tree (yes, I'm exaggerating a little).
>
> Hopefully I'm not way off...
>
You could easily have an abstract asterisk timing module which provided
the timing to each funtion which needs it. The OS dependend
implementation could be covered by this module. It is easier to debug
things in user-space so there's a wider developer community which could
port the OS dependend part to this timing module. Also the zaptel
dependency would vanish for non zaptel users.
Christian
>
> North Antara
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
More information about the asterisk-dev
mailing list