[asterisk-dev] dahdi system.conf update

[Shaun Ruffell]

On 08/26/2010 04:11 PM, Tzafrir Cohen wrote:
> On Thu, Aug 26, 2010 at 03:23:53PM -0500, Shaun Ruffell wrote:
>> On 08/26/2010 06:12 AM, Oron Peled wrote:
>>> On Wednesday, 25 בAugust 2010 22:49:32 Shaun Ruffell wrote:
>>>> 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. 
> 
> Fine.
> 
> Note that with the proposed format there's no global numbering at all in
> system.conf . You'd need a translation option from system.conf numbers
> to global numbers just like the option '-p' added to lsdahdi in the
> dahdi-tools sysfs branch[1]

Understanding that I would like for users to be able to update DAHDI
without requiring them to update Asterisk, there are many existing
Asterisk installations that do use global channel numbers in
/etc/asterisk/chan_dahdi.conf.  This new version of DAHDI should not, in
my opinion, set the blacklist or need the /etc/dahdi/modules files.  We
should let udev load the drivers for the devices it detects.  But
without the blacklist and specific driver load order, existing Asterisk
installations.

Another use case for maintaining some support for global channel
numbering could be that you have an old Asterisk 1.4 installation that
has been working fine.  You're not interested in risking an update of
Asterisk if you otherwise don't need it.  However, you also want to
minimize the time from power on until Asterisk is ready to take calls.
Loading the drivers (especially the TDM2400) can take some time.....if
udev could start loading the devices early in the boot sequence, it
could happen in parallel during system start so that all the dahdi init
script would need is wait until all the devices it expects are present.
 You've increased your availability without incurring the risk of both
an asterisk and dahdi update for an otherwise functioning installation.

Another use case could be that you have several devices providing FXO
ports in your, again otherwise completely fine Asterisk installation,
one of them fails (perhaps struck by lightening) but you don't have a
replacement available immediately but you would still like your other
ports / cards to continue functioning.  You could either update your
configs and dialplans to use the now renumbered channels (since unless
the card that failed was not the last one loaded, there will be some
channel renumbering based on registration order) or you could update
DAHDI and keep the spans static for the cards that are still functioning
and just comment out now failed span in your asterisk configs.

These use cases are also valid when using "dial by name", but that would
require an Asterisk update and some users might want the benefits of a
DAHDI update without also requiring them to update their Asterisk
installation.

> 
>> 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.  
> 
> dahdi_scan can be modified. You can add an extra output field. Or
> whatever. This has been demonstrated by the changes to lsdahdi and co.
> in the dahdi-tools sysfs branch.
> 
>> 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.
> 
> One thing I was hoping to avoid in the sysfs branch is the need to open
> a file to merely get such data. DAHDI_GET_PARAM is a r/w ioctl.

No disagreement from me here.  I don't think opening a channel via a
device file just to find out what the 'channo' for the channel is
desirable or necessary.

> 
>>
>>>
>>> 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 > 
>>
>> 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.
> 
> A DAHDI device means a driver needs to register it first before
> registering spans. But placing common attributes up the tree is indeed a
> good idea.
> 
>>
>>>
>>>  * 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.
> 
> I think you basically mean the same thing.
> 
>>numbers we should refer to them as numeric channel aliases?
>> eh, probably not...
> 
> Hmm.... device file names?

Great for one way "alias" -> "actual device" mapping in userspace.  Not
so useful when kernel space is presented with an alias and needs to find
the actual device, again referring to DAHDI_SPECIFY.

>>>
>>>  * 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.
> 
> Note that in the sysfs branch the aliasing symlinks are created
> separately, and are merely simple directory symlinks. Whereas the
> <channo> files are real device files created automatically by udev. This
> greatly reduces the work that needs to be done in udev.

My opinion is that this leaks an implementation detail that
users/userspace shouldn't care about.  This would mean there are "real"
channels in sysfs under their spans, and also these other channels that
are only there so udev can create the device files for us.  These other
channels also have names that reveal their registration order that may
not be consistent between boots.  Spans exported as children of devices
will have a consistent sysfs representation regardless of the
registration order.

> 
>>
>> 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....
> 
> Generating a node per device is something udev does best. I don't think
> it's a good idea to add this into dahdi_cfg. For instance, it should be
> simple to allow configuring the nodes as either asterisk:asterisk,
> root:asterisk or root:dilout . This is currently done with simple udev
> rules. Let's keep it this way.

Ok.  Perhaps dahdi_cfg doesn't need to perform this if we can write the
rules to take a single UEVENT for the span and create dev files for all
the children.  I was just thinking that it would be easier to try and
consolidate locations where configuration information lies and since
dahdi_cfg is running in response to hotplug events anyway...  But I
haven't yet looked into this enough.

> 
> [1] http://svnview.digium.com/svn/dahdi/tools/team/tzafrir/sysfs/
> 


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