users of drivers/misc/echo ?

users of drivers/misc/echo ?

[Dr. David Alan Gilbert]

Hi,
  I can't see anything that uses drivers/misc/echo - should it go or
is there something out of tree using it?

  I see where Greg moved it from staging into the main kernel
but am not seeing anything include the headers or call any of the symbols.

Dave
-- 
 -----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   |_______/

Re: users of drivers/misc/echo ?

[Arnd Bergmann]

On Sun, Feb 23, 2025, at 18:23, Dr. David Alan Gilbert wrote:
> Hi,
>   I can't see anything that uses drivers/misc/echo - should it go or
> is there something out of tree using it?
>
>   I see where Greg moved it from staging into the main kernel
> but am not seeing anything include the headers or call any of the symbols.

Good catch!

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

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.

Adding Harald to Cc, might know more about it.

       Arnd

Re: users of drivers/misc/echo ?

[Harald Welte]

Hi Arnd,

> Adding Harald to Cc, might know more about it.

thanks for Cc'ing me on this thread.

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.

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.

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@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Re: users of drivers/misc/echo ?

[Dr. David Alan Gilbert]

* Harald Welte (laforge@gnumonks.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@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   |_______/

Re: users of drivers/misc/echo ?

[Harald Welte]

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.

> 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.

-- 
- 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)

Re: users of drivers/misc/echo ?

[Dr. David Alan Gilbert]

* 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   |_______/

Re: users of drivers/misc/echo ?

[Arnd Bergmann]

On Tue, Feb 25, 2025, at 19:39, Dr. David Alan Gilbert wrote:
> * Harald Welte (laforge@gnumonks.org) wrote:

>
> 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
> ...

I took a look at the debian sources in
https://salsa.debian.org/pkg-voip-team/dahdi-linux/

Apparently the 'dahdi-linux' package contains a copy of
the oslec module, which it puts in a local drivers/staging/echo
directory.

It has done so since at least 2015 when the package moved
from subversion to git.

      Arnd

Re: users of drivers/misc/echo ?

[Harald Welte]

Hi Dave,

On Tue, Feb 25, 2025 at 06:39:06PM +0000, Dr. David Alan Gilbert wrote:
> > 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:

thanks, I didn't realize that.  You could reach out to the Debian maintainer of the package
if you'd want clarification.

-- 
- 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)

Re: users of drivers/misc/echo ?

[Dr. David Alan Gilbert]

* Harald Welte (laforge@gnumonks.org) wrote:
> Hi Dave,
> 
> On Tue, Feb 25, 2025 at 06:39:06PM +0000, Dr. David Alan Gilbert wrote:
> > > 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:
> 
> thanks, I didn't realize that.  You could reach out to the Debian maintainer of the package
> if you'd want clarification.

Given that Debian build etc - what's your preference?   I'm happy to
grind a patch to remove the kernel copy if Debian is using their own copy.
Or do we leave it and fix up Debian to use it?

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   |_______/

Re: users of drivers/misc/echo ?

[Harald Welte]

Hi Dave,

On Tue, Feb 25, 2025 at 10:04:07PM +0000, Dr. David Alan Gilbert wrote:
> * Harald Welte (laforge@gnumonks.org) wrote:
> > Hi Dave,
> > 
> > On Tue, Feb 25, 2025 at 06:39:06PM +0000, Dr. David Alan Gilbert wrote:
> > > > 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:
> > 
> > thanks, I didn't realize that.  You could reach out to the Debian maintainer of the package
> > if you'd want clarification.
> 
> Given that Debian build etc - what's your preference?   I'm happy to
> grind a patch to remove the kernel copy if Debian is using their own copy.
> Or do we leave it and fix up Debian to use it?

I've Cc'ed Tzafrir, the Debian maintainer of the DAHDI package.  Better to ask his
opinion directly rather than speculate about it.

Tzafrir: You can read this thread on lkml.org. The summary is that mainline Linux
is considering to remove drivers/misc/echo from the kernel source, as after removal
of mISDN there are no users of it left in mainline.

DAHDI doesn't build the dahdi_echocan_oslec by default, and the
Debian dahdi-linux DKMS seems to come with its own copy/version of the actual oslec
echo cancellation code rather than using the mainline one (which has migrated from
staging to misc a decade ago).

My opinion is that there's no reason mainline should keep drivers/misc/echo.

Regards,
	Harald

-- 
- 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)