Linux – How does cat know the baud rate of the serial port

It looks like you might be a bit confused about how this all works.

First, /dev/ttyACM0 does not represent the USB link, or even the USB endpoint for whatever serial adapter you have connected, it represents the UART inside the adapter that handles the serial communications. Data you read from it will not include any USB headers or framing, just like data you read from /dev/ttyS0 will not include any PCI Express headers or framing. Setting the baud rate on these affects the hardware that it represents, not the bus it's connected to, so this won't do anything to the USB connection.

Second, the baud rate is a hardware setting, not a software one. When you call stty to set it on a serial port, that is telling the kernel to tell the hardware to change what baud rate it is trying to receive data at. This means in particular that any data that was received prior to this change will either be bogus (because it wasn't interpreted correctly by the hardware, sometimes the case if the baud rates are close to each other or exact harmonics), or completely lost (because the hardware just didn't accept it, the more likely case on modern hardware).

If you plan on reading data from a serial line, you need to have the baud rate set correctly prior to any data being transmitted by the other end. This also means that changing the baud rate won't change how the kernel interprets the data. If the data is already buffered in the kernel, then it's not going to change just because you change the baud rate (although it is good practice after changing the baud rate to drain the kernel buffers so that you know any future data is good).

So, to clarify, the correct method to get data out of a USB to serial adapter without using special software is to:

1. Set the baud rate during system startup. For a USB to serial adapter, this should probably be a udev rule so that it gets set when the device gets plugged in too.
2. Use cat (or od if you need the byte values instead of text) to read data. This will return the exact data that is received by the USB to serial adapter (assuing the adapter doesn't do special processing).

The line discipline controls handling of special characters (like software flow control, or characters generating signals) over the "line" (i.e., electrical wire in early unix systems). There are several possible line disciplines, and the tty driver calls the line discipline responsible for that tty.

So it makes absolutely no sense to have a "virtual serial port" in front of the line discipline. Not in the first picture, and not in the second picture.

The line discipline in turn just calls other parts of the kernel (the serial port driver (USB, UART, whatever), or the emulator for a virtual console, etc.), and also gets called by the corresponding driver if characters arrive. So in some sense this is a "virtual switch" where you can hook in different components.

But there's no pair of serial port drivers that somehow simulate sending a byte as bits over the line with a certain speed, and then reassembling it from bits as a byte. Because that would be unnecessary slow, and doesn't give a functionality.

Nevertheless, you can set the baud rate, amount of stop bits etc. for all tty's. These parameters are just ignored by drivers that don't need them, like the virtual console.