[asterisk-dev] zaptel sysfs / device model

[Tzafrir Cohen]

Hi

I'd like to follow-up on the discussion that has started on 
http://bugs.digium.com/7613 ("automatic configuration for analog
channels").

That bug started with an old patch of mine that is aimed at completely
sasving the need to run ztcfg for analog channels. While I still think
that theis is a neat hack, and noone has yet to come with a scenario in
which it does harm, I agree with the sentiment of others in that thread
that such decisions are better be left to userspace. 

So let's leave the original topic of the bug and skip to

  http://bugs.digium.com/7613#72445 

where meneault has started his own implementation of sysfs support.

This raises a number of issues with the sysfs support:

The current sysfs support has a number of major problems:

1. spans are not represented in any way. Just channels.
2. And even channels are not really represented. Only just enough to
create device files. But they don't get to have their own attributes.
3. The device class interface is considered deprecated and will
eventually be removed from the kernel.

So when a span is registered with Zaptel I don't have enough information
in sysfs or in the generated events to configure it.

For instance, /etc/{sysconfig,default}/zaptel will contain overrides to
the defualt configuration (the default will be ks to analog ports and
some combination of timing priorities with bchan and dchan channels for
digital - this default will be used if the sysadmin has not configured
the system yet).

At span registration a zaptel config script gets an event from udev after
files under udev have been generated for the span and its channels. Thus
this can even be a simple shell script. This config script will
eventually generate a partial zaptel.conf and run ztcfg for it.

Another thing to consider is how to generate the device files. Those
have to be generated by udev and not statically as /dev is not static
anymore on most systems. The current udev rules, which are already
widely deployed by users and integrated in distributions, use the
"zaptel" class name. Maybe we should move that task to the same span
config script? Maybe this can prevent strange issues with the timing of
the generation of the device file.


And this brings the issue of asynchronic events. We loaded a bunch of
drivers. How can we tell that they are fully configured? Will it be
possible to avoid a sleep?

-- 
               Tzafrir Cohen       
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir