Значи ситуацията е следната, ще правим нова версия на нашия продукт (ronetix.at - PEEDI), тъй като текущия хардуер е на възраст около 10 години.
Новото желязо със сигурност ще е АРМ на 400+ MHz, RAM 128+MB, FLASH 512+MB, т.е. система без проблем въртяща линукс.
Главната функционалност вероятно ще бъде мушната в едно юзер спейс приложение и даден брой драйвери отдолу.
Приложението в общия случай ще чака на наяколко ТСП порта за телнет и дебъг конекции. По телнета могат да се изпълняват юзер команди, а на дебъг порта се връзва gdb/eclipse.

Значи питанката е следната, сега са модерни уеб интерфейсите, а ние не искаме да изоставаме от тенденциите:), т.е. пускаш си браузера и през него си правиш почти всичко което иначе правиш в конзолата, типичен пример всичките рутери.
- Та въпроса е някой прарвил ли е подобно нещо?
- Как уеб сървъра комуникира с линукс кърнъла, или с юзер програмата?
- Как стандартно се прави това? Какъв е интерфейса - конзолни команди, /dev/*, /sys/*, други?

П.С. Исках да постна в раздел Микроконтролери програмиране, но нещо не стана, така че админа да реши дали да я премести или да я остави тук.

Най-чистия вариант е ти да си напишеш веб сървъра. В най-простия си вид не е нищо особено, има си имплементации за 8 битови uC.
Ако искаш да отидеш на apache и php, нещата стават по-дебели, ще се наложи да си пишеш plugin за php, който да хендълва system calls.

Не ми се открива топлата вода, ще ми се нещо стандартно, т.е. тези неща трябва да стават относително лесно при промяна:
- промяна на изгледа.
- промяна на логиката под изгледа.
- промяна на интерфейса към главното приложение.

Главното приложение ще експортва разну Lua функции, така че май най добре ще е да се използват скриптове на Lua Server Pages. Приемам всякакви предложения.

Аз смятам, че при тази система съвсем спокойно можеш да ползваш някой готов уеб сървър, има доста малки и леки такива:

http://en.wikipedia.org/wiki/Comparison ... eb_servers

Относто как става работата, има два варианта - CGI или mod_нещо си.

При първия вариант, когато има заявка към определен път до уеб сървъра (по подразбиране cgi-bin/neshto.si) вместо той да сервира съдържанието на този файл той стартира файла (който трябва да е изпълним) и изпраща към клиента изхора в резултат на изпълнението. Въпросният изпълним файл може да е всякакъв, компилирана C програма, интерпретиран скриптов език, няма значение. Един от недостатъците тук е, че се стартира нов процес и повече се товари системата.

При втория варианат имаш вграден модул в уеб сървъра, който интерпретира определени скриптови файлове. Такива например са модулите за apache mod_php, mod_perl, mod_lua и т.н.

Относто въпроса ти как става комуникацията със ядрото или друга програма, то това няма общо с уеб сървъра. Реално за да се генерира динамичната уеб страница се изпълнява програма на някакъв език, и там си реализираш комуникацията/дейностите като във всяка друга програма.

Другото нещо е, че от доста време е модерно да не се зарежда наново цялата уеб страница, а да се изпълнява код при клиента (тоест в браузъра), който динамично сменя само някои елементи в страницата. Тука нямаш голям избор за език - Javascript, но за сметка на това има много frameworks. На това му се казва AJAX. Въобще client side уеб програмирането си е специфична област и ако ще правите някакъв по-сложен динамичен интерфейс или ще трябва да четеш (и псуваш, ако трябва да поддръжаш стари браузъри) или да наемете някой специалист, който знае къде какви бъгове има.

http://www.webtoolkit.eu/wt
http://www.tntnet.org/

и ей това ако го портнат за арм ще свърши работа:

http://www.gwan.com/

хайде малко и от мен...

Най-близко е това което казва radolin, но аз ще се опитам да го преразкажа по малко по-различен начин.
За онагледяване на стандартния подход при client-server историите може да вземем за пример тоя форум. Аз преди малко заредих страницата в която пиша в момента. След малко ще натисна "submit" бутона и браузера ще изпрати заявка. На сървъра апачи-то ще огледа заявката и ще реши какво да прави. Най-вероятно ще зареди "posting.php" и ще ми я предаде. Това php може да се разглежда като приложение. Стартира се със завка, проверява я и после вероятно ще направи няколко записа в базата данни на форума. Накрая ще ми върне отговор под формата на страничка, която ще видя аз...

Накратко казано имаме:
заявка -> уеб сървър -> "приложение" -> база данни

Където сървърът е стандартен (няма нищо общо с тоя форум). Най-важното е това, което става в базата данни. Това е форумът - една "боза". А "приложението" или по-точно приложенийцата (щото те са набор от php и др.) са само един интерфейс. Във всеки един момент Рек може да ги промени...

Сега за PEEDI
очевидно сървърът ще е стандартен, с тоя хардуер нямате никакви грижи. Очевидно ще има и някакви стандартни странички (приложенийца) да се конфигурират разни параметри и т.н. Но за разлика от обикновените рутери, вие трябва да предоставите възможност и потребителя да си качва собствени странички/приложения. Примерно ако искам да ползвам PEEDI като тестер, ще направя страничка която зарежда някакъв тестов софтуер в устройството, евентуално казва "натисни еди кой си бутон да видим дали бачка"... Може да има отметки "екрана се вижда", "спийкъра се чува" и т.н. Накрая резултата от теста ще се записва някъде или ще се отпечатва.
Така че важното според мен е интерфейса да е отворен, т.е. потребителите да могат лесно да си пишат и качват странички и/или приложения. А за да се пишат лесно, трябва интерфейса към функциите и параметрите на PEEDI да са лесни. Тук въпросът е какъв е точно тоя интерфейс. При стандартния сървър както казах в основата на всичко е базата данни. Даваш някакъв достъп до базата данни и всеки да може да си качва каквито иска интерфейси... Не те интересува дали ще качват PHP, Javascript или нещо друго.
Имам някакви смътни спомени, че на базите можеха да се слагат тригери и да се прихващат операции. Евентуално това е единия вариант. Правиш си табличка "параметри" и някой като ти промени полето jtag_clock ти се задейства твоя тригер и тогава сетваш и клока на хардуера, така че да съответства на стойността на полето от бозата.
Другия вариант е за интерфейса към хардуера да ползвате нещо стандартно. Примерно socket - всички стандартни езици и скриптове го поддържат, няма нужда да правите нещо специално. Разбира се, може и специални библиотеки. Примерно ваша PHP библиотека с разни функции. Но проблемът е че се обвързвате със съответния език/скрипт.

www.python.org
www.djangoproject.com http://django-ahoy.com/ http://www.djangopackages.com/

python на тва ще като да вкараш истински питон в буркан
Rasbery Pi + OpenWRT, има си всичко, няколко скрипта на пърл или php да ти четят нещата и ги записваш в mysql нa 2" хард диск.
http://code.google.com/p/raspberrypi-openwrt/
http://www.instructables.com/id/Web-Con ... y-Pi-GPIO/
Аз бих си взел китайче 1.5GHz играчка с 1GB RAM, вградени 2-3USB че тва PI е много кекаво на CPU, слагаш по USB контролер за GPO входове, ще ти спести година писане на софтуери.
Всичко на всичко ще тряя да си напишеш комуникацията за USB за някакъв евтин контролер. Останалото е работа на админа да настрой WEB, MySQL и php на играчката

Да бе, представям си новото PEEDI с китайска играчка вътре и клати сигналите към таргета през GPIO bridge.

Пишеш си модул за PHP, от там веба ползва функции от твоя модул, а твоя модул си комуникира с квото ти е кеф като shared object, dll или каквато там ти е технологията. За web сървъра каквото си харесаш това е.
Изпробвано работи безотказно.
Друг вариант също пробван и работещ, пишеш приложение което го правиш като add-on, Active-X и каквото там още е нужно за отделните браузери. То си е апп, но работи в браузера.