Hi Michael,<br><br>first, thanks for you answer.<br><br>The idea is to provide my own clock source to Asterisk since our hardware has its own clock source and I don't use any "zaptel" hardware. <br><br>Our hardware isn't zaptel dependent then I thought that is possible to provide the clock without the need to install any zaptel software. Well, I think it is still possible but the work involved is much bigger than use ztdummy interface to do it.... And AFAIK, I always will need to patch something...
<br><br>Also, I need to clarify what do you mean when said "to provide channels". Could you please?<br><br><br>Thanks!<br><br><br>Paulo Garcia<br><br><br><br><br><div><span class="gmail_quote">On 6/7/07, <b class="gmail_sendername">
Michael Cargile</b> <<a href="mailto:mcargile@explido.us">mcargile@explido.us</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 2007-06-07 at 09:05 -0300, Paulo Garcia wrote:<br>> Hi,<br>><br>> I'm currently study the alternatives I can use to implement an<br>> alternative clock source for Asterisk. After some research I found two
<br>> options some developers are doing.<br>><br>> The first solution is described on Digium's bug tracker<br>> (<a href="http://bugs.digium.com/view.php?id=8896">http://bugs.digium.com/view.php?id=8896</a>
). The idea is to use a<br>> patched ztdummy with a new module. This module will register itself to<br>> ztdummy and it will implement the interrupt handler. Since ztdummy is<br>> already registered to zaptel, my clock will be used. This solution is
<br>> being used with mISDN driver.<br>><br>> The second solution is to make a ztdummy "clone" with my code<br>> controling the clock.... The idea is very similar to the first one but<br>> the ztdummy-clone will register itself directly to zaptel. I'll need
<br>> to patch zaptel's Makefile to compile my "clone" and so on….Ztxen uses<br>> this solution (XEN virtualization).<br>><br>> Both options are very similar and they need to keep zaptel device<br>
> driver running to do it.<br>><br>> I'd like to know if there are another alternative which doesn't need<br>> zaptel.<br>><br>> Any information will be useful!<br><br>Being the person who did the initial work on ztxen I can give you info
<br>on why we choose the second approach. The big thing with ztxen is that<br>we want to pass the timing in from the host system into the virtual<br>machine so that if the host system has a stable zaptel timer it uses<br>
that instead of the kernel interrupt (XEN virtual machines have no RTC).<br>Also we want to actually be able to pass from the host machine any<br>zaptel channels through ztxen to the virtual machines. We will be<br>implementing this in the not to distant future. Right now ztxen is
<br>nothing more than ztdummy without the RTC stuff.<br><br>If the only thing we were doing was providing timing and no channels to<br>the virtual machine we probably would have just created a module for<br>ztdummy like in the first solution. So my personal opinion is that if
<br>you are just getting a timing source augment ztdummy to use it. If you<br>are going to be providing channels create your own module.<br><br>Personally I think it would be really neat to make ztdummy take some<br>options on load that would allow you to choose which timer it should
<br>use. The three I can think of off the top of my head are the RTC, the<br>kernel interrupt, and the USB subsystem.<br><br>Well that's my 2 cents.<br><br>Michael Cargile<br>Explido Software USA Inc.<br><a href="http://www.explido.us">
www.explido.us</a><br><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:
<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>--------------<br>Paulo Garcia<br>Pika Technologies Inc