Покритикую маленько...

All about NedoOS

Postby Максагор » 19 Nov 2020, 21:25

Вариант конечно. Хочешь -- научи, тем более что ты явно лучше представляешь, как это должно быть. C++ же знаешь, да? :)
И кстати, твой is-acсемблер мой кусок кода правильно срелоцирует? Опять же не говорю про выравнивание на 256 байт.


Я C++ не знаю. Ну а насчет "срелоцировать кусок кода" - то релоцирует не ассемблер. iS-ассемблер при компиляции кода с ключом, указывающим, что это будет программа, предназначенная для релокации внутри системы, ассемблирует (под какой-то выбранный пользователем "контрольный адрес", указанный в ORG nnnn) как обычно, но в конце программы "пришивает" после метки табличуц с указанием на все места в программе, где встретились либо переходы, либо указания на адреса в виде меток внутри этой программы (т.е. если встретились CALL metka1, JP metka2, LD A,(metka3) и подобное, где metka1,2,3 - указывают на адреса процедур/переменных внутри тела компилируемой программы).
А релоцирует на основании "табличек адресации" получвенный драйвер/резидент уже служебная системная утилита по установке/удалению драйверов резидента. Допустим, У вас в системе в выделенной под дрова области лежат (для примера, "сверху вниз" дрова:

1. Клавы
2. Мыши
3. COM-порта
4. флопа
5. винта
6. SD-карты

Далее нам надо поставить еще и драйвер CD-ROM, который занимает, допустим (берем с потолка), 1537 байт. Утилита установщик берет драйвер, находит самый нижний драйвер в области (в нашем примере это драйвер SD-карты), вычитает от начала его расположения эти 1537 байт (если надо, проверяет, хватает ли под это оставшегося места, чтобы не залезть в "ненужные" разделы системы). Подгружает файл со скомпилированным драйвером, ищет в нем таблицу, и по ней находит все адресныек константы и подправляет их на разницу между теми адресами, которые указаны там и адресами относительног реального расположения драйвера. В итоге получаем новый набор настроенных на свое месторасположение драйверов:

Дрова:
1. Клавы
2. Мыши
3. COM-порта
4. флопа
5. винта
6. SD-карты
7.CD-ROM

А затем нам надо удалить "ненужный" в текущей работе драйвер COM-порта, который, опять берем с потолка, "весит" 915 байт.
Та же самая утилита удаляет из списка ссылку на драйвер COM-порта, и последовательно сдвинает вверх на 915 байт драйвера флопа, винта, SD-карты, CD-ROM, в каждом внося разницу в адресацию соответственных команд исходя их таблицы в конце каждого драйвера.

В итоге получаем набор дров:

Дрова:
1. Клавы
2. Мыши
3. флопа
4. винта
5. SD-карты
6.CD-ROM

В отличие от TASiS можно выделить под дрова отдельную страницу. Или разбить дрова на несколько типов (дрова устройств ввода, дрова печати/вывода символов, дрова "дисковых" устройств, "иные") несколько страниц, или по странице на каждый. Но тут уже, как упоминалось выше, надо брать блокнот, ручку, и "расчерчивать" структуру. Не говорю, что вот прям срочно-срочно. Я согласен с Алонекодером, что очень важен функционал. Но и упускать то, о чем я говорю, тоже нельзя. Ибо "откомпилировать ядра под любые случаи" можно, но это неправильно. Юзер не должен "уметь в ассемблер" или знать структуру системы, чтобы лезть туда и "впендюривать" другой драйвер. Он должен знать, что любой драйвер он установит/удалит/заменит один на другой при момощи утилитки vot_eta_khrenovina.com, а драйвера - это файлы с расширениями, допустим drv,dsk,kbd и prn. И есть тыкнуть по таким-то файлам или набрать в командной строке vot_eta_khrenovina.com /ключ1 /ключ2 fignya.drv то в зависимости от набора ключей или их отсутствия получим или искомый результат, или сообщение об ошибке, если, к примеру, не хватило памяти. Всё.
Last edited by Максагор on 19 Nov 2020, 21:27, edited 1 time in total.
User avatar
Максагор
 
Posts: 259
Joined: 26 Apr 2010, 21:07
Location: Москва
Group: Registered users

Postby Максагор » 19 Nov 2020, 21:27

Я ж не письками мерятся пришел, а пообсуждать...

...
Если ты крутой кодер (я не крутой), то помоги ребятам, напиши пару функций на которые у них времени нет...


Поддерживаю.
User avatar
Максагор
 
Posts: 259
Joined: 26 Apr 2010, 21:07
Location: Москва
Group: Registered users

Postby alone » 19 Nov 2020, 21:51

Поскольку драйверы никто не пишет, вопрос об их загрузке на лету вообще не стоит. Все устройства, которые в принципе можно обслужить, стандартны, кроме принтеров. Но драйвер принтера лучше делать в виде com-файла, который принимает на входе пайп.
User avatar
alone
 
Posts: 48
Joined: 04 Jun 2007, 21:04
Group: Registered users

Postby Максагор » 19 Nov 2020, 22:00

Поскольку драйверы никто не пишет, вопрос об их загрузке на лету вообще не стоит. Все устройства, которые в принципе можно обслужить, стандартны, кроме принтеров. Но драйвер принтера лучше делать в виде com-файла, который принимает на входе пайп.


Драйверов как "структурно законченных" модулей со стандартизированными заголовками, точками входа и проч. по сути сейчас и нет. А есть подпрограммы в ядре, выполняющие функции "общения" с железом. А так как драйверов нет, то, по сути, их даже при всем желании писать никто не будет. А сейчас такой этап, что и писать (а значит и курочить ядро) НЕ НАДО. Сейчас речь идет о "блокнотном" этапе проработки концепции. Дедлайна нет, так что сильно отвлекаться от иных проектов по софту не надо. Все, что требуется на сегодня, это убрать психологическую стеночку из "не хочу", "не буду", "нафиг надо". Ибо от предлагаемых направлений развития система только выиграет.
User avatar
Максагор
 
Posts: 259
Joined: 26 Apr 2010, 21:07
Location: Москва
Group: Registered users

Postby SfS » 20 Nov 2020, 06:44

alone wrote:Поскольку драйверы никто не пишет, вопрос об их загрузке на лету вообще не стоит. Все устройства, которые в принципе можно обслужить, стандартны, кроме принтеров. Но драйвер принтера лучше делать в виде com-файла, который принимает на входе пайп.


Так их не пишут, потому что "драйверов" как таковых - просто нет.
Сейчас в NedoOS "драйвера" - это по сути никак не выделенные подпрограммы, у каждой из которых РАЗНЫЙ интерфейс. И любая программа жестко гвозждями прибита к "драйверу". Добавить драйвер нового устройства - уже никак.

Приведу пример: вот есть у меня пентева.
Куплю я себе, например ZXNETUSB. Прекрасно. Работает.
Потом я возьму и подключу WiFi посредством AY и ESP.
Как мне написать драйвер второй сетевухи? Ну хочу я, чтобы одна программа в сеть ходила по ZXNETUSB, а другая - через WiFi? В существующей реализации - НИКАК. Потому что ОС прибита к одной карте и никак иначе.

Ну да ладно, это скорее экзотика. Возьмём пример попроще - RS232. С ними как быть? Их реальизаций несколько в Спеке. Предположим, одновременно у меня на компе 2 RS232. Как мне в программе указать "я хочу работать через COM2" ? Ведь опять всё прибито гвоздями и если в программе отдельно не предусмотрена возможнось работы через "драйвер COM2" - то фиг то там. То есть скатываемся к тому с чего начали - программа жестко прибита к оборудованию и никак иначе.

Я пытаютсь донести простую истину - суть ОС - это СТАНДАРТНЫЕ ИНТЕРФЕЙСЫ.
Программа ВООБЩЕ НЕ ДОЛЖНА ЗНАТЬ о том, как там что реализовано в драйвере. Ей должно быть монопенисуально - COM1, COM2 или COM22 - сказала "открыть устройство" - получила код возврата, обработала. Сказала "задать скорость" - получила код возврата, обработала. Сказала "записать" - получила код возврата, обработала. И так далее. Отсюда в нормальных ОС и растут принципы - "всё есть файл, а что не файл - то процесс". Я не предлагаю, конечно, писать юникс для спека, но принципы некоторые позаимствовать стоит.

Драйвер это законченная программная единица со СТАНДАРТНЫМ интерфейсом. Понятно, что разные классы устройств требуют разного интерфейса. Но нам то по сути что надо? Символьные/блочные устройства и сетевые устройства. Плюс какой-то уровень абстракции для прикладного ПО. Да хоть виртуальный диск P: на котором в виде файлов представлены ВСЕ драйвера устройств. То есть во время регистрации драйвер задаёт имя устройства, в виде которого он будет представлен и оно добавляется в таблицу.
С точки зрения системы тогда будет просто диск P: и в нем файлы sda sdb ttyS0 ttyS1 net0 net1 и так далее...

Хочешь узнать адрес сетевухи? Да пожалуйста:

int fd=open("P:net1",O_RDONLY);
uint32_t ip, mask;
ioct(fd, GET_IP, &ip, &mask);
close(fd);

Поменять скорость порта? Так же почти:

int fd=open("P:ttyS0",O_RDONLY);
ioct(fd, SET_SPEED, 38400);
close(fd);

Ну и так далее.

Захотел вася пупкин свой драйвер - напишет, придумает имя устройства и загрузит. И никаких конфликтов.

И это.. На быстродействие это практически не влияет.

Аналог select() даст куда больший прирост скорости, чем считание тактов при системных вызовах.
ZX-Phoenix.
Pentevo ZX-Evoluton Rev. B (зелёная)
SfS
 
Posts: 240
Joined: 24 Jun 2010, 08:07
Group: Registered users

Postby alone » 20 Nov 2020, 14:12

Вся работа с сетью находится в модуле w5300.asm. Для написания драйвера достаточно написать в том же формате. Это уже говорилось всем, кто спрашивал насчёт поддержки нестандартных сетевух. Кстати, эта ESP поддерживает несколько одновременных соединений?

Блочные и символьные устройства - это разные устройства. Кроме того, для мыши и часов отдельный интерфейс. Есть также отдельный интерфейс для доступа к клавиатуре на низком уровне (это матрица - нельзя заменить ни на блочное, ни на символьное устройство). Про память уж не говорим. И про графику. В итоге для каждого класса устройств принципиально разный подход. Попытка скрестить нескрестимое приведёт только к тормозам и неудобству использования.
User avatar
alone
 
Posts: 48
Joined: 04 Jun 2007, 21:04
Group: Registered users

Postby SfS » 20 Nov 2020, 14:42

Вся работа с сетью находится в модуле w5300.asm. Для написания драйвера достаточно написать в том же формате. Это уже говорилось всем, кто спрашивал насчёт поддержки нестандартных сетевух.


И я это понял. Но две сетевухи никак, судя по по всему.

Кстати, эта ESP поддерживает несколько одновременных соединений?


Да. ESP8266 до 4 соединений. esp32 - пока памяти хватит. Но имеет смысл только если для них свою прошивку написать. Иначе будет рудимент сетевой карты, который есть сейчас на Penteve.

Блочные и символьные устройства - это разные устройства. Кроме того, для мыши и часов отдельный интерфейс. Есть также отдельный интерфейс для доступа к клавиатуре на низком уровне (это матрица - нельзя заменить ни на блочное, ни на символьное устройство). Про память уж не говорим. И про графику. В итоге для каждого класса устройств принципиально разный подход. Попытка скрестить нескрестимое приведёт только к тормозам и неудобству использования.


На уровне open() close() read() write() это очень даже одинаковые устройства:)

