Постановката е следната - линукс система (х86) с кърнел 3.нещо си. Има си файлова система и всичко стандартно.
Към него е закачен по някакъв интерфейс (да кажем за простота SPI) е изграден транспорт на съобщения (пакети) към друг микроконтролер (арм), като през него могат да се тунелират произволни съобщения (протоколи).
Търси се лесен начин малкия микроконтролер да получи достъп до файловата система на големия. За целта ще трябва софтуер в линукса и такъв във арм-а. Едната опция е да се дефинира нов протокол който да прехвърля нещо като fopen, fread, fwrite, fclose, fseek и подобни, и реално да получим нещо като RPC до file функциите на хоста.
Дайте идеи за да не откривам топлата вода.

До цялата файлова система ( / ) на големия ли трябва да има достъп или до някаква директория ще е достатъчно (примерно до /mnt/smallarm ) ?

Другия важен въпрос е и двата процесора ли ще трябва да пишат на това споделено място или само единия от тях (и кой)?

Принципно до цялата, вкл. /dev, /tmp и подобни. В смисъл не е идеята малкия да внася някакви данни, а да може да редактира съществуващи файлове, вкл. триене, подмяна и т.н.
Дали и двата - да, и двата, но не едновременно - да приемем че файловете които "редактира" малкия ще се ползват от големия на следващия рестарт.
Целта е малкият да може да достави файлове за ъпдейт на големия (на следващия рестарт), както и да може да се сменя конфигурация на големия през малкия. За пояснение малкият е вързан навън през друг специфичен интерфейс. Само този интерфейс е достъпен отвън (извън машината) и само през него може да се прави достъпа за конфигуриране и ъпдейт.
Реално идеята е да има някакво "прокси" дето тича на линукса и получава данните от малкия (пакетите) и да прави викането на локалните (в линукса) функции.
Може би достъп до шел-а на линукса от малкия ще е работеща кръпка, но никак не обичам ascii интерфейсите между процесори.
Друга алтернатива да се погледне на тоя проблем е да се даде RPC достъп до линукските функции които да се ползва от малкото добиче.

Сещам се за следното:

Във файловата система на PC-то правиш един файл с дисков имидж на FAT32 файлова система. Този имидж можеш винаги да го маунтнеш и да прочетеш/запишеш каквото трябва и пак да го размаунтнеш. Вътре в тази файлова система си правиш поддиректории за каквото ти трябва - примерно /update, /settings, /logs и т.н.

През останалото време за да може малкия да чете/пише на този виртуален диск ти трябват две неща:

първото е да си напишеш за ARM-а твои версии на 6-те функции от Device Control Interface към FatFs, така че да комуникират с PC-то и то да ги изпълнява върху имидж файла.

второто е програмката за PC-то (daemon) която да изпълнява 6-те функции.

Най-накрая ще ти трябват някакви скриптове, които след рестарт на PC-то да изпълняват това, което малкия е натворил във виртуалния диск - примерно ако в /settings има нещо ново - то да се изкопира или добави където трябва, ако в /update има нов фърмуер - да се флашне и т.н.

То идеята е че отдавна си ги има направени нещата които при рестарт правят ъпдейта и използват конфигурационните файлове, но редактирането на файловете ставаше през ftp/scp. Т.е. там промяна не може да има.
Реално директният вариант е къстъм протокол който просто да вика fopen/fread/fwrite от другата страна - т.е. демон в линукса който като получи тези неща по "SPI"-а да извика самите функции и да прати обратно данните. Самите пакети за достъп (протокола по жицата) ще отразява аргументите на функциите и връщаните данни - например името на файла (пътя) в пакета за open, данните в write и т.н. Това е ясно и лесно.
Мисълта ми е дали има по-дълбок RPC протокол който да даде достъп до файловия интерфейс, но и да може в бъдеще да се ползва за други неща, например reboot, викане на други шел команди и инструменти и т.н.. Като писах за директен достъп до шел-а това имах предвид - че ако си го пусна така ще мога да реализирам каквото реша в бъдеще, и то само с допълване на кода в малкия процесор (това би било сериозен плюс). Само че ще е добре да е нещо бинарно за да е ефективно.
Ако приемем шел достъпа за приемливо решение за момента, какви са ми опциите да отворя програмно конзола и да си говоря с нея от моето приложение (в линукса)? Правил съм подобни работи през python, сигурно и през C ще е подобно, но дали има нещо (полу-)готово?

OBEX

API функциите на FatFs са доста на брой и всяка с различни структури данни и т.н. Device Control интерфейса е само от 6 функции, от които 3 имат да предават блок от данни, а останалите 3 връщат по една стойност. Кое колко е лесно да се направи - ти си знаеш...

Линукса има серийна конзола, която обаче работи само със стандартен асинхронен сериен порт (RS232). Не ми е известно да може да работи по SPI. Ако ти е толкова важно да имаш шел-достъп до Линукса - можеш да си направиш твоя версия на getty или agetty, така че да работи и по SPI.

(s)ftp по сериен? мислиш си за серийния като за вечно отворен сокет и действаш, може да си сложих едно ниво на абстракция което да слага чек суми за надежност, та даже и порт номер може да добвиш, така по един сериен можеш да прекараш колкото си искаш "сокета"... хм от там нататък и NFS можеш да си подкараш в тоя ред на мисли май си има стандартни решения, търси нещо от сорта tcp/ip over uart, излизат някакви работи. Ако са ти наблизко ЦПУтата УАРТа може да го пуснеш на мегабит и повече така че скоростта ще се ядва.

Аз май си намерих каквото ми трябва, поне ми изглежда много близко до моето виждане:
https://www.arduino.cc/en/Reference/YunBridgeLibrary
Шел и файлов достъп и други подобни.

rsh ? Виж как е направено на BBB

Мерси за идеята - но това не е ли просто прехвърляне на "текста" през TCP? Принципно това беше единият вариант описан горе, но ме отблъсква ASCII комуникацията, която се очаква да върви отдолу. Може и да бъркам, но така ми се струва че ще да е имплементирано в този rsh.

Едит: една от функциите на ардуинския bridge е да дава na AVR достъп до конзолата на OpenWRT-то. Принципно това е достатъчно, но те са добавили и отделни улеснение за файлов достъп и други.

Може и по сериен канал да прехвърляш, или по USB, не знам дали е чисто ASCII отдолу. На BBB е май UART към USB конвертор, трябва да погледна в документите им.

Мисълта ми е, че ако използваш нещо като rsh, то ще работи на всяка Linux дистрибуция. Освен това, а може би и най-важното, е че можеш да го пуснеш върху SSH и ще имаш винаги защитена комуникация, ще има и пълноценни log файлове за кой кога се е логвал и какво е променял по системата. Единствено ще имаш писане на код за микроконтролера, от страната на Linux практически всичко ти е готово, и тъй като rsh е основен инструмент, то всяка дистрибуция го има, т.е. нищо не пипаш по Linux системата... Почти съм сигурен, че някой вече е разписал rsh за еmbedded Linux или bare metal система, потърси, все ще излезне нещо