[asterisk-dev] dahdi system.conf update

[Oron Peled]

[cut for brevity]

On Wednesday, 25 בAugust 2010 22:49:32 Shaun Ruffell wrote:
> > From: Oron Peled <oron at actcom.co.il>
> > On Wednesday, 25 בAugust 2010 00:47:55 Russ Meyerriecks wrote:
> >> 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.

Dialplan backward compatibility:
 * Existing dialplans refer to channels via DAHDI/<global_num>
    The "dial by name" dahdi driver still provides the /dev/dahdi/channel
    mechanism -- as a result, nothing is changed for these dialplans.
 * Modified dialplans can be written using DAHDI/<span_name>!<rel_number>
    syntax. These use the new "dial by name" syntax and will be resilient
    to hardware changes (e.g: adding new spans)

Hotplug adding/removing/replacing spans with different number of
channels is isomorphic to memory/disk-space allocation -- in the general
case it will always cause fragmentation.

Translating this to our case means that with hotplug spans, we will have
to write channel number allocator and nevertheless, there will be cases
that users will have "unusable" channel numbers (holes in the channel number
space) -- do we want to go in that route?

The solution that was implemented in "dial by name" was to refer to channel
names which are composed for span name + relative channel number.
These names are presistent.

> >> 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.

I may have failed to phrase my question correctly:
 * It is clear to me that the driver will export some unique attributes to
    identify the span. And we already implemented it in the "dial by name"
    branch.

 * Also, we want future user space program *not* to use global
   channel numbers, but instead some persistent addressing (e.g: span-id +
   relative channel number, as was done in "dial by name")

 * As a result, there is a need to map these persistent addresses to the
    specific channel struct in the driver:

 *  In "dial by name" this mapping is done via minor number allocation
    and name creation via udev scripts. As a result, the changes to user
    space are minimal (asterisk diff is < 100 lines) and there are no API
    changes between user-space/kernel-space.

  * So my question was if there is another proposed mapping method
     between the channel persistent names and the dahdi_channel struct
     in the kernel?

Thanks,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"I love deadlines, especially the whooshing sound they make as they go by." 
      -- Douglas Adams