[asterisk-security] [asterisk-dev] dahdi system.conf update
Tzafrir Cohen
tzafrir.cohen at xorcom.com
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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-security
mailing list