[asterisk-dev] dahdi system.conf update

[Shaun Ruffell]

On 08/26/2010 06:12 AM, Oron Peled wrote:
> [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)

/dev/dahdi/channel needs the "DAHDI_SPECIFY" ioctl.  Therefore, the
driver needs to have a concept of the global channel number that matches
up with userspace's idea of what the global channel number is. Also, the
output from dahdi_scan displays what the global channel number is and
there may be users who are relying on the output from those tools to
remain consistent.  I would be surprised if there are not other cases
where the global channo leaks to userspace that aren't currently covered
by opening /dev/dahdi/<channel> and using GET_PARAMS to find out what
the global channel number happens to be.

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

I think it would help to think of the global channel number like the
network device name.  Currently you can use "ip link set <old device
name> name <new device name>" to make sure your hotpluggable network
adapters have the same name in kernelspace and userspace.  If we want to
allow for hot pluggable spans and not break asterisk configurations that
are referring to channels by number, we must provide a capability to set
the channel number much like the "ip" utility allows the name of network
devices to be set.  The same is true for span numbers.  Perhaps instead
of channel numbers we should refer to them as numeric channel aliases?
eh, probably not...

And there wouldn't necessarily be holes in the numbers.  Nothing says
that the global channel numbers for a given span be consecutive.  It
wouldn't make much sense to configure it otherwise, but that's not a
requirement.

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

I completely agree that this is where we want to end up.  I just want to
try and avoiding forcing everyone to update their asterisk configs the
moment this is merged and released.

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

ok...but I hope we can remove these "unique attributes" from the span
(which there may be more than one for a single dahdi device) and instead
have them in the device itself.

> 
>  * 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")

+1 for wanting.  -1 for currently requiring.

> 
>  * 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?
> 

My understanding is that this would be similar to how it's currently
done in the "dial by name" branch.  The thought here is that the
KOBJ_ONLINE event would be sent for the span object after all the
channels (which would be children of the span in sysfs) are exported and
have had their minor numbers assigned.  Then the alias in the
configuration file could be used by dahdi_cfg to make the
/dev/dahdi/<alias>/<span relative channo> device files.  This would mean
that there wouldn't be a relationship between minor numbers and channel
numbers.

We would not need to create an extra set of devices (the
"dahdi!<channel>" devices) in sysfs for the sole purpose of creating the
device files.  This could be done by dahdi_cfg which can/should now run
in response to the UEVENTS.  I think this had the added advantage that
the representation in sysfs matches the physical representation with the
disadvantage that we can't just rely on standard udev behavior.  But if
we are already writing scripts to allow symbolic names for the spans we
might as well just let dahdi_cfg do it since we want that to run on
hotplug anyway....


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