Динамическое определение дисковых устройств
-
В виртуалбоксе перестало работать выключение
У меня выключение работает.
Подтверждаю, у меня та же проблема в VMware:Heavyiron wrote:В виртуалбоксе перестало работать выключение
Code: Select all
VMware® Workstation (Version 7.0.1 build-227600)
Host OS version: Windows 7 Professional, 64-bit 6.1.7601, Service Pack 1
CPU: Intel Core i5-3570 @ 3.40 GHz
RAM: 8GB
В VirtualBox при создании какого-нибудь файла на "/fd/1" он также создаётся и на "/fd2/1".
UPD:
Попробовал так:
UPD:
Попробовал так:
- Floppy Device 0:kolibri.img (1,41 MB)
Floppy Device 1:Empty
Это и раньше так было. Он некорректно эмулирует второй привод флоппи дисков.0CodErr wrote:В VirtualBox при создании какого-нибудь файла на "/fd/1" он также создаётся и на "/fd2/1".
UPD:
Попробовал так:На "/fd2/1" отображается содержимое "/fd/1".
- Floppy Device 0:kolibri.img (1,41 MB)
Floppy Device 1:Empty
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Насколько я знаю, в VirtualBox это и до фикса CleverMouse так было.0CodErr wrote:В VirtualBox при создании какого-нибудь файла на "/fd/1" он также создаётся и на "/fd2/1".
UPD:
Попробовал так:На "/fd2/1" отображается содержимое "/fd/1".
- Floppy Device 0:kolibri.img (1,41 MB)
Floppy Device 1:Empty
В VMware Workstation /fd2 вообще не показывается, если подключить его в настройках. (Это тоже было и до фикса CleverMouse, и сейчас не изменилось).
У меня раньше на fd совсем доступа не было.yogev_ezra wrote:в VirtualBox это и до фикса CleverMouse так было
Последовательность списка в директории "/" изменилась, теперь первым идет "/cdX/X". Не смертельно, но неудобно.CleverMouse wrote:r4273: я перевела на новую схему рамдиск, дискеты и объединила код FAT12 с остальными вариантами FAT. Могут появиться глюки. Жёсткие нерасширяемые зависимости остаются только у CD с собственным кэшем и iso-сколько-то-там-fs.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Я переместила /cdX в конец листинга корневой псевдопапки в r4277.
Сделаем мир лучше!
Я устранила проблему с падением при выключении в r4278.
Сделаем мир лучше!
VMware Workstation - Подтверждаю, проблема исправлена.CleverMouse wrote:Я устранила проблему с падением при выключении в r4278.
В r4437 я написала новые функции fs_read64_sys/fs_read64_app и fs_write64_sys/fs_write64_app для файловых систем, которые принимают на вход 64-битный номер сектора и число секторов для чтения/записи. Старые функции fs_read32_sys/fs_read32_app и fs_write32_sys/fs_write32_app теперь следует считать устаревшими и не использовать в новом коде. Код файловых систем нужно поменять так, чтобы он объединял операции с подряд идущими секторами и кластерами в один вызов.
Пока этого не произошло, fs_read32_sys/fs_read32_app теперь при промахе кэша внутри себя читают CACHE_LEGACY_READ_SIZE секторов вместо одного, где константа CACHE_LEGACY_READ_SIZE = 16 сектороввзята с потолка, в надежде - но без гарантий, - что пригодится. Если и правда пригождается - получается очень серьёзный выигрыш. Если нет - не повезло.
Пока этого не произошло, fs_read32_sys/fs_read32_app теперь при промахе кэша внутри себя читают CACHE_LEGACY_READ_SIZE секторов вместо одного, где константа CACHE_LEGACY_READ_SIZE = 16 секторов
Сделаем мир лучше!
В disk_cache.inc:252 push edi сдвигает структуру над esp.
Пока у себя поправил так:
Пока у себя поправил так:
Code: Select all
Index: disk_cache.inc
===================================================================
--- disk_cache.inc (revision 4440)
+++ disk_cache.inc (working copy)
@@ -250,7 +250,7 @@
; 12b. Prepare for the loop: save edi and create a local variable that
; stores number of sectors to be copied.
push edi
- push [.current_num_sectors]
+ push [.current_num_sectors+4]
.store_to_cache:
; 12c. For each sector, call the lookup function with adding to the cache, if not yet.
mov eax, [.sector_lo+.local_vars2_size+8]
Надо же, кто-то и правда начал использовать fs_read64_*! Да, фикс правильный, я закоммитила его в r4442.
Сделаем мир лучше!
CleverMouse
В связи с не обсуждаемым и единоличным решением полностью выпилить документацию по ф.58.8 и ф.58.15, в SVN r. 4573, у меня возникли встречные вопросы:
1) Насколько взвешенным является решение удалять не очень востребованную, но тем не менее полезную функциональность ф.58.8 и ф.58.15 и планируется ли организация подобных сервисов в рамках ф.70 или любой другой функции?
2) Если, по второй части в.1 ответ утвердительный, то как планируется обеспечить ограничение использование доступа к записи LBA (я понимаю, что форматер вещь нужная) в случае попыток его деструктивного использования (например, если отдельные лица захотят заняться написанием вирусов)?
В связи с не обсуждаемым и единоличным решением полностью выпилить документацию по ф.58.8 и ф.58.15, в SVN r. 4573, у меня возникли встречные вопросы:
1) Насколько взвешенным является решение удалять не очень востребованную, но тем не менее полезную функциональность ф.58.8 и ф.58.15 и планируется ли организация подобных сервисов в рамках ф.70 или любой другой функции?
2) Если, по второй части в.1 ответ утвердительный, то как планируется обеспечить ограничение использование доступа к записи LBA (я понимаю, что форматер вещь нужная) в случае попыток его деструктивного использования (например, если отдельные лица захотят заняться написанием вирусов)?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 1 guest