[asterisk-dev] dahdi_device representation

[Oron Peled]

During Shaun Ruffell adventures with DAHDI persistant channel assignments
he started implementing a very important feature (IMO) -- a representation
of dahdi_device that represent a collection of spans.

Lack of this representation caused hardware attributes to be
duplicated in the spans while in reality they should be represented
in the dahdi_device (e.g: location)

I would like to use this opportunity ot present a relevant issue that
may IMO affect the design:

1. Historically, chan_dahdi was not made for hot-pluggable
   devices.

2. As a result. After a successfull open(), chan_dahdi ignore read()/write()
   errors (except for the special errno used to pass events).

3. This means that if a device is removed under chan_dahdi feet it
   goes to an infinite tight failed read() loop which usually make the
   host unresponsive after a few seconds (except of the kernel)
   because asterisk usually runs at real-time priority.

4. Since Astribanks were always hot-plugabble, we "solved" this problem
   by employing various measures in our xpp drivers:
   - When a device is removed, we *keep* its data structure intact and
      make a note to ourselves that it's disconnected.
   - We send a red alarm to asterisk for disconnected devices, trying
      to squelch some of the "noise".
   - We ignore asterisk calls for disconnected devices.
   - We added a "REMOVED" event to asterisk, politely asking it to remove
      a span with all its channels.
   - We refcount the opne/close so if/when asterisk is nice and actually close
      all channels, we can actually release the data structures.

   BTW: only lately (during dial-byname development) we managed to fix
           asterisk so removing a digital span would also close its dchan.

5. Obviously, keeping "ghost" devices around so we don't surprise asterisk
    is not a very good design, but we didn't see any alternatives at the time.

If chan_dahdi is not made aware to driver errors (e.g: -ENODEV), similar ugly
techniques would be needed for hot-plug implementation at the DAHDI
level. This has some design consequences for the sysfs object layout and
therefore should be thought about early.

So the question is short:
   Should DAHDI account for and work around chan_dahdi ignorance?
   Or should chan_dahdi be fixed first?

Opinions, rants,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"Simplicity is prerequisite for reliability."
                        -- Edsger Wybe Dijkstra