Since r5021 [1], first released in DAHDI-Linux 2.2.0, it's been impossible for
user space to change the rxbufpolicy. This hasn't caused any problems and it's
safe to remove a few more of the vestiges of the rxbufpolicy from the driver.
This streamlines the code path in a few places and saves 8 bytes from the size
of struct dahdi_chan.
The user visible parts are maintained and will indicate
DAHDI_POLICY_IMMEDIATE, like it has since 2.2.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=5021
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10730 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When DAHDI is bridging channels between two different cards, or a user is trying
to record from a channel on a card that is not using the same timing source as
the master span, it is possible to miss audio.
For example, given the following scenario:
<T1 Span> <---> <ISDN CARD> <---> <ANALOG CARD> <---> <local handset>
If DAHDI was set to natively bridge the call from the T1 span to the local
handset it is possible that system conditions could result in one of the cards
servicing their interrupt three times before the other card has a chance to.
Since there are currently only two conference buffers to pass audio between the
cards, one chunk (1ms) of audio will be dropped since the card servicing it's
interrupt more frequently will run out of space to copy audio for the other card
and will have emptied the audio buffer from the other card.
Increasing the number of conference buffers to eight greatly reduces the
probability of audio from being dropped under these conditions at cost of an
additional 72 (32-bit) or 96 (64-bit) bytes per DAHDI channel.
Internal-Issue-ID: DAHLIN-159, DAHDI-976
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10726 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When compiling against kernels 2.6.25, you could get the following error.
error: linux/pci-aspm.h: No such file or directory
This fixes a build regression introduced in r10556 "dahdi: Add
dahdi_pci_disable_link_state for kernel < 2.6.25." [1]
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10556
Reported-by: Jean-Philippe Lord
Internal-Issue-ID: DAHLIN-299
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10705 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* This is a minimal convertion -- everything compiles and looks OK.
* We print a warning for spans registering without a spantype.
* Low-level drivers may later want (but not required)
to fold their internal representations to this canonical
representation -- it will save code and make it more readable.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Instead of registering a function pointer, register a dahdi_dynamic_ops
structure that contains the owner as well as the ioctl callback. This way
dahdi.ko can bump up the reference count on dahdi_dynamic.ko before calling
the ioctl callback.
Also, use the registration mutex to guard against the module being unloaded
between the time the structure pointer was checked, and the module reference
is taken.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10623 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This in conjunction with r10449 "A parent-less device should not crash dahdi",
this allows dahdi_dynamic spans to work post the dahdi_devices changes in
2.6.0.
The full address of the device is not used since kernels prior to 2.6.31 limit
the length of a devicename to 20 characters. The full address of the device
can be pulled out of the "hardware_id" and "type" fields of the span.
This patch is just to get things working again. dahdi_dynamic devices *may*
still have issues if the auto_assign_spans module parameter is 0.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10563 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is needed because dev_name() is mapped to kobject_name() in a backport,
but the kobject name isn't set until after device_add(). The result would be
parentless devices would fail since dahdi would not think a name was set for
these devices.
For these systems, we'll set both the bus_id string and the underlying
kobject_name.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10561 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In addition to updating the year, this also adds some boilerplate to
dahdi-sysfs.c and dahdi-sysfs-chan.c that wasn't there previously.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10560 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Will allow the ASPM (Active State Power Management) state to be disabled on
PCIe devices before kernel version 2.6.25.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10556 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This patch removes support for kernel versions < 2.6.18, as those are
not actively supported in any major Linux distribution (except RHEL4,
which is in the "extended" support level of the product life cycle).
This removes much of the more #ifdef-rich parts of the code.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10472 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Commit de47725, first released in 3.2-rc1 removed module.h from some
kernel headers. Include it explicitly now.
Resolves compilation errors like:
error: implicit declaration of function 'try_module_get'
error: 'THIS_MODULE' undeclared (first use in this function)
error: implicit declaration of function 'module_put'
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10361 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Added dahdi_dev_dbg() macro to print when we don't (yet)
have a span number.
* Added a new debug category: DAHDI_DBG_ASSIGN
* Made sure error return code paths prints helpfull messages
* Promote error messages from INFO to NOTICE
* Change some errno values from EINVAL to EFAULT (internal
errors not caused by user input)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10328 a0bf4364-ded3-4de4-8d8a-66a801d63aff
For some boards, the linemode (E1/T1/J1) is software selectable but
needs to be configured before the spans were historically registered
since the line mode determines the channel count available on the span.
This change exports a "spantype" attribute from the dahdi_device that
can be used to set E1/T1/J1 before the spans are assigned. When
userspace writes to this attribute (in a <span offset>:<span type
string> format), and if the board driver has implemented a set_spantype
function in it's dahdi_span_ops, then the board driver can optionally
change it's mode before registration.
Also part of this change is breaking out the raw data structure
initialization of the spans / channels via the dahdi_init_device_spans
function since the board drivers may need to reallocate channels / spans
as part of this callback. For example, changing from T1 to E1 mode will
require allocating 7 new channels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10277 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irqmisses' is more a function of the device and there are better ways
to get to IRQ for a device than storing it in any DAHDI structures.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10276 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This exposes dahdi devices in sysfs and also exposes attributes that
will allow user space to control the registration order in spans. This
facilitates loading drivers out of order yet keeping consistent
span/channel numbering, which in turn will eventually allow the
blacklist for DAHDI drivers to be removed. The default behavior,
controlled with the auto_register module parameter on dahdi is to number
the spans / channels in order like is currently done. So this change
does not introduce any new behavior by default.
* Writing (anything) to this attribute returns the span to its
unassigned state
* Fix dahdi_chan_unreg() echocan refcount
* Add safeguard against duplicate unassignment to _dahdi_unregister_span()
* Remove the span from device_node list, only in dahdi_unregister_device()
and not in dahdi_unregister_span()
* Free allocated span->span_device in span_sysfs_remove()
[is it safe?, didn't cause problem so far...]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi: Add "hardware_id" dahdi_device attribute.
- The "hardware_id" does not change with device location (e.g: when a PCI
card is moved from one slot to another).
- Not all devices have this attribute. It is legal for it to be NULL (that
is the default for all low-level drivers that do not set it explicitly).
- When "hardware_id" is NULL, the sysfs attribute value is "\n"
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10275 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change will facilitate creating rules that will allow spans and channels
to be accessed by named device files instead of by numbers.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10274 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Increasingly, spans are implemented by devices that support more than a
single span. Introduce a 'struct dahdi_device' object which explicitly
contains multiple spans. This will allow a cleaner representation of
spans and devices in sysfs since order of arrival will not determine the
layout of the devices. This also gives the core of dahdi a way to know
the relationship between spans.
This generalizes similar concepts that were previously xpp specific. The
conversion of the xpp code was almost entirely done by Oron and Tzafrir.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10273 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I only generally test on RHEL 4 when testing against kernels older
than 2.6.18. Apparently OpenSUSE 10.1 runs with 2.6.16 and doesn't
have WARN_ON_ONCE backported. I took the patch Richard Miller
originally attached to the issue and moved it to
include/dahdi/kernel.h so it would be available for all the board
drivers in the future.
Internal-Issue-ID: DAHLIN-260
Reported-by: Richard Miller
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10252 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Uses the linecompat member to determine what type of span it is. This will
allow removing T1/E1 flags from other places where the span type is stored.
This function also changes the return value from bool to int for the
inlines defined in include/dahdi/kernel.h. This is because not all
kernel versions include stdbool.h in the headers and it will conflict
with boolean values that are exported via module parameters on some
older kernels if dahdi included it globally.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10227 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The pr_ macros are the recommended way for subsystems to print messages
but not all kernel versions DAHDI support has them defined.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10226 a0bf4364-ded3-4de4-8d8a-66a801d63aff
HAVE_NET_DEVICE_OPS was defined in the mainline kernel in commit
47fd5b83 which was first released in 2.6.29. Any kernels after that will
have those fields defined.
Mainline commit e2270ea62ae4d7a removed the feature test macros, so
the easiest thing to do is define HAVE_NET_DEVICE_OPS ourselves on the
kernels since it was committed.
This change is needed to compile against the 3.1 kernel.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10109 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This reverts commit r9879. Asterisk commit r264249 [1], which was committed
after the switch to enumerations, requires the maintenance modes to be
Changing the test in configure.ac from:
AST_C_DEFINE_CHECK([DAHDI], [DAHDI_RESET_COUNTERS], [dahdi/user.h], [230])
to:
AST_C_COMPILE_CHECK([DAHDI], [int foo = DAHDI_RESET_COUNTERS], [dahdi/user.h])
Would allow the maintenance modes to stand as enumerations but the potential
for users to run incompatible versions does not seem worth it at this point.
[1] http://svnview.digium.com/svn/asterisk?view=revision&revision=264249
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10000 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Linux kernel v2.6.22 introduced the __packed macro to allow the gcc specific
__attribute__((packed)) extension to be overridden if required and
checkpatch.pl will complain if you don't use it.
For some strange reason gcc doesn't complain when you use non-existant
decorators.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9989 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Not quite ideal, but this seems to be the most straightforward way to
know when someone is trying to monitor the preec stream on a channel.
This callback allows the board driver providing the span an opportunity
to setup the hardware preecho monitoring as needed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9942 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_ec_chunk is the function that saves the received audio and places
a signed linear copy of it in the pre echocanceled buffer on the
channel. By splitting the input and output of this function into two
parameters, a driver that can provide separate pre and post ec streams
can pass them independently to DAHDI, without worrying about DAHDI
overwriting a stream that may have already been echocanceled by the
hardware.
Previously, the dahdi_ec_chunk interface took a received audio buffer
and overwrote it after canceling the echo. Now the input and output
from the function are broken up in order to support hardware echocans
that have a different preechocan stream.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9941 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change ensures that the dahdi_span_ops callbacks are not called
with any spinlocks held, and that the module is pinned in memory, and
also passes the struct file * pointer to the callbacks.
Passing the file pointer to the callbacks allows the board drivers to
check any flags on the file descriptor used to configure the
span/channel. The intent here is to allow dahdi_config to open the
/dev/dahdi/ctl file in a non-blocking mode in case there is a lengthy
processes that needs to happen as part of configuration.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9940 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'struct mutex' was introduced in 2.6.16. While DAHDI previously allowed
statically allocated mutexes, this change is required in order to allow
mutexes to be embedded in dynamically allocated structures on older kernels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9938 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Add BUFFEVENTS and individual buffer event channel flags so that DAHDI can
notify userspace processes when it is dropping data. This can be useful when
trouble shooting fax problems since DAHDI currently silently discards data
becasuse of scheduling latency. With this change, Asterisk could log an event
as opposed to just leaving it up to the tone detectors to figure out there was
some unexpected phase shift.
Acked-by: Shaun Ruffell <sruffell@digium.com>
(original patch by Matt Fredrickson)
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9905 a0bf4364-ded3-4de4-8d8a-66a801d63aff
RHEL 5.6 has backported dev_name in include/dahdi/devices.h. We now need to
check for a back ported definition before defining our own version on pre
2.6.26 kernels.
(closes issue #18992)
Reported by: ndupeux, AlexCeli
Tested by: elguero
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9894 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since cli/sti are expensive instructions, if the board drivers are
calling receive/transmit/ec_span from interrupt context all local
interrupts do not need to be disabled. The board drivers all still use
the normal dahdi_receive and dahdi_transmit. _dahdi_receive and
_dahdi_transmit are the "in-hardirq" versions of those functions.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9884 a0bf4364-ded3-4de4-8d8a-66a801d63aff
These drivers (all DAHDI drivers) should explicitly block suspend if they are
loaded.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9882 a0bf4364-ded3-4de4-8d8a-66a801d63aff
linux/kobject.h was removed from linux/fs.h in upstream commit 57cc721.
Add it back in in order to pick up the linux/kref.h include.
Reported-by: Raoul Bönisch <jkl345@alice-dsl.net>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9697 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Separate out device generation in dahdi_[un]register to separate
functions.
* As we don't keep anywhere the information of whether or not
* there's
an existing device node for a channel, I abuse an unused flag:
DAHDI_FLAGBIT_DEVFILE (25), to mark if the channel has a sysfs node.
DAHDI_FLAGBIT_DEVFILE is expected to be replaced later on with a proper
pointer to the device (or embedding of the device). I prefer a simple
flag for now as it does not break ABI.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9625 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The default tone lengths are compile time options and they were in
digits.h to make it easy for users to patch. Most of these settings are
potentially overridden from user space via the DAHDI_SET_DIALPARAMS
ioctl currently regardless of these settings.
In r9597 I moved digits.h directly into dahdi-base.c since I thought it
was broken out for sharing between compilation units as opposed to
ease patching.
I also changed the units of the default options to ms instead of in
samples. This way if the sampling frequency changes the user will not
need to update the defaults.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
asterisk-dev-reference: 4D236FD7.30707@digium.com
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9616 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When we're in monitor mode, we can save a pointer to the channel we are
monitoring directly instead of dereferencing the 'chans' array each
time.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9604 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This both removes the need to reference the 'chans'
__dahdi_process_putaudio_chunk and __dahdi_process_getaudio_chunk, and
allows the dahdi_receive / dahdi_transmit logic to be streamlined. DACS
channels can no longer be echocanceled if crossed. However, if a
channel was DACSed with dahi_cfg it couldn't have been echocanceled
anyway since the echo cancelers are disabled on the channel by default.
This change was originally contained in a patch kpfleming had floating
around. I split it up and merged it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Kevin P. Fleming <kpfleming@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9603 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Spans are no longer added to a static array, but they are chained
together in a list. DAHDI_MAX_SPANS, while no longer used in the
kernel, is still in include/dahdi/user.h since dahdi tools is currently
using it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9598 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change primarily is a memory reduction. Most users only ever have
a single tone zone loaded so we can save some mostly unused pointers by
using a list instead of an array. Since we also have a pointer to the
dahdi_zone in struct dahdi_chan, we also don't need to store the integer
that is an index into that array. This saves 4 bytes for every channel
allocated in the system. Finally, we don't need a separate default_zone
member since we're on a list, we can define the first element on
the list to always be the default zone.
Additionally, all reference counted structures in the drivers should
standardize on kref as much as possible for simplicity.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9594 a0bf4364-ded3-4de4-8d8a-66a801d63aff
kasprintf will be used in upcoming changes and it's not supported on
RHEL4 kernels. This change essentially backports it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9593 a0bf4364-ded3-4de4-8d8a-66a801d63aff
