linux-kernel - Re: users of drivers/misc/echo ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z72_EnXyHoDACRk5@gallifrey>
Date: Tue, 25 Feb 2025 13:01:06 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Harald Welte <laforge@...monks.org>
Cc: Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, david@...etel.com
Subject: Re: users of drivers/misc/echo ?

* Harald Welte (laforge@...monks.org) wrote:
> Hi Arnd,
> 
> > Adding Harald to Cc, might know more about it.
> 
> thanks for Cc'ing me on this thread.

Hi Harald,
  Thanks for the reply.

> On Sun, Feb 23, 2025 at 09:38:12PM +0100, Arnd Bergmann wrote:
> > I don't see any in-tree users for it either, but I found one
> > project using the exported symbols, and there is a debian
> > package for it as well:
> > 
> > https://tracker.debian.org/pkg/osmocom-dahdi-linux
> > https://gitea.osmocom.org/retronetworking/dahdi-linux/src/branch/master/drivers/dahdi/dahdi_echocan_oslec.c#L34
> 
> Note: The official upstream of DAHDI is maintained as part of the Asterisk soft switch project,
> the Osmocom fork has just become more popular in recent years due to very slow maintenance of
> upstream.
> 
> Any of the DAHDI forks is used in production deployments by a number of
> different telephony / softswitch / telecom software projects (like
> Asterisk, FreeSWITCH, yate or many osmocom sub-projects) in order to
> interface with classic anaolog or TDM (time division multiplex)
> telephony technology.  
> 
> Even today this TDM technology (most likely in most instances without
> open source softswitches) is still relevant in commercial production
> deployments, including many (but not all) cellular carriers
> around the world, but for example also as part of GSM-R (railway
> communications systems) for at least until 2035.  I personally also know
> of present-day production deployments in satellite telephony
> infrastructure.
> 
> 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.
> 
> In any case, for this discussion, it doesn't matter, as all DAHDI
> flavours make use of the same API function.
> 
> > With our normal rules, we should just remove it as there is no
> > way to use the code without external modules, but I don't know
> > how we even got to this state.
> 
> I'd expect the echo cancellation code was used by mISDN for as long as
> that was still in upstream.  As mISDN has (sadly, but understandably)
> been removed, the echo canceller likely remained in the tree without any
> other in-tree users.

OK.

> DAHDI has been using the in-kernel echo canceller for decades.  If it's
> removed now, it will likely mean that DAHDI will carry a copy of it and
> selectively compile that as out-of-tree module for future kernel
> versions.

Well, it's a bit odd - but if it's actively used it's not terrible.
(I guess there are kernel drivers that are fully usable that are never used!)

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?

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?

3) Any idea why it's never been upstreamed?
  I guess the problem is that dahdi-base.c is quite a chunk and
that would have to go in to take any of the useful other bits.
Oh hmm, and a whole bunch hasn't got signed-off's so it's
very hard.

Dave


> I personally wouldn't see that as a big problem, as DAHDI itself has
> always been out-of-tree anyway, and adding one more module to that is
> not a big deal.  Note that I cannot speak officially for the DAHDI
> project as I'm just maintaining the Osmocom fork.
> 
> Kind regards,
> 	Harald
> -- 
> - Harald Welte <laforge@...monks.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   |_______/