If we don't do this, we always have a full FIFO at the time userspace
opens the trunkdev, adding latency for no good reason.
Change-Id: Ifbda3766309cc7d6be485073e36607bdd6742f3a
This virtual trunk device is a new character device. Contrary to
the per-channel devices, this is a per-span device for virtual E1
spans. Userspace reads and writes 32-byte E1 frames on it.
ioctl's are added to create and delete such virtual trunk devices
at runtime. Each virtual trunk device is limited to one span.
Opening trunkdev is similar to opening channels via /dev/dahdi/chan
works: All users open the same generic device node but then issue
an ioctl to specify which (named) trundev they actually want to open.
This avoids having to dynamically register minor device ids, creating
device nodes, etc.
The trunkdev is in RED + LOS alarm after creation. Only once a userspace
process opens the E1 frame side, those alarms cease.
Change-Id: Iffd9a1a09d835b29927acd374364cab56745fb74
Harald Welte