ttyACM versus ttyUSB

ttyACM versus ttyUSB

[Alex Henrie]

Dear kernel developers,

I am very curious and I haven't been able to find a definitive answer
anywhere: Why is the cdc-acm driver separate from the general
usbserial driver? There are lots of drivers that use usbserial, each
with its own unique protocol. What makes ACM so special that it needs
to be separated out as /dev/ttyACM* instead of going with everything
else in /dev/ttyUSB*?

I can think of several possible reasons, but I'd really like to know
what reasons matter to the kernel architects/maintainers.

-Alex

Re: ttyACM versus ttyUSB

[Greg KH]

On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> Dear kernel developers,
> 
> I am very curious and I haven't been able to find a definitive answer
> anywhere: Why is the cdc-acm driver separate from the general
> usbserial driver? There are lots of drivers that use usbserial, each
> with its own unique protocol. What makes ACM so special that it needs
> to be separated out as /dev/ttyACM* instead of going with everything
> else in /dev/ttyUSB*?
> 
> I can think of several possible reasons, but I'd really like to know
> what reasons matter to the kernel architects/maintainers.

cdc-acm implements the USB specification for that protocol, which is
defined by the USB group.  All of the usb-serial drivers do NOT follow
that protocol and use their own vendor-specific ways of talking to the
device.

Hope this helps,

greg k-h

Re: ttyACM versus ttyUSB

[Alex Henrie]

On Sun, Oct 12, 2025 at 12:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> > Dear kernel developers,
> >
> > I am very curious and I haven't been able to find a definitive answer
> > anywhere: Why is the cdc-acm driver separate from the general
> > usbserial driver? There are lots of drivers that use usbserial, each
> > with its own unique protocol. What makes ACM so special that it needs
> > to be separated out as /dev/ttyACM* instead of going with everything
> > else in /dev/ttyUSB*?
> >
> > I can think of several possible reasons, but I'd really like to know
> > what reasons matter to the kernel architects/maintainers.
>
> cdc-acm implements the USB specification for that protocol, which is
> defined by the USB group.  All of the usb-serial drivers do NOT follow
> that protocol and use their own vendor-specific ways of talking to the
> device.

OK, so it's just a matter of policy that drivers for standard USB
protocols name the device nodes differently than drivers for
vendor-defined USB protocols do?

-Alex

Re: ttyACM versus ttyUSB

[Greg KH]

On Sun, Oct 12, 2025 at 09:55:27AM -0600, Alex Henrie wrote:
> On Sun, Oct 12, 2025 at 12:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> > > Dear kernel developers,
> > >
> > > I am very curious and I haven't been able to find a definitive answer
> > > anywhere: Why is the cdc-acm driver separate from the general
> > > usbserial driver? There are lots of drivers that use usbserial, each
> > > with its own unique protocol. What makes ACM so special that it needs
> > > to be separated out as /dev/ttyACM* instead of going with everything
> > > else in /dev/ttyUSB*?
> > >
> > > I can think of several possible reasons, but I'd really like to know
> > > what reasons matter to the kernel architects/maintainers.
> >
> > cdc-acm implements the USB specification for that protocol, which is
> > defined by the USB group.  All of the usb-serial drivers do NOT follow
> > that protocol and use their own vendor-specific ways of talking to the
> > device.
> 
> OK, so it's just a matter of policy that drivers for standard USB
> protocols name the device nodes differently than drivers for
> vendor-defined USB protocols do?

These drivers are decades old, originally written in 1999 and handled
different hardware types so they got different device nodes.  Just like
many different serial drivers today have different named device nodes,
it was just following that well-known practice at the time.

And that practice continues today, when people write new serial/tty
drivers, they usually name the device nodes something new, much to many
of us arguing that maybe they shouldn't do that and they should learn
from our past history :)

Also, cdc-acm does not support as wide of a range of devices as the
usb-serial driver does, which can handle multiple-port devices and full
hardware line controls, which cdc-acm can not as it's not part of the
spec for that protocol.

There was a time that cdc-acm almost did not become a specification due
to internal arguments at USB-IF, which is why the usb-serial devices all
were using custom vendor protocols first, before cdc-acm eventually got
ratified.

