Olej писал(а):Речь идёт о программировании модулей ядра Linux и реализации в этих модулях неоднозначной операции read_proc_t ... а заодно и write_proc_t.
Сделал я такой маленький заготовец-архивчик, тестовая площадка для отработки вариантов:
Здесь можно добавлять новые варианты read_proc_t, компилируя их как-то так:
Там есть уже 4 варианта... для
малых (
<3Kb объёмов считываемых данных)
Достаточно любопытно ... и достаточно неожиданно:
1. то, что уже рассматривалось, и из-за прототы я не стал его менять:
Код: Выделить всё
static char msg_short[ LEN_MSG + 1 ] =
".........1.........2.........3.........4.........5.........6\n";
static ssize_t proc_node_read( char *buffer, char **start, off_t off,
int count, int *eof, void *data ) {
int len = 0;
char *buf_msg;
LOG( "read: %d (buffer=%p, off=%ld, start=%p)", count, buffer, off, *start );
#if VARIANT == 0
// тупо копируем весь буфер, пока return не станет <= off
buf_msg = msg_short;
len = strlen( buf_msg );
strcpy( buffer, buf_msg );
LOG( "copy bytes: %d", len );
#endif
LOG( "return bytes: %d%s", len, *eof != 0 ? " ... EOF" : "" );
return len;
};
Код: Выделить всё
[olej@notebook variants]$ ./insm
Module Size Used by
mod_procr_3 1264 0
mod_procr_2 1224 0
mod_procr_1 1228 0
mod_procr_0 1192 0
fuse 48375 2
/proc/mod_node_0 /proc/mod_node_1 /proc/mod_node_2 /proc/mod_node_3
[olej@notebook variants]$ ./mcat 40 mod_node_0
read + 40 bytes, input buffer: .........1.........2.........3.........4
read + 21 bytes, input buffer: .........1.........2.........3.........4.........5.........6
read + 00 bytes, input buffer: .........1.........2.........3.........4.........5.........6
[olej@notebook variants]$ dmesg | tail -n15 | grep !
! read: 40 (buffer=f4042000, off=0, start=(null))
! copy bytes: 61
! return bytes: 61
! read: 40 (buffer=f4042000, off=40, start=(null))
! copy bytes: 61
! return bytes: 61
! read: 19 (buffer=f4042000, off=61, start=(null))
! copy bytes: 61
! return bytes: 61
! read: 40 (buffer=f4042000, off=61, start=(null))
! copy bytes: 61
! return bytes: 61
Это отправная точка.
Здесь вообще
никак не сигнализируется конец данных (конец файла) из кода реализации!
Решение о конце данных принимает скрытая реализация в ядре поддержки read_proc_t на основании того, что: возвращаемое значение (return) < (или <=?) чем переданное при вызове ранее значение off!
Совершенно дикая логика реализатора...
Остальные 3 варианта я нарисую чуть позже...