lvd wrote:Ура! У нас новый концептолог! (предыдущего и так все знают, упоминать не буду
Ну простите, что высказал свои мысли. Не знал, что это так вас возбудит... Но если вам они не интересны - не читайте. Я ж не заставляю.
lvd wrote:Почему?
Потому что на КАЖДУЮ новую конфигурацию аппаратуры надо новое ядро компилировать. Хотя по идее, ядро есть сущность неизменная и настраиваемая при загрузку. Я ж не даром принципы построения ОС процитировал.
lvd wrote:Так покажи КАК НАДО! Я даже готов тебе сделать прошивку для zxnetusb, чтоб она отзывалась по нестандартным портам, и ты сможешь запилить свой интерфейс сразу для двух сетевушек, которые не будут друг другу мешать. Или ты действительно только концептолух?
Я уже показал. Пишется интерфейс модуля (по сути структура, которая содержит указатели на функции обращения к реализации модуля). Для каждого устройства делается своя реализация, но с единым интерфейсом. Достоинства - неважно какое количество устройств подключено и как они реализованы, программа может общаться с любым из них. Сейчас этого нет. При чём тут порты вообще? Не о них речь.
lvd wrote:Зачем?
Затем, что пользователь хочет скачать файл из инета и запустить его, а не компилировать и бороться с несовместимостью... Не?
lvd wrote:Почему не стоит? Чо-то как я посмотрю, аргументация страдает отсутствием логических умозаключений.
Аргументация проста и была много раз приведена:
При добавлении нового устройтва, даже полностью аналогичного по функциями существующему необходимо:
- реализовать новый интерфейс общения с этим устройством;
- пересобрать всё ядро (ну ладно это не так страшно);
- переписать прикладное ПО, чтобы оно знало, что есть ЕЩЁ одно устройство с ровно таким же функционалом, как уже имеющееся (это писец); Ага. Очень удобно.
lvd wrote:Ну да, логично, одним и тем же вызом можно и скорость сериального порта установить, и сокет открыть на прослушивание. Да? Ведь всё должно быть файлом.
А почему нет? Для каждого устройства набор файлов, через которые идёт управление.
И никакого IOCTL не надо:)
Например устройство COM-порт /dev/ttyS0 и к нему управляющие файлы:
/sys/dev/ttyS0/mode
/sys/dev/ttyS0/flowctl
/sys/dev/ttyS0/rts
/sys/dev/ttyS0/dtr
/sys/dev/ttyS0/cts
/sys/dev/ttyS0/ri
Читаешь-пишешь всё стандартными open() close() read() write()...
И с сетью аналогично можно:)
Так что надо о таком подходе подумать.. Минусы-плюсы...
lvd wrote:Какие именно функции включает а какие нет? Что делать если всё же места не хватит? А если места для этих 'модулей' не хватит?
Функции добавления, инициализации, удаления модулей и управления памятью (щёлкания страничками, их выделения-освобождения) по сути. И функции диспетчерезации системных вызовов.
Модули могут располагаться в разных страничках. Если памяти не хватит на одной, выделяется ещё одна. Ограничение - модуль не более 16К размером.
lvd wrote:Чем это отличается от букв дисков? Ну кроме желания 'хачю как в unix и ниипёт'?
Отличается тем, что можно монтировать-отмонтировать реальные и виртуальные ФС к любому каталогу корневой ФС. Можно, конечно, прибить виртуальные ФС и к буквам: D-devfs, P-pipes и так далее. Но мне больше нравится так /dev/ /mnt/sdsmuc /mnt/sdneogs.
В принципе, с точки зрения реализации разницы не много.
ZX-Phoenix.
Pentevo ZX-Evoluton Rev. B (зелёная)