Hope this helps,

greg k-h

Re: ttyACM versus ttyUSB

[Alex Henrie]

On Sun, Oct 12, 2025 at 10:21 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Oct 12, 2025 at 09:55:27AM -0600, Alex Henrie wrote:
> > On Sun, Oct 12, 2025 at 12:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> > > > Dear kernel developers,
> > > >
> > > > I am very curious and I haven't been able to find a definitive answer
> > > > anywhere: Why is the cdc-acm driver separate from the general
> > > > usbserial driver? There are lots of drivers that use usbserial, each
> > > > with its own unique protocol. What makes ACM so special that it needs
> > > > to be separated out as /dev/ttyACM* instead of going with everything
> > > > else in /dev/ttyUSB*?
> > > >
> > > > I can think of several possible reasons, but I'd really like to know
> > > > what reasons matter to the kernel architects/maintainers.
> > >
> > > cdc-acm implements the USB specification for that protocol, which is
> > > defined by the USB group.  All of the usb-serial drivers do NOT follow
> > > that protocol and use their own vendor-specific ways of talking to the
> > > device.
> >
> > OK, so it's just a matter of policy that drivers for standard USB
> > protocols name the device nodes differently than drivers for
> > vendor-defined USB protocols do?
>
> These drivers are decades old, originally written in 1999 and handled
> different hardware types so they got different device nodes.  Just like
> many different serial drivers today have different named device nodes,
> it was just following that well-known practice at the time.
>
> And that practice continues today, when people write new serial/tty
> drivers, they usually name the device nodes something new, much to many
> of us arguing that maybe they shouldn't do that and they should learn
> from our past history :)
>
> Also, cdc-acm does not support as wide of a range of devices as the
> usb-serial driver does, which can handle multiple-port devices and full
> hardware line controls, which cdc-acm can not as it's not part of the
> spec for that protocol.
>
> There was a time that cdc-acm almost did not become a specification due
> to internal arguments at USB-IF, which is why the usb-serial devices all
> were using custom vendor protocols first, before cdc-acm eventually got
> ratified.

Ah, so the name ttyACM is a historical accident, from the time when it
was the norm to use different device node names in different serial
drivers.

I did notice that the ACM protocol has no way to set the baud rate or
read the CTS line and I wondered if those limitations were the reason
for keeping its driver separate. Today there are ttyUSB drivers that
likewise have limitations on the baud rate and the flow control lines
(some are even based on ACM), but they weren't around in 1999, so I
can see how the difference in capabilities would have been another
motivation for the difference in naming conventions.

I did not know that there was controversy over including ACM in the
USB specification in the first place. An unsettled specification
combined with the limitations of the ACM protocol explains why FTDI
and others developed their own protocols.

Thank you very much for the history lesson!

-Alex

Re: ttyACM versus ttyUSB

[Greg KH]

On Sun, Oct 12, 2025 at 01:01:00PM -0600, Alex Henrie wrote:
> On Sun, Oct 12, 2025 at 10:21 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Sun, Oct 12, 2025 at 09:55:27AM -0600, Alex Henrie wrote:
> > > On Sun, Oct 12, 2025 at 12:07 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Sat, Oct 11, 2025 at 11:00:00PM -0600, Alex Henrie wrote:
> > > > > Dear kernel developers,
> > > > >
> > > > > I am very curious and I haven't been able to find a definitive answer
> > > > > anywhere: Why is the cdc-acm driver separate from the general
> > > > > usbserial driver? There are lots of drivers that use usbserial, each
> > > > > with its own unique protocol. What makes ACM so special that it needs
> > > > > to be separated out as /dev/ttyACM* instead of going with everything
> > > > > else in /dev/ttyUSB*?
> > > > >
> > > > > I can think of several possible reasons, but I'd really like to know
> > > > > what reasons matter to the kernel architects/maintainers.
> > > >
> > > > cdc-acm implements the USB specification for that protocol, which is
> > > > defined by the USB group.  All of the usb-serial drivers do NOT follow
> > > > that protocol and use their own vendor-specific ways of talking to the
> > > > device.
> > >
> > > OK, so it's just a matter of policy that drivers for standard USB
> > > protocols name the device nodes differently than drivers for
> > > vendor-defined USB protocols do?
> >
> > These drivers are decades old, originally written in 1999 and handled
> > different hardware types so they got different device nodes.  Just like
> > many different serial drivers today have different named device nodes,
> > it was just following that well-known practice at the time.
> >
> > And that practice continues today, when people write new serial/tty
> > drivers, they usually name the device nodes something new, much to many
> > of us arguing that maybe they shouldn't do that and they should learn
> > from our past history :)
> >
> > Also, cdc-acm does not support as wide of a range of devices as the
> > usb-serial driver does, which can handle multiple-port devices and full
> > hardware line controls, which cdc-acm can not as it's not part of the
> > spec for that protocol.
> >
> > There was a time that cdc-acm almost did not become a specification due
> > to internal arguments at USB-IF, which is why the usb-serial devices all
> > were using custom vendor protocols first, before cdc-acm eventually got
> > ratified.
> 
> Ah, so the name ttyACM is a historical accident, from the time when it
> was the norm to use different device node names in different serial
> drivers.

