допустим в системе есть
\dev\SPIdev0
как в контектсе Си будет выглядеть запрос и обмен по устройству SPI?
можно ли применить функции работы с файлами из стандартной библиотеки, если SPIdev0 - это файл?
требуется организовать в пользовательском приложении связь по SPI с подчинённым устройством в приложении
незнаю как подступиться

В первую очередь - смотреть документацию
http://lxr.free-electrons.com/source/Docum...tion/spi/spidev
http://lxr.free-electrons.com/source/Docum...pi/spidev_fdx.c
http://lxr.free-electrons.com/source/Docum...i/spidev_test.c

Вот по этой ссылке есть как раз подобный пример.

Во-первых, скорее всего имеется в виду /dev/spidevB.X,
где B - номер шины, X - номер Chip-Select'а.

Если требуетсмя half-duplex обмен данными, то тупо read()/write() из файла устройства. Если нужен full-duplex обмен данными, то это придётся делать через соответсвующий ioctl(). Ссылки на примеры выше уже привели.

Правильный метод - написать модуль ядра, который будет предоставлять userspace прриложению интерфейс через атрибуты sysfs или символьное устройство. Городить огород через spidev не очень светлая мысль, а если понадобится прерывание обрабатывать или GPIO дёргать? Будете /dev/mem мучать?

Интересно, можно подробнее об этом, что такое sysfs ?

Смотрите в исходниках Documentation/filesystems/sysfs.txt или поиском в гугл
Если коротко, то это виртуалньая файловая система, с помощью которой из userspace можно получить доступ к интерфейсам в ядре линукс.

Стандартно: через системные вызовы : open("/devspi"), ioctl("/devspi"), read("/devspi"), write("/devspi"), close("/devspi"), select("/devspi")
Все, что пишется ф-ей по write-: уходит в spi
Все, что читается по read- ,берется из буфера драйвера (ранее пришло из spi)
select("/devspi") - ожидание прихода данных по spi
можно организовать ввод/вывод не read()/write()?, а через ioctl()

Если кому интересно, можете почитать мои старые статьи на эту тему:
http://habrahabr.ru/blogs/linux/123145/
http://habrahabr.ru/blogs/linux/123266/
Может содержать некоторые ошибки, ибо когда писал, только начинал вникать в эту тему, но в целом понимание основных структур давать должно.
Что касается прриведённого там примера драйвера, то там для "полного счастья" следует все совместно используемые данные выносить в структуру с общей блокировкой.

Собственно никто не мешает включить поддержку в ядре gpio в sysfs. Через /dev/spidev можно вполне себе производить первоначальную отладку программы, религия это не запрещает, а в книге по Linux Device Drivers именно этот и описывается как опциональный первоначальный вариант разработки драйвера через userspace, т.к. имеется возможность использовать дебаггер и не перезагружать постоянно модули

"Модули ядра Linux" + с примерами того, что вам надо.