[asterisk-dev] dahdi system.conf update

Thu Aug 26 16:11:16 CDT 2010

On Thu, Aug 26, 2010 at 03:23:53PM -0500, Shaun Ruffell wrote:
> 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. 

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]

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

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

Hmm.... device file names?

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

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

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

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

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