Блог

POSIX определяет текстовый файл как:

Файл, содержащий символы, организованные в одну или несколько строк.

POSIX определяет строку как

Последовательность из нуля или более символов, отличных от новой строки, плюс завершающий символ новой строки.

Учитывая это, должна ли read() функция драйвера символьного устройства Linux добавляться 'n' к пользовательскому буферу, когда он достигает EOF / не имеет больше данных?

Концепция драйверов символов аналогична потоку. В этом свете read просто возвращает все, что будет доступно дальше. Теперь то, что доступно, обычно будет частью определения устройства, драйвером которого оно является. Если устройство возвращает символ новой строки, то и драйвер должен это сделать. Обратите внимание, что это означает, что устройство вернет новую строку на всех платформах, а не только на Linux.

В общем, интерпретация байтов, возвращаемых read , является вопросом абстракции более высокого уровня. С точки зрения политики против механизма, драйвер символа можно рассматривать как предоставляющий механизм, оставляя политику на более высоких уровнях.

В классическом Unix разница между символьными устройствами и блочными устройствами заключается в том, что блочные устройства поддерживают поиск, что подразумевает, что они адресуемы в единицах дисковых блоков фиксированного размера. Символьные устройства не поддерживают поиск, они просто доставляют или принимают поток символов.

В Linux драйвер устройства реализован в виде структуры, содержащей некоторые флаги и параметры плюс набор указателей на функции, реализующих методы для чтения() / записи()/ и т.д. Драйверы блоков (дисков) также будут реализовывать seek() и, возможно, даже mmap().

Обычно драйверы устройств не мешают фактической передаче содержимого, они только перемещают байты или блоки на устройство / с устройства, используя (аппаратный) протокол, необходимый устройству (например, манипулирование регистрами внутреннего контроля, проверка регистров состояния, …)