Для мыши и часов отдельный интерфейс? ЗАЧЕМ? Во всех юниксах мышь прекрасно представляется как символьное устройство...

Чем тебя open() close() read() write() не устраивает? Никто ж не обязывает тебя читать по байту. Читай сразу структуру read() - ом
Code: Select all
{
uint16_t  x;
uint16_t  y;
uint8_t  buttons;
uint8_t  wheel;
uint8_t  visiable;
}


Ну или write()-м пиши управляющую мышью структуру.

ioctl() есть если не нравится read() write()

Для часов ещё проще: записать time_t - установка RTC, прочитать time_t - получить время.

это матрица - нельзя заменить ни на блочное, ни на символьное устройство


Ну что ты выдумываешь?:) Читай в буфер по 8 байт и всё. Обычное символьное устройтсво. Кстати, мышь тоже символьное устройство.

Про память уж не говорим.


А что про неё говорить? Обычное символьное устройство /dev/mem или блочное /dev/ram по вкусу :)

Дружище, помоему ты просто думаешь, что из символьного устройства можно читать только символы, а из блочного только блоки:)
Это не так. И оттуда и отсюда можно читать данные любого размера.

Подсистема event в Linux именно так и делает - читает структуры обычным read() из устройства /dev/eventXX (это клава, мышь или что иное).
ZX-Phoenix.
Pentevo ZX-Evoluton Rev. B (зелёная)
SfS
 
