Board.KolibriOS.org

В настоящее время 58 и 70 сис. функции выполняют схожие функции. 58 сис. функция досталась нам от MENUET.
Сейчас, все новые программы используют 70 сис. функцию.

Предлагаю удалить 58 сис. функцию, и больше не оборачиваться на совместимость.
Программы, у которых есть исходники, и они присутствуют на SVN будут переписаны на 70 сис. функцию.

Для информации: среди подфункций 58-й функции есть LBA-чтение с IDE-дисков 58.16, у которого отсутствует аналог в 70-й функции и которое используется программой hdread, исходники которой отсутствуют.

ЗЫ на всякий случай: лично мне пофиг на судьбу 58-й функции в целом и приложения hdread в частности, так и голосовал.

Можно добавить такую-же подфункцию в функцию 70 если есть необходимость, так что я тоже проголосовал за третий вариант. Главное код работы с LBA не удалять.

Имхо, сначала нужно сделать аналог функции 58.12, и только потом уже удалять. Ибо удалить - самое легкое...

_________________
ушёл...

Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите.
Когда-нибудь эту дырку придется так или иначе затыкать.

ИМХО имеет смысл сохранить LBA-сервис как опциональную подфункцию SysFn 70 для экспериментальных и встроенных версий ядра, отключив ее (условно-компилируемым блоком) в транке.
Кому надо - тот легко сможет подключить ее для собственных нужд.

А сделать так, чтобы функции 58 и 70 были совместимы между собой, а может быть просто были синонимами (в смысле подфункций) нельзя?

P.S.

Цитата: "Прямой доступ к диску из пользовательского приложения - одна из опасных дыр в системной защите."

Если развивать систему в микроядерном направлении, то можно идти другим путём - проверять полномочия приложения выполнять тот или иной системный вызов (в смысле - из потенциально опасных).

Нельзя. Они не только отличаются номером функций подфункций. По сравнению с 70 функцией 58 вообще косорукий и одноногий инвалид. В 70 функции есть аналог VFS, 58 вообще не умеет возвращать директории в виде форматированного списка - она тупо возвращает содержимое либо файла либо папки в виде RAW данных. При работе с ней приложению (файловому менеджеру к примеру) приходилось самому разбираться со всей хитрой внутренней структурой каталогов FAT, про NTFS и Ext вообще речи не было на общесистемном уровне.

К микроядерности это никакого отношения не имеет. В целом ряде древних систем с монолитным ядром системные вызовы делились на привилегированные и непривилегированные; первые были доступны ограниченному кругу задач (например, привилегированная задача могла убить любую задачу в системе, а непривилегированная -- только любую задачу своего же пользователя).

В принципе аналог 58.12 вроде бы придумал.
viewtopic.php?p=29459#p29459
Только

и я бы оставил эту возможность только драйверам, сделав экспорт соответствующих функций ядра.

Да и 58.12 вроде бы использует приложение hdview замечательного товарища Trans'а. Приложение не имеет исходников. Кто-нибудь может с ним связаться?

Asper

Можно сделать условную компиляцию. Правда этот вопрос надо еще проработать.

Связаться вряд ли, но при желании можно переписать с нуля - ничего в ней сложного нет (учитывая наличие Box_Lib сейчас), только времени на все не хватает.

Вобщем 59 функция выглядит так:

syscall_LBA_read_write:
    cmp   [lba_read_enabled], 1
    je     @f
    mov   eax, 10   ; LBA access denied
    ret
 @@:

    test  edi, edi
    jnz   @f
    mov   eax, 7    ; No pointer to buffer
    ret
 @@:
    test  esi, esi
    jnz   @f
 .err_dev_name:
    mov   eax, 1    ; No pointer to device name
    ret
 @@:
    movzx eax, byte [esi+4]
    sub   al, '0'
    inc   al
    cmp   dword [esi], '/hd/'
    je     @f

    cmp   dword [esi], '/bd/'
    jne   .err_dev_name
    dec   al
    add   al, 0x80
 @@:
    mov   [hdpos], eax

    push  ebx edi
    mov   eax, ecx
    xchg  ebx, edi
    test  edi, edi
    jz     .read
    cmp   edi, 1
    je     .write

    pop   edi ebx
    mov   eax, 2    ; Unknown function
    ret

 .read:
    call  hd_read
    jmp   .out

 .write:
    call  hd_write
 .out:
    pop   edi ebx
    xor   eax, eax
    cmp   [hd_error], 0
    je     @f
    mov   eax, 11   ; Device error
 @@:
    ret

в syscall.inc добавил:

      dd syscall_LBA_read_write           ; 59-LBA read and write

Файл kernel.mnt.txt надо переименовать в kernel.mnt, форум блокирует "неизвестные" ему расширения.

Формат функции 59.

in:
eax = 59 ; номер функции
ebx = 0 или 1 ; номер подфункции: 0 - чтение, 1 - запись
ecx = номер блока для чтения/записи
edi = буфер данных для считывания/записи указанного блока (размером 512 байт)
esi = Путь к устройству (задаётся в формате 58 функции (например '/hd/2' или '/bd/1'))

out:
eax = код ошибки файловой системы

Программа считывающая MBR (винчестера или флешки) и опционально записывающая загрузочный сектор указанного устройства в файл /sys/bootsector.bin. Путь к устройству для считывания MBR зашито в коде программы (для смены устройства нужна перекомпиляция программы).


P.S. Я по прежнему считаю, что этой функции быть не должно в "нормальном" ядре.

Я за то, чтобы такая функция была в официально в ядре. Всё равно нету никакого ограничения доступа. Может просто добавить функцию включения/выключения возможности прямого доступа к диску?

_________________
ушёл...

Зачем функцию? Можно сделать компиляцию по умолчанию без этой функции, а при необходимости компилировать с функцией.

Неверное размышление. Выражаясь иносказательно - если всем разрешено носить личное оружие это не значит, что любому должна быть доступна атомная бомба. А такая функция по умолчанию - это атомная бомба для данных жесткого диска.

А может добавить в ядро диалог (только не смейтесь):

Программа XYZ пытается получить прямой доступ к диску "/hd0/1". Разрешить?
{Да} {Нет}

_________________
ушёл...

Падсталом...
Виста+Семерка - кошмарим юзера!