It wasn't an "accident", it was on purpose at the time.

> I did notice that the ACM protocol has no way to set the baud rate or
> read the CTS line and I wondered if those limitations were the reason
> for keeping its driver separate. Today there are ttyUSB drivers that
> likewise have limitations on the baud rate and the flow control lines
> (some are even based on ACM), but they weren't around in 1999, so I
> can see how the difference in capabilities would have been another
> motivation for the difference in naming conventions.

Yes, baud rate and line control is important for the usb-serial devices
that were real serial ports.  The ACM protocol did not want to implement
those for various reasons best discussed over your favorite beverage :)

thanks,

greg k-h

Re: ttyACM versus ttyUSB

[Alex Henrie]

On Sun, Oct 12, 2025 at 1:54 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Oct 12, 2025 at 01:01:00PM -0600, Alex Henrie wrote:

> > Ah, so the name ttyACM is a historical accident, from the time when it
> > was the norm to use different device node names in different serial
> > drivers.
>
> It wasn't an "accident", it was on purpose at the time.

Yes, that's what I was trying to say. By "historical accident" I meant
"It seemed like a good idea at the time, and it's not worth changing now."

> > I did notice that the ACM protocol has no way to set the baud rate or
> > read the CTS line and I wondered if those limitations were the reason
> > for keeping its driver separate. Today there are ttyUSB drivers that
> > likewise have limitations on the baud rate and the flow control lines
> > (some are even based on ACM), but they weren't around in 1999, so I
> > can see how the difference in capabilities would have been another
> > motivation for the difference in naming conventions.
>
> Yes, baud rate and line control is important for the usb-serial devices
> that were real serial ports.  The ACM protocol did not want to implement
> those for various reasons best discussed over your favorite beverage :)

If we ever bump into each other in person, I will take you up on that ;-)

-Alex

Re: ttyACM versus ttyUSB

[Oliver Neukum]

On 12.10.25 21:01, Alex Henrie wrote:

> I did notice that the ACM protocol has no way to set the baud rate or
> read the CTS line and I wondered if those limitations were the reason
> for keeping its driver separate. Today there are ttyUSB drivers that
> likewise have limitations on the baud rate and the flow control lines
> (some are even based on ACM), but they weren't around in 1999, so I
> can see how the difference in capabilities would have been another
> motivation for the difference in naming conventions.

You could argue that ACM is intended to be a driver for a _modem_ ,
not a serial line. In principle we are trying to propagate a layering
violation that is so old that we no longer see it as a violation.

	Regards
		Oliver

Re: ttyACM versus ttyUSB

[Vojtech Pavlik]

On Mon, Oct 13, 2025 at 11:28:59AM +0200, Oliver Neukum wrote:
> On 12.10.25 21:01, Alex Henrie wrote:
> 
> > I did notice that the ACM protocol has no way to set the baud rate or
> > read the CTS line and I wondered if those limitations were the reason
> > for keeping its driver separate. Today there are ttyUSB drivers that
> > likewise have limitations on the baud rate and the flow control lines
> > (some are even based on ACM), but they weren't around in 1999, so I
> > can see how the difference in capabilities would have been another
> > motivation for the difference in naming conventions.
> 
> You could argue that ACM is intended to be a driver for a _modem_ ,
> not a serial line. In principle we are trying to propagate a layering
> violation that is so old that we no longer see it as a violation.