Posts: 240
Joined: 24 Jun 2010, 08:07
Group: Registered users

Postby SfS » 20 Nov 2020, 15:00

Ту же клавиатуру можно представлять в виде нескольких устройств:

/dev/zxkbdraw - просто линии как есть после опроса (по 8 байт матрица)
/dev/zxkbd - символы (в нужной кодировке)

/dev/pckbdraw - буфер сканкодов
/dev/pckbd - символы (в нужной кодировке)

Перекодировка должна на уровне драйвера делаться, ИМХО (ну там рус-лат, кодовая страница и проч).
ZX-Phoenix.
Pentevo ZX-Evoluton Rev. B (зелёная)
SfS
 
Posts: 240
Joined: 24 Jun 2010, 08:07
Group: Registered users

Postby lvd » 20 Nov 2020, 15:51

SfS wrote:Потом я возьму и подключу WiFi посредством AY и ESP.

Если ты подключишь есп через компот (дебилизм №1, там же не PPP? а какой-то свой кривой велосипед?) и потом этот компот будешь эмулировать ногодрыжеством на АУ (дебилизм №2), наличие драйверов тебя УЖЕ не спасёт -- всё будет ппц как медленно и долго. Лучше так не надо.

А вообще что тебе мешает взять и переделать ядро (без драйверов) под работу с ЕСП? чтоб меньше дебилизма было, цепляй её через компот пентевы. Вот после этого опыта можно будет что-то осмысленное сказать о необходимости драйверов именно для сетевушек, и в каком виде они должны быть. А не как ты -- 'а давайте щяс таблички вызовов запилим и релоцируемые куски кода понагрузим, и каак заживёёём!'

ps: насколько мне известно, у ДимкиМ никаких ЕСП нету. И у меня. Так что кот если не ты.
Многого нет здесь: http://lvd.nedopc.com
Image
User avatar
lvd
 
Posts: 1744
Joined: 07 Apr 2007, 22:28
Group: Registered users

Postby lvd » 20 Nov 2020, 15:54

alone wrote:В итоге для каждого класса устройств принципиально разный подход. Попытка скрестить нескрестимое приведёт только к тормозам и неудобству использования.

Вот кстати да, несмотря на то, что в горячо мною любимых юниксах и линуксах всё впихивается в прокрустово ложе символьных и блочных девайсов, совершенно очевидно, что так делать нельзя на Z80 на 14 мгц. Это, по-сути, добавление к кол-ву перекладываний байтов туда-сюда. И ioctl() всё равно отбалдёжный, как ни унифицируй.
Многого нет здесь: http://lvd.nedopc.com
Image
User avatar
lvd
 
Posts: 1744
Joined: 07 Apr 2007, 22:28
Group: Registered users

PreviousNext

Return to Обсуждение NedoOS

Who is online

Users browsing this forum: No registered users and 1 guest