[asterisk-dev] ztxen a zaptel timer for XEN virtual domains

[Michael Cargile]

We based this off ztdummy at present because we needed a domU Asterisk
server yesterday, and started working on this yesterday thinking that we
could use ztdummy. We realized very quickly that ztdummy no longer
worked in domU domains because of it's new ties to the RTC on Intel
architectures (which we are actually really happy about because of the
fact that the it improves the accuracy of ztdummy on non domU domains).

As I said in my original post, we created a completely separate driver
for this rather than placing checks in ztdummy to see if it is being
built on a domU domain because of the fact that we plan on reworking it
within the next few months. We plan on making it so that it will take
whatever zaptel timing source you have in the dom0 domain and pass it on
the each of the domU domains. Not just ztdummy but any zaptel timing
source, be it a single FXO port analog card or a eight port T1 card,
will be passed. We planned on implementing this by either a virtual
interrupt or through locking within XEN. Once we have done this the
driver will look nothing like ztdummy and will probably rely on XEN
header files. Ztdummy serves its purpose quite well for providing a
zaptel timing source when no other is present and I do not think that it
should be changed to accommodate XEN.

Also we are currently looking into the possibility of taking say an
eight port T1 card and breaking it up into individual T1s and passing
each one of them on to a different domU domain. Within those domU
domains, ztxen will only see the T1s that it was passed. By doing this
ztxen will allow someone to host multiple Asterisk systems on a single
box and provide each one of them their own dedicated T1s. We plan on
doing this because we would like to test various versions of Asterisk at
the same time but do not necessarily want the heat from eight servers in
our office. It would also be great for someone who plans on offering
hosted Asterisk systems. If we can implement this correctly, it should
not be a bigger task to create fake T1 cross overs between domU
domains. 

As you can see we have very valid reasons for creating a separate
driver.

Thank you for your input.

Michael Cargile
Explido Software USA Inc.
http://www.explido.us


On Fri, 2007-05-04 at 10:50 +0300, Tzafrir Cohen wrote:

> Why a different module? Why not just build ztdummy with the USE_RTC
> define unset?
> 
> Now, let's take a close look at the code (from ztdummy,c, aligned for
> readability):
> 
> #if defined(__i386__) || defined(__x86_64__)
> #  if LINUX_VERSION_CODE >= VERSION_CODE(2,6,13)
> #    define USE_RTC
> #  else
> #    if 0
> #      define USE_RTC
> #    endif
> #  endif
> #endif
> 
> I guess we need one of the following three:
> 
> 1. Disable USE_RTC for the case of a Xen kernel as well (how exactly?)
> 2. Move the decision to the build system and outside of the code
> 3. Build both inside and allow selecting one at module load time.
> 
> For instance, what if the host has an actual zaptel hardware? Now you
> could have a ztdummy span that registers on every tick of the zaptel
> master and passes it to the guest (or better: through a PLL, and I
> believe one is already implemented in ztdummy).
> 
> It would still require an extra dummy span (unless you patch that
> directly into zaptel.ko)


> What if the host already has zaptel hardware?
> For instance, what if the host has an actual zaptel hardware? Now you
> could have a ztdummy span that registers on every tick of the zaptel
> master and passes it to the guest (or better: through a PLL, and I
> believe one is already implemented in ztdummy).
> 
> It would still require an extra dummy span (unless you patch that
> directly into zaptel.ko)