[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