In article <40741691.8070903@unorthodox.com>,
Hadar Pedhazur <hadar@unorthodox.com> wrote:> I have a system with no Digium hardware in it (two others with 2 X100P
> cards in each of them as well). I'm interested in using MeetMe in the
> one without the hardware (it works great in the ones with the
> hardware). I can't use ztdummy, because the system has usb-ohci
> drivers, rather than usb-uhci.
I have the same situation, and I'm sure many others do too.
> I have read the little there is about zaprtc, and I am wondering
> whether there is a downside in turning off RTC support in the kernel,
> and recompiling. Are there other things that might break if I do this
> (it simply feels like a more "drastic" step than the ztdummy
> approach)? (I am running Red Hat 9.0)
Actually, I have used Zaprtc quite successfully. The only reason you
have to disable kernel RTC support is because Zaprtc is actually a
*replacement* for the standard RTC module. It provides the same
facilities, but includes extra parts for Zaptel use.
The Red Hat kernels have the RTC compiled directly into the kernel,
which precludes loading a modified one. Rather than completely disable
the RTC in the kernel build, I preferred to specify it as a module.
This way the build kernel still works normally.
If Red Hat had provided the RTC as a module instead of compiled in,
there would have been no need for the user to recompile the kernel
before using zaprtc.
When I start up Asterisk, I then unload rtc and load zaprtc in its
place, followed by running rtcsetup. I've also enhanced rtcsetup
to be a proper daemon.
> Finally, and this will show my complete naivete for linux programming,
> I am curious as to why no one has written a timer that simply hooks
> the standard kernel installed RTC?
This is effectivel what *has* been done. The zaprtc code is the standard
rtc.c from the kernel, with zaptel-specific parts inserted in a couple
of places. There were no hooks to link in the zaptel requirements without
a recompile.
The zaprtc.c code is based on the rtc.c from 2.4.20. I am running 2.4.22,
so I isolated the zaprtc changes, and re-applied them to a copy of the
rtc.c from 2.4.22. It works a treat.
> From the rtc.txt file in the
> Documentation directory of the kernel source, it seems that one can
> "hook" the interrupt and get the clock ticks delivered via
interrupt
> directly to your c code. Isn't that what is needed to get a stable
> timing device in *? Just curious, as I'm sure that it's way more
> sophisticated than that...
That's exactly what zaprtc does. However, it needs to deliver not to
the application, but to the zaptel pseudo-channel driver at kernel
level. That is why a modified version is required.
> Thanks in advance.
>
> P.S. The system with no Digium hardware in it is in a colo facility
> that is 250 miles from my house, and besides, I don't have physical
> access to the machine. So, it would be painful, and expensive, for me
> to arrange for a Digium card to be installed in the machine, and it
> would be used for nothing other than the clock, since there are no
> other interfaces available for me to plug into the card. This was just
> to nip the "why don't you just pony up for a Digium card?"
responses :-)
:-)
Cheers
Tony
--
Tony Mountifield
Work: tony@softins.co.uk - http://www.softins.co.uk
Play: tony@mountifield.org - http://tony.mountifield.org