[asterisk-dev] dahdi system.conf update

[Shaun Ruffell]

I'm not sure why I didn't receive this email through the list but Russ
forwarded it to me.

> -------- Original Message --------
> Subject: Re: [asterisk-dev] dahdi system.conf update
> Date: Wed, 25 Aug 2010 11:24:39 +0300
> From: Oron Peled <oron at actcom.co.il>
> To: asterisk-dev at lists.digium.com
> CC: Russ Meyerriecks <rmeyerriecks at digium.com>,        Michael Spiceland <mspiceland at digium.com>
> 
> Looks like a good idea, but a few points...
> 
> On Wednesday, 25 בAugust 2010 00:47:55 Russ Meyerriecks wrote:
>>   I'm looking at updating the dahdi config file to be closer in line
>> with asterisk's ini config files. I propose :
> 
> Changing the syntax in a significant way involves backward/forward
> compatibility issues. Suggestions for migration plan:
>  * The new file  should have different name than "system.conf"
>  * The new dahdi_cfg utility would look first for the new file and fallback
>    to the old file if it is missing.
>  * If the old file exist (regardless of the new), the new dahdi_cfg should
>    issue a warning about deprecated configuraiton laying around.
>    (so people would not have two configs at the same time)
>  * Maybe later, dahdi_cfg on maintenance branches should be patched
>     to issue a deprecation warning.

+1

> 
>> 1) Creating a "section" for each span. Currently, span local
>> configuration lines are associated with the previous "span=" line. I
>> think spans as sections would divide the file nicely. As a follow on, we
>> can break everything in the "span=" line into separate parameters. This
>> seems more readable than our current parameters-as-positions-in-a-string
>> method. eg
>>
>>      [global]
>>      loadzone = us
>>      defaultzone = us
>>
>>      [span_1]
>>      timing_priority = 1
>>      framing = esf
>>      coding = b8zs
> 
> Good. But let's think a step further (e.g: help config generators) and *allow*
> each span to reside in separate file:
>  * Have dahdi_cfg read /etc/dahdi/spans.conf which normally would contain
>     the [global] section.
>  * Have the default /etc/dahdi/spans.conf contain:
>        include /etc/dahdi/spans.d/*.conf
>  * Now each span may be a foo.conf file dropped into the /etc/dahdi/spans.d/
>    directory or moved/removed if we want to disable it.
> 
> Note that users are still permitted to make a monolithic /etc/dahdi/spans.conf
> but are encoraged to configure each span in a seperated file so it's easier
> to implement "plug and play" systems.

+1

> 
>> 2) Assigning to each span a global channel number start point and
>> allowing all other channel configurations to be offsets from this. This
>> is to support our new sysfs additions, as we are moving the global
>> channel enumeration out into user-space.
> 
> That's really bad. Why go back to global numbering at all? The whole idea
> of the "dial by name" feature was to make channel numbering *relative* to
> their span. Let's not break this feature.

I do not believe relative channel numbering and global channel numbering
are mutually exclusive.  I do not so much think of it as "going back" as
opposed to supporting both during a transition period so that everyone
isn't forced to update their dialplans when they update to a version of
the drivers that support hot pluggable spans at run time.

> 
>> 3) Adding a unique identifier and alias for each span. This will allow
>> us to switch from referencing global channel numbers to a span-relative
>> system. ie "span-alias/channel"
>>
>>      [span_1]
>>      id = 0000:03:02.0:0 #<pci bus id>:<span>
>>      alias = telco
>>      # These channels could be referenced as "telco/<channel>"
>>
>>      [span_2]
>>      id = 0000:03:02.0:1
>>      alias = office
>>      # These channels could be referenced as "office/<channel>"
> 
> Looks good, but I may be missing something -- Who would map the "id"
> or "alias" to the actual spans?
>  * If it's dahdi_cfg, than similar mapping should be implemented for
>    asterisk as well -- how this code would be maintained? share lib?
>  * If it's dahdi.ko, through what API?
>  * If "id" or "alias" are missing? What should be the default behaviour?

My thought here is that the id would come from some piece of information
out of the parent device.  Each span would point to their parent "struct
device" in the same manner that channels point to their span.  Could be
the name (as in the example Russ used for PCI devices) or serial number
or some other attribute.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org