Марат, ты бы хоть написал, какие исправления ты сделал в драйвере и главное зачем. Все ведь прекрасно работало.
Начал копать исходники - очень удивился. Мой драйвер переработан, и, боюсь, не в лучшую сторону. Хотелось бы ошибаться, но тогда хоть объясни, с какими ты глюками столкнулся и где их исправил. Переработанные мною процедуры Calculatefatchain и Restorefatchain в новом ядре заменены на старые. На хрена? Чем новые хуже? Да, тело цикла чуть побольше, но и элементов FAT за один проход обрабатывается в 4 (!!!) раза больше.
В общем, я не против багрепортов, но жду конструктивных предложений, а не партизанщины.
Посмотрел новое ядро Колибри5. Очень удивился.
А теперь я объясню, что мне конкретно не понравилось.
Вот определение размера диска. Вместо 2849 тобой было поставлено 2847 кластеров:
ramdisk_free_space:
;---------------------------------------------
;
; returns free space in edi
; rewr.by Mihasik
;---------------------------------------------
push eax ebx ecx
mov edi,0x280000 ;start of FAT
xor ax,ax ;Free cluster=0x0000 in FAT
xor ebx,ebx ;counter
mov ecx,2847 ;2849 ;2849 clusters
Да, кластеров - 2847. НО ПЕРВЫЕ ДВА ЭЛЕМЕНТА FAT - СЛУЖЕБНЫЕ! И НЕ НА КАКИЕ КЛАСТЕРЫ НЕ ВЕДУТ!
Соответственно, последствия:
-неправильное определение количества кластеров, заниженное на 2 (последние-то 2 не анализируются)
-неправильное определение размера диска.При попытке записи на рамдиск, драйвер будет занижать
размер свободного пространства на 1К (2 кластера), и возможно, выдавать "диск полон" тогда,
когда реально файл помещается.
Едем дальше. Чтение файла, а конкретно, корневого каталога рамдиска.
fr_do: ;reading rootdir
mov edi,edx
dec ebx
push edx
mov edx,ecx ;проверяем: всего кластеров корневого каталога - 14. Соответственно,
add edx,ebx ;начало блока+размер блока - не больше 14
cmp edx,14 ;ebx+ecx=14 если больше, будем выравнивать, уменьшая размер блока
pushf ;сохраняем флаги,они нам пригодятся, чтобы определить, последний ли блок
jbe fr_do1
sub edx,14 ;выравниваем, если такая необходимость возникает
sub ecx,edx
fr_do1:
shl ebx,9
mov esi,0x100000+512*19
add esi,ebx
shl ecx,7
cld
rep movsd ;читаем
popf ;а теперь вытаскиваем флаги
pop edx ;команда pop на флаги не влияет, а в стеке надо прибраться
; jae fr_do2 ;переходим по восстановленным флагам, если дальше читать бессмысленно
xor eax,eax ; ok read возвращаем ОК, НО БЛОК НЕ ПОСЛЕДНИЙ
xor ebx,ebx
ret
fr_do2: ;if last cluster возвращаем ОК, БЛОК ПОСЛЕДНИЙ
mov eax,6 ;end of file
xor ebx,ebx
ret
Последствия:
Закомментировав команду ; jae fr_do2, ты лишаешь возможности при поблочном чтении
корневого каталога определить, где же его конец. Я точно знаю приложение, которое от этого
будет глючить - Lisovin Commander. Не исключена и глючная работа других приложений.
Ну а про calculatefatchain и restorefatchain я молчу. Они к тебе просто не попали.
Вот определение размера диска. Вместо 2849 тобой было поставлено 2847 кластеров:
ramdisk_free_space:
;---------------------------------------------
;
; returns free space in edi
; rewr.by Mihasik
;---------------------------------------------
push eax ebx ecx
mov edi,0x280000 ;start of FAT
xor ax,ax ;Free cluster=0x0000 in FAT
xor ebx,ebx ;counter
mov ecx,2847 ;2849 ;2849 clusters
Да, кластеров - 2847. НО ПЕРВЫЕ ДВА ЭЛЕМЕНТА FAT - СЛУЖЕБНЫЕ! И НЕ НА КАКИЕ КЛАСТЕРЫ НЕ ВЕДУТ!
Соответственно, последствия:
-неправильное определение количества кластеров, заниженное на 2 (последние-то 2 не анализируются)
-неправильное определение размера диска.При попытке записи на рамдиск, драйвер будет занижать
размер свободного пространства на 1К (2 кластера), и возможно, выдавать "диск полон" тогда,
когда реально файл помещается.
Едем дальше. Чтение файла, а конкретно, корневого каталога рамдиска.
fr_do: ;reading rootdir
mov edi,edx
dec ebx
push edx
mov edx,ecx ;проверяем: всего кластеров корневого каталога - 14. Соответственно,
add edx,ebx ;начало блока+размер блока - не больше 14
cmp edx,14 ;ebx+ecx=14 если больше, будем выравнивать, уменьшая размер блока
pushf ;сохраняем флаги,они нам пригодятся, чтобы определить, последний ли блок
jbe fr_do1
sub edx,14 ;выравниваем, если такая необходимость возникает
sub ecx,edx
fr_do1:
shl ebx,9
mov esi,0x100000+512*19
add esi,ebx
shl ecx,7
cld
rep movsd ;читаем
popf ;а теперь вытаскиваем флаги
pop edx ;команда pop на флаги не влияет, а в стеке надо прибраться
; jae fr_do2 ;переходим по восстановленным флагам, если дальше читать бессмысленно
xor eax,eax ; ok read возвращаем ОК, НО БЛОК НЕ ПОСЛЕДНИЙ
xor ebx,ebx
ret
fr_do2: ;if last cluster возвращаем ОК, БЛОК ПОСЛЕДНИЙ
mov eax,6 ;end of file
xor ebx,ebx
ret
Последствия:
Закомментировав команду ; jae fr_do2, ты лишаешь возможности при поблочном чтении
корневого каталога определить, где же его конец. Я точно знаю приложение, которое от этого
будет глючить - Lisovin Commander. Не исключена и глючная работа других приложений.
Ну а про calculatefatchain и restorefatchain я молчу. Они к тебе просто не попали.
Михаил
Так расставим все точки над Ё.
Твой драйвер я изменил только в одном месте. Я тебе отправил письмо! Даже три письма, ни на одно из которых ты не ответил.
Изменение касается процедуры считывающей ROOT, она не считывала последний сектор, в результате 512 байт/32 байта=16 входов FAT были не доступны для просмотра.
Теперь насчет процедур распаковки FAT. Дело в том, что мы с Андреем Халявиным занимались активным отловом багов, и в результате тасовки файлов получилось, так что попал старый файл со старыми процедурами. Хорошо, что ты это увидел. Надо будет вообще переместить эти процедуры в rd.inc
Будем исправлять недоработки. Заодно со всеми другими обнаруженными багами.
Кстати LC работает криво, про это я тебе тоже письмо кидал.
А количество сеторов я сверял с виндой - все нормально!
И блин скольким из вас надо еще объяснять, что я специально гадостями не занимаюсь - они сам получаются!
Так расставим все точки над Ё.
Твой драйвер я изменил только в одном месте. Я тебе отправил письмо! Даже три письма, ни на одно из которых ты не ответил.
Изменение касается процедуры считывающей ROOT, она не считывала последний сектор, в результате 512 байт/32 байта=16 входов FAT были не доступны для просмотра.
Теперь насчет процедур распаковки FAT. Дело в том, что мы с Андреем Халявиным занимались активным отловом багов, и в результате тасовки файлов получилось, так что попал старый файл со старыми процедурами. Хорошо, что ты это увидел. Надо будет вообще переместить эти процедуры в rd.inc
Будем исправлять недоработки. Заодно со всеми другими обнаруженными багами.
Кстати LC работает криво, про это я тебе тоже письмо кидал.
А количество сеторов я сверял с виндой - все нормально!
И блин скольким из вас надо еще объяснять, что я специально гадостями не занимаюсь - они сам получаются!
Михаил
В общем надо проверять не cmp edx,14 ;ebx+ecx=14 если больше, будем выравнивать, уменьшая размер блока
а cmp edx,15
если расскоментировать
jae fr_do2
В любом случае LC не работает с RD, список выведен а по нму курсор не перемещается, с винтом все нормально.
В общем надо проверять не cmp edx,14 ;ebx+ecx=14 если больше, будем выравнивать, уменьшая размер блока
а cmp edx,15
если расскоментировать
jae fr_do2
В любом случае LC не работает с RD, список выведен а по нму курсор не перемещается, с винтом все нормально.
Марат
Ну раз они сами получаются, будем мучить драйвер дальше.
Насчет 15 ты наверное прав. Но раскомментировать эту строчку имхо прийдется.
Файл с процедурами я тебе вышлю.
А глюк с LC когда по нему курсор не перемещается, мне хорошо знаком. Как правило это получалось из-за отсутствия "конца файла"
Ни одного письма с багрепортами я не получил. Если ты их слал на lisovin(at)26.ru, значит, они попали в переполненный ящик (там всегда спама полно, а я был на морях, и чистил его от случая к случаю).
Насчет 2847 надо проверить. Но я уже спотыкался на этой цифре. Последствия я тебе уже расписал.
В общем, будем работать дальше.
Ну раз они сами получаются, будем мучить драйвер дальше.
Насчет 15 ты наверное прав. Но раскомментировать эту строчку имхо прийдется.
Файл с процедурами я тебе вышлю.
А глюк с LC когда по нему курсор не перемещается, мне хорошо знаком. Как правило это получалось из-за отсутствия "конца файла"
Ни одного письма с багрепортами я не получил. Если ты их слал на lisovin(at)26.ru, значит, они попали в переполненный ящик (там всегда спама полно, а я был на морях, и чистил его от случая к случаю).
Насчет 2847 надо проверить. Но я уже спотыкался на этой цифре. Последствия я тебе уже расписал.
В общем, будем работать дальше.
Кстати, у меня в Supermp3 выводится неправильный размер test.mp3 на рамдиске (в Qemu).
А через что ты выводишь размер?
Через 58-ю. В К4 всё было нормально.
Ложная тревога. Оказывается размер файла зачем-то был вкомпилирован в прогу и не зависел от test.mp3...
Who is online
Users browsing this forum: Ahrefs [Bot] and 10 guests