[Asterisk-Dev] The Zaptel init scripts must die!

Kevin P. Fleming kpfleming at digium.com
Thu Dec 15 07:19:34 MST 2005


Tzafrir Cohen wrote:

> So you would still have unnecessary manual work. This is bad.

Define 'unnecessary' in this context. There is _no_ automatic tool that 
will be able to _decide_ where I want my channel numbers to be on which 
cards. Given that it will have to ask me how I want things arranged, 
typing that information into the tool vs. typing it into zaptel.conf 
seems like a very little difference to me.

> Two lists of numbers that need to be incremented together (else: strange
> breakage). Information is duplicated. Again: begs for auto-generation.

Sure it does, but at least now it is _possible_, unlike the current model.

> Don't you want to map them to separate namespaces? Instead of just one
> list of channels, each span will be its own list of channels with some
> properties exposed through, e.g. , sysfs . userspace (e.g: chan_zap) can
> use those properties for their own maps, if they choose so.

I did not offer that as a proposal because I'm trying to design this one 
step at a time; the current proposal would not break Asterisk's chan_zap 
at all, nor any other Zaptel-using applications. This is a good thing. 
We can come up with more logical ways of naming channels in the next 
round of changes.

> A sysfs/procfs is also a nicer interface than ioctls for all of the
> small utilities. Some of them could be converted to shell scripts.

Yes it is. Now that the world is moving to 2.6 kernels en masse, I see 
no particular reason to keep supporting configuration/control methods 
that don't take advantage of its features (and thus are backwards 
compatible with 2.4 kernels).



More information about the asterisk-dev mailing list