[asterisk-dev] A plan for span

[Steven S. Critchfield]

I'm probably going to stick my foot in my mouth over this one, but I wanted to point out a possible different solution.

----- "Shaun Ruffell" <sruffell at digium.com> wrote:
> Kevin P. Fleming wrote:
> > Using the existing hotplug mechanism to provide symbolic names to
> spans
> > and devices both solves the load ordering issue and also provides
> much
> > more understandable configuration and usage syntax. It also avoids a
> 250
> > channel limit, as we no longer have to have any specific major or
> minor
> > numbers for channels, they can be totally dynamic.
> 
> I agree this would be better...but this is orders of magnitudes more
> complex. 
> Everything that refers to zap channels by a number would need to
> change, 
> dialplans, management scripts, call files, GUIS, etc..

Instead of thinking about udev and or hotplug scripts, what about adding a translation layer to asterisk and use sysfs.

On a machine with a TE420, I can
cd /sys/bus/pci/devices/0000:02:08.0
And I see the information about my TE420.

I'm kind of thinking, if you could make a more predictable path into the Digium hardware, that this might be a easy way of aliasing your hardware and knowing where it will be all the time. 

The currently predictable route would be /sys/class/(zaptel|dahdi), but this only gives zap channels and not hardware that is installed. I'm thinking of something more like /sys/block for all the block devices. I guess it isn't all that dificult to scan the /sys/bus/* dirs for vendor files that match 0xd161 or that of other vendors. I guess we would still need to export out information about the spans, and channels on those spans, or just channels such that we could find them in the rest of the listings. I could see similar to /sys/class/zaptel, making a /sys/bus/pci/devices/0000:02:08.0/spans/1/channels/1 directory that contained the same information as /sys/class/zaptel/zap1. This would let you identify the device explicitly, and channels relatively without needing to know what channel number it is.

I also think the aliasing of channels could be done through a chan_local style channel resource. This way nothing else needs to change, and we don't break existing installs. Just create a new config file that allows one to map the channels via a path to a name that would be usable within the new technology dial statement. 

Again, I might be sticking my foot in my mouth, and not helping, but I think it might be an interesting idea.

-- 
Steven Critchfield critch at basesys.com