[asterisk-dev] dahdi_device branch

[Shaun Ruffell]

On 1/10/11 5:02 PM, Tzafrir Cohen wrote:
>
> Regarding https://github.com/sruffell/dahdi-linux/commit/283436d2b094e
> (your dahdi_device branch)
>
> Generally this looks like a good idea. Is it intended to be included
> next? If so, we'll re-apply our changes on top of it.
> Naturally it means a change to low-level drivers, which is somehing we
> opted to avoid so far.

Yes, but I'll need to rework it again slightly.  Since I want to embed a 
"struct device" in the "struct dahdi_device", I cannot have the board 
drivers embedding the "struct dahdi_device" in the driver specific 
structures (for the same reasons described in this LKML thread: 
http://thread.gmane.org/gmane.linux.kernel/1085178).  Instead I'll need 
to add a dahdi_create_device / dahdi_destroy_device so that I can move 
the lifetime management of those objects out of the board drivers and 
into dahdi-base.c

My intent with the dahdi_devices (besides removing duplication 
information from the spans) is to allow a two-stage registration.  The 
dahdi_device can show up in sysfs when first registered.  A script 
started by udev can then set the span number and channel numbers on the 
child spans, which will then be registered themselves and show up in 
sysfs.  This will eliminate any need to rename/renumber the spans like I 
had originally proposed.  [1] contains a discussion about why this is a 
bad idea. ([2] contains the previous discussions about why I was trying 
to rename the channels / spans)

I'm not convinced that we need to wait to merge your byname [3] branch 
until after this goes in anymore.  I was originally thinking that we 
wouldn't need to virtual DAHDI bus in order to plug the spans in on, and 
that we would only have a tree rooted in /sys/devices but I think I was 
wrong about that.  So, I don't see how slightly delaying the span 
registration in order to set the numbers conflicts with anything you 
have in the byname branch.

For Reference:

[1] "LKML: [RFD] Device Renaming Mechanism"
http://thread.gmane.org/gmane.linux.hotplug.devel/16183

[2] http://lists.digium.com/pipermail/asterisk-dev/2010-August/045923.html

[3] 
http://gitorious.org/~tzafrir/asterisk-tools/dahdi-linux-tzafrir/commits/merge_byname

Some other pertinent breadcrumbs about why this whole topic is important 
for anyone else who is following along:

"0007613: [patch] automagic configuration with sysfs and udev"
https://issues.asterisk.org/view.php?id=7613

"[asterisk-dev] A plan for span"
http://lists.digium.com/pipermail/asterisk-dev/2008-July/033805.html

"[asterisk-dev] dahdi_device representation"
http://lists.digium.com/pipermail/asterisk-dev/2010-August/045928.html


>
> Note that for the xpp a device is represented by a 'xbus', whereas 'xpd'
> corresponds to a single span. Anyway, we'll need to work with this a
> bit, of course.

Ok, thanks

>
> Another minor detail is that struct dahdi_device should also have a
> hardware_id field, in addition to the location :-)
>

If eventually the "struct dahdi_device" is setup as a child of the 
physical device, I think location should be completely dropped and 
replaced with a hardware_id that could be used.


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