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

[Tzafrir Cohen]

On Wed, Dec 14, 2005 at 09:44:27AM -0600, Kevin P. Fleming wrote:
> Tzafrir Cohen wrote:
> 
> >2. You canactually remove that listing, and rely on either discover or
> >hotplug to pick it up. Both are expected to. 
> 
> With current udev (unstable 'sid'), hotplug is a deprecated package. I 
> haven't tested whether discover will make the modules autoload or not, 
> but I think it's not doing that on my system.

Hmmm, its blacklisting abilities are really useful...

> 
> >2. The current zaptel drivers do not allow dynamic unregistration and
> >   registration. But let's ignore that for now. The main problem here is
> >   not just fixing them to do so, but also the fact that the only
> >   identifiers you have are the span numbers and channel numbers, which
> >   are too dynamic and wildly depend on the load order. 
> 
> Correct.
> 
> >   Something that is a bit more permanent is the physical address in the
> >   system. E.g: the PCI slot number. There should be some sort of "PCI
> >   address" for every PCI card, I believe (the first column in lspci).
> 
> Exactly my idea :-)
> 
> >   In USB there is something rather similar. Not sure about pcmcia and
> >   ISA.
> 
> They don't matter, we can let the producers of PCMCIA/CardBus and ISA 
> Zaptel gear deal with that in their drivers.
> 
> >   There is also nothing equivalent of a MAC address.
> 
> With current hardware that is true, but some of the new stuff (TDM2400P) 
> may change that.
> 
> >3. We had it working rather dynamic, but then noticed that we nust
> >   configure zapata.conf at the same time because it replicates much of
> >   the information in zaptel.conf and changing it requires asterisk
> >   restart.
> 
> Agreed.
> 
> I'm thinking along these lines:
> 
> Modify zaptel core and drivers so that when a driver binds to a 
> card/device, it does only two things: register that card/device with the 
> core and provide a system-unique identifier for that card/device. For 
> existing PCI devices, this would be the PCI location info; for USB it 
> would be the same. Both of these would be superseded by MAC (or 
> equivalent) for devices that can supply a globally-unique identifier.

Let's look at two scenarios:

1. You want to replace a (defective?) card. You remove the old one and
(hot)plug the new one to the same physical location.

For this it would be nice to configure by "connection": Something like:
"pci:0000:00:07.0" . 

2. Removing the card and (hot)plugging it in a different slot.

For this it would be nice to configure by "MAC address".

> 
> Registration of that card with the core would include telling the core 
> how many spans the card supports, but would _not_ assign span or channel 
> numbers to any of the card's interfaces.
> 
> This registration would register 'something' (some sort of device, 
> probably) in sysfs, which would cause kernel uevents to be handled by 
> udev. There would be a rule in the udev configuration for when these 
> devices appear, to run ztcfg to configure that device _only_ (by passing 
> the identifier gleaned from sysfs to ztcfg). ztcfg would configure the 
> device, which would assign (by reading info from zaptel.conf, not 
> dynamically assign) span numbers and channel numbers to the device's 
> interfaces. zapata.conf would continue to reference span numbers and 
> channel numbers, but they would be deterministic.

How do you guarantee that span and channel numbers continue being
non-varianting?

> 
> Configuration of those span numbers and channel numbers would then 
> generate more kernel uevents, which would create the actual Zap device 
> nodes for Asterisk or other applications to use.
> 
> Along with some changes to chan_zap to allow it to gracefully start when 
> configured channels are not present, this would go a long way towards 
> providing configuration flexibility and less 'surprise' when things are 
> changed around.
> 
> Comments?
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 

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