mjhjmtu

Is a device driver a program that runs on its own, or is it just a library (a group of functions) that is loaded in memory and programs can call one of its functions (so it is not running on its own).

And if it is a program, does it have a process ID, so can I for example terminate a device driver the same way I can terminate any other process?

On Linux, many device drivers are part of the kernel, not libraries or processes. Programs interact with these using device files (typically in /dev) and various system calls such as open, read, write, ioctl...

There are exceptions however. Some device drivers use a mixture of kernel driver stubs and user-space libraries (e.g. using UIO). Others are implemented entirely in user-space, usually on top of some bit-banging interface (UART or GPIO). In both cases, they’re generally in-process, so you won’t see a separate process, just the process that’s using the device.

To “terminate” a device driver, you’d have to stop all the processes using it, then remove its kernel modules (assuming it’s built as modules), and optionally any other modules it uses and which are no longer necessary. You can list the modules on your system using lsmod, and unload them using rmmod or modprobe -r, both of which will only work if lsmod indicates they have no users.

You first have to define what a driver is. I'll define it as a program or subroutine that controls a device (like your camera) or a subsystem (like a file system). Whether it does it directly via the system program or via kernel servers or user-land processes shouldn't in principal matter to this essentially semantic question.

In some cases Linux only provides a generic protocol written in software where the actual "driver" is a device tree. That is a configuration of hardware parameters and which software to use that make up a driver.

Generally speaking driver interfaces and protocols are implemented using kernel modules which are loaded as needed defined by device trees or udev rules. A kernel module is not in the strictest sense a process or library.

A library is just a static set of code that can be loaded into any given process. Modern operating systems load these libraries into shared memory. A process can itself link to any number of shared libraries.

A process is a running program in which the system program or kernel has allocated resources such as system memory and cpu time. Kernel modules may or may not follow this pattern themselves but regardless are not regarded as a defacto processes under Linux.

So to answer your question a driver need not be process but it can be. While the code can exist in a library the driver is still loaded into memery via a program whether it be the kernel in the form of kernel modules or userland processes.

It becomes more of a semantic argument when considering what the totality of a driver actually is. You could say a driver is always a program but sometimes its not like in the case of device trees also it could actually be a userland process, device tree file, udev rules and kernel module where the process and module both use libraries all to make up the logic of a driver.