1

I need to write a new character device file for the UART, which allows a few more file operations than usually allowed (not just open, write, etc..)

I'm on an embedded mainline linux kernel (v 5.4).

I started looking at the UART drivers and notice there are many things:

  1. First, there are a lot of tty files. I know that tty stands for Teletypewriter. I don't think it's a piece of hardware.
  2. Then, there is the specific driver for my processor, which handles interrupts on UART.
  3. Then, there is (what I believe to be) the character device driver for uart, written in serial_core.c

I remarked that serial_core.c doesn't have a file operations struct, but uses a tty_operations.

What is happening here? I cannot understand how all these files are related to each other, what do they really do. More precisely, I would like to understand the role of each one of them. I'm tasked to write a character device driver for the uart but I do not know which one of these files (maybe all?) would my driver have to substitute.

Thanks,

Mölp
  • 31
  • 3
  • "Few more file operations.."? It is difficult to imagine there is anything new to say about UART that nobody ran into before. Typically, the ioctl() interface is used for everything that is outside the scope of stdio. `man ioctl` says "the call is used as a catch-all for operations that don't cleanly fit the UNIX stream I/O model". `man ioctl_list` shows over 600 defined operations for various device types. – Paul_Pedant Oct 14 '20 at 10:09
  • 1
    I need to add Out-of-band (OOB) operations that are analogue to the read and write default operations. The OOB is in the context of the Dovetail interface using the EVL core which is applied on top of the mainline kernel. I don't think these operations are defined anywhere for a normal linux kernel. – Mölp Oct 14 '20 at 10:23
  • For reference: https://evlproject.org/ – Mölp Oct 14 '20 at 10:23
  • For further clarification, the driver for the GPIO in EVL just adds the extra operations on the existing mainline driver. – Mölp Oct 14 '20 at 10:24
  • Maybe look at writing a tty line discipline? – Murray Jensen Oct 15 '20 at 14:01
  • @Murray Jensen What do you mean by that? I've looked it up what a line discipline is, but I am not sure that would help me to understand the relations between all these files. – Mölp Oct 20 '20 at 13:29
  • check out examples in the **[slip](https://elixir.bootlin.com/linux/latest/source/drivers/net/slip/slip.c#L1264)** driver, and others e.g. [this](https://elixir.bootlin.com/linux/latest/source/net/nfc/nci/uart.c#L454) - look at [tty_ldisc.c](https://elixir.bootlin.com/linux/latest/source/drivers/tty/tty_ldisc.c#L46) and [tty_ldisc.h](https://elixir.bootlin.com/linux/latest/source/include/linux/tty_ldisc.h#L175) - main struct of interest is [tty_ldisc_ops](https://elixir.bootlin.com/linux/latest/C/ident/tty_ldisc_ops). also read [this](https://www.kernel.org/doc/Documentation/serial/tty.rst) – Murray Jensen Oct 22 '20 at 12:45

1 Answers1

1

I now, after a long time reading, analysing and reading code again, came to understand the code which is very difficult to understand given the lack of comments.

The goal of all this is to create a communication interface between the user space and the hardwre. For this, we can imagine the model in two layers: A layer that connects the user space to the kernel space, and a layer that connects the kernel space to the hardware.

The layer connecting user to kernel space is a character device driver. This is the TTY layer, which will handle the file in /dev/ and get the data from the user and pass it to the kernel space and vice-versa. The TTY layer implements a lot of other things that I didn't quite understand, but it is safe to say that it's main goal is this.

Now the second layer is parting from kernel space to write on the hardware. This is done with a platform driver in the file imx.c. This driver knows the hardwre in detail, and can control it based on what it receives from TTY. Thus, TTY calls the functions from this layer based on what is being said by the user.

Since the UART is a somewhat generic hardware, there are numerous functions and routines that aren't very specific and can be grouped into a single file that is used as a base for developing platform drivers such as imx.c. This is the serial_core.c file, which works sort of like an API for the development of hardware specific drivers.

Mölp
  • 31
  • 3