Быть может будет возможность исправить следущее поведение:

1. Загрузится с устройства, которое не поддерживает запись (CD)
2. На голубом стартовом экране сделать изменения
3. "Запомнить текущие настройки?" - Да
ER: сообщение "Бро, сорян, сохранить изменения не получилось. Нажми любую клавишу, чтобы продолжить".
AR: зависание, нужен ребут

План по добавлению функций по чтению/записи секторов дисков

Для добавления этих функций на уровне работы с самими дисками всё уже организовано, есть как чтение, так и запись. Но на уровне API для прикладных программ(системные функции) подобного интерфейса нет и для его организации необходимо добавить несколько компонентов:

• Файловые дескрипторы. Они нужны для блокировки диска/раздела на доступ из других процессов во время записи секторов раздела.

• Функции чтения/записи блоками на основе файловых дескрипторов. Стандартный API 70(80) системной функции не обеспечивает блокировок файла/директории/раздела/диска.

• Функции монтирования/размонтирования дисков/разделов. Это нужно в основном внутри ядра(при открытии дескриптора, см ниже), но также полезно и для пользователей, которые боятся потерять данные из-за ошибки в драйвере фс или диска например.

• Функции изменения данных о разметке дисков. Это необходимо например при форматировании для изменения типа фс раздела

Описание процесса открытия дескриптора на запись раздела/диска:
- создаётся структура дескриптора(добавляется в массив дескрипторов процесса, в глобальную таблицу и тд)
- раздел/диск размонтируется
- раздел/диск блокируются флагом(семафором)

Описание процесса размонтирования:
- блокируется раздел/диск
- для раздела освобождается структура раздела и заменяется заглушкой
- для диска вызывается функция disk_media_changed с аргументом 0
- снимается блокировка раздела/диска


Предлагаю добавить системные функции:
70.11 - open fd
70.12 - close fd
70.13 - update partition info
30.6 - mount disk/part
30.7 - unmount disk/part
77.14 - read blocks
77.15 - write blocks

План по переводу IDE ATAPI устройств на единую систему

В данный момент IDE ATAPI дисководы подключаются с единой файловой системе можно сказать сбоку, что вносит некоторую запутанность в коде ядра и по сути дублирование кода. По этой причине есть предложение по переводу IDE ATAPI устройств на единую систему взаимодействия через следующие изменения кода ядра:
- Добавление в структуру DISKFUNC функции для вызова ATAPI команд
- Реализация универсальных функций для оптических дисков(не чтение и запись)
- написание нового драйвера для iso9660
- перевод IDE ATAPI драйвера на AddDisk/DelDisk
- Удаление системной функции 18.11 как устаревшей ещё лет 13 назад и всего кода связанного с ней

Кроме этого ядро не выводит размер диска через 70.1 что добавляет накладные расходы на программы и лишние вызовы 70 сисфункции для каждого диска. Это же касается и разделов где кроме этого нельзя сменить название раздела.

Doczom wrote: ↑Sat Sep 30, 2023 12:06 am Функции изменения данных о разметке дисков. Это необходимо например при форматировании для изменения типа фс раздела

I don't think this logic should be in the kernel. Having the above mentioned functions implemented, this particular logic can be easily done in userspace.

Doczom wrote: ↑Sat Sep 30, 2023 12:06 am Описание процесса открытия дескриптора на запись раздела/диска:
- создаётся структура дескриптора(добавляется в массив дескрипторов процесса, в глобальную таблицу и тд)
- раздел/диск размонтируется
- раздел/диск блокируются флагом(семафором)

Описание процесса размонтирования:
- блокируется раздел/диск
- для раздела освобождается структура раздела и заменяется заглушкой
- для диска вызывается функция disk_media_changed с аргументом 0
- снимается блокировка раздела/диска

Since it's in the kernel, error handling should be designed carefully. Resources are limited and app crashes happen.

Doczom wrote: ↑Sat Sep 30, 2023 12:21 am - Добавление в структуру DISKFUNC функции для вызова ATAPI команд

Not all DISKs can handle ATAPI commands. Maybe inherit DISKATAPI from DISK and DISKATAPIFUNC from DISKFUNC. Or something like this.

I don't think this logic should be in the kernel. Having the above mentioned functions implemented, this particular logic can be easily done in userspace.

Ok, but when formatting is complete, all other disk partitions will be unmounted to change the partition table.

Not all DISKs can handle ATAPI commands. Maybe inherit DISKATAPI from DISK and DISKATAPIFUNC from DISKFUNC. Or something like this.

DISKFUNC contains a structure size field, due to which I can add 2 functions, for example, to check if there is an ATAPI service and a function to call ATAPI commands. This will not affect the rest of the disks in any way.

Doczom wrote: ↑Sat Sep 30, 2023 12:05 pm Ok, but when formatting is complete, all other disk partitions will be unmounted to change the partition table.

There are two options.
1. No implicit MBR or GPT changes are allowed. If the user formats a partition, only that partition is changed. If the user decides to update an MBR or GPT, first all the partitions are to be unmounted and then the whole disk is to be opened for writing.
2. Allow the user to write MBR and GPT without unmounting any partitions. If a new partition is going to be added, fine. If any partition is going to be resized or removed, ask the user to confirm.

Doczom wrote: ↑Sat Sep 30, 2023 12:05 pm DISKFUNC contains a structure size field, due to which I can add 2 functions, for example, to check if there is an ATAPI service and a function to call ATAPI commands. This will not affect the rest of the disks in any way.

Then another function to check for USB service and a function to send USB packets. Then same for ATA, SCSI, etc. I believe that generic DISK* structures shouldn't care about ATA*, USB and other hardware details.