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 <[email protected]> > >>> 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:[email protected] +972-50-7952406 mailto:[email protected] http://www.xorcom.com iax:[email protected]/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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-security mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-security
