All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: Harald Welte <laforge@gnumonks.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, david@rowetel.com
Subject: Re: users of drivers/misc/echo ?
Date: Tue, 25 Feb 2025 18:39:06 +0000	[thread overview]
Message-ID: <Z74OSsZqeboJml9c@gallifrey> (raw)
In-Reply-To: <Z73MevharqkC5dt8@nataraja>

* Harald Welte (laforge@gnumonks.org) wrote:
> Hi Dave, Arnd, Greg,
> 
> On Tue, Feb 25, 2025 at 01:01:06PM +0000, Dr. David Alan Gilbert wrote:
> > > However, those DAHDI-using deployments that I personally am familiar
> > > with do not use the software echo canceller discussed here.  On the
> > > other hand, I'm quite certain that there are many PBX/IVR related
> > > systems out there (unrelated to my area of cellular or trunked radio)
> > > that would still use the echo canceller discussed here.
> 
> I have to correct myself here:  "that would still use software echo cancellation".
> 
> As I stated before, in "my" deployments, the echo canceller is not used
> and hence I'm not super familiar with it.  My use cases either don't
> need echo cancellation, or use hardware echo cancellation.
> 
> Revisiting the DAHDI source code as a result of this thread: There are
> actually several different software echo cancellation implementations,
> only one of which (oslec) is using the drivers/misc/echo.
> 
> > Some questions:
> > 
> > 1) I see drivers/dahdi/dahdi_echocan_oslec.c
> > 
> > /* Fix this if OSLEC is elsewhere */
> > #include "../staging/echo/oslec.h"
> > //#include <linux/oslec.h>
> > 
> > now that moved to drivers/misc in 2014 by Greg's
> > 6e2055a9e56e ("staging: echo: move to drivers/misc/")
> > 
> > So is most of this on ancient kernels or do people
> > actually use modern stuff?
> 
> Actually, looking at DAHDI, I really don't think anyone is still using
> the dahdi_echocan_oslec code.  It is disabled by default and only built
> if explicitly enabled by the user, and indeed if anyone did that it
> would fail to build for any kernels that have moved it out of staging.

It looks like Debian is including and enabling it in it's DKMS build:

# apt install dahdi-dkms
...
dahdi_echocan_oslec.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/6.1.0-31-amd64/updates/dkms/
...
# nm /lib/modules/6.1.0-31-amd64/updates/dkms/dahdi_echocan_oslec.ko
...
                 U oslec_create
                 U oslec_free
                 U oslec_update
...

> > 2) I see there is a fir.h that's different from the kernels
> > drivers/misc/echo/fir.h  doesn't that cause problems?
> > Should one get updated from the other somehow?
> 
> I'll not investigate that given the above determination.
> 
> > 3) Any idea why it's never been upstreamed?
> 
> I can only speculate, but I guess it was never a strong priority for the authors,
> and indeed likely the code would have had to undergo quite some changes.
> 
> DAHDI is clearly well beyond its peak user base these days, and I would
> expect the amount of effort into mainlining it, together with the
> associated risk of introducing bugs during required refactoring simply
> doesn't make it an attractive proposition.  Also, given that userspace
> applications for it have been around for decades, it would be impossible
> to address any upstreaming related change requests without rendering
> those applications incompatible.
> 
> So I'd really not bother at this point anymore.  The few adjustments
> I/we had to make to keep it building + working with recent kernels over
> the past few years are minimal, and mostly trivial stuff like minor
> kernel API changes.  In the end, DAHDI doesn't interact with a lot of
> other kernel.  It talks to the hardware via its own device drivers, and
> it talks to userspace programs via character devices.  So unless some
> core kernel memory allocator, or PCI or USB device drive APIs or
> character device API changes, we're mostly good.

OK.

Dave

> -- 
> - Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

  reply	other threads:[~2025-02-25 18:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-23 17:23 users of drivers/misc/echo ? Dr. David Alan Gilbert
2025-02-23 20:38 ` Arnd Bergmann
2025-02-25 12:33   ` Harald Welte
2025-02-25 13:01     ` Dr. David Alan Gilbert
2025-02-25 13:58       ` Harald Welte
2025-02-25 18:39         ` Dr. David Alan Gilbert [this message]
2025-02-25 19:02           ` Arnd Bergmann
2025-02-25 19:08           ` Harald Welte
2025-02-25 22:04             ` Dr. David Alan Gilbert
2025-02-26  7:12               ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z74OSsZqeboJml9c@gallifrey \
    --to=linux@treblig.org \
    --cc=arnd@arndb.de \
    --cc=david@rowetel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.