The ttyACM driver is also older than the ttyUSB driver.

And yes, indeed, USB CDC ACM was intended as a class for USB modems, not
for serial ports, so it doesn't directly support pin twiddling.

One would assume that baud rate setting would also be unnecessary in
this usecase, yet, surprisingly enough, many of the early USB modems
absolutely failed to work unless a baud rate was explicitly set.
(USB_CDC_REQ_SET_LINE_CODING)

Today, some USB-serial chips have the ACM protocol, so perhaps it would
make sense to merge the drivers, I certainly would not object.

-- 
Vojtech Pavlik

Re: ttyACM versus ttyUSB

[Alex Henrie]

On Mon, Oct 13, 2025 at 4:47 AM Vojtech Pavlik <vojtech@suse.com> wrote:
>
> On Mon, Oct 13, 2025 at 11:28:59AM +0200, Oliver Neukum wrote:
> > On 12.10.25 21:01, Alex Henrie wrote:
> >
> > > I did notice that the ACM protocol has no way to set the baud rate or
> > > read the CTS line and I wondered if those limitations were the reason
> > > for keeping its driver separate. Today there are ttyUSB drivers that
> > > likewise have limitations on the baud rate and the flow control lines
> > > (some are even based on ACM), but they weren't around in 1999, so I
> > > can see how the difference in capabilities would have been another
> > > motivation for the difference in naming conventions.
> >
> > You could argue that ACM is intended to be a driver for a _modem_ ,
> > not a serial line. In principle we are trying to propagate a layering
> > violation that is so old that we no longer see it as a violation.
>
> The ttyACM driver is also older than the ttyUSB driver.
>
> And yes, indeed, USB CDC ACM was intended as a class for USB modems, not
> for serial ports, so it doesn't directly support pin twiddling.
>
> One would assume that baud rate setting would also be unnecessary in
> this usecase, yet, surprisingly enough, many of the early USB modems
> absolutely failed to work unless a baud rate was explicitly set.
> (USB_CDC_REQ_SET_LINE_CODING)

Oh, so there is a way to set the baud rate in ACM after all! I'm
flabbergasted that I missed that. What exactly are the limitations of
the ACM protocol compared to the vendor protocols then? It looks to me
like there's no way to turn hardware flow control on or off, and
there's no way to query the state of the CTS line. If the only
differences in capabilities have to do with hardware flow control,
that seems really minor in light of the fact that many serial devices
don't have hardware flow control lines at all.

> Today, some USB-serial chips have the ACM protocol, so perhaps it would
> make sense to merge the drivers, I certainly would not object.

It is definitely confusing to have to think about whether your USB
serial device is going to appear as /dev/ttyUSB* or /dev/ttyACM*. On
the other hand, if we renamed the ttyACM device nodes to ttyUSB to
reflect the fact that ACM is just another USB serial protocol, how
many things would that break? In general I like making things make
sense, but I'm hesitant to be the one to pull the trigger.

-Alex

Re: ttyACM versus ttyUSB

[Greg KH]

On Mon, Oct 13, 2025 at 09:42:38AM -0600, Alex Henrie wrote:
> > Today, some USB-serial chips have the ACM protocol, so perhaps it would
> > make sense to merge the drivers, I certainly would not object.
> 
> It is definitely confusing to have to think about whether your USB
> serial device is going to appear as /dev/ttyUSB* or /dev/ttyACM*. On
> the other hand, if we renamed the ttyACM device nodes to ttyUSB to
> reflect the fact that ACM is just another USB serial protocol, how
> many things would that break? In general I like making things make
> sense, but I'm hesitant to be the one to pull the trigger.

Yeah, we can't really do that now, sorry.  Too many chances to break
userspace.

If you want to always get this right, just use the symlinks in
/dev/serial/ to find the proper device easier.

greg k-h