Board.KolibriOS.org

Да вроде логично... Успехов в труде!)) А поддержки мультисессионных CD-RW это ни коим боком касаться не будет? Чего именно надо доработать, чтобы они читались путем?

Похвальная инициатива, поддерживаю. Хотя я, пока, работал только с RD.
Не пнешь, где смотреть про то как установить KOS на винт с GRUB? Пока этим вопросом вообще не занимался, но на следующей недели придется. Тестирование XviD на дискетке затруднительно . (Грузиться система обязательно должна с винта.)

..bw

http://meos32.7.forumer.com/viewtopic.php?t=110

Ok, I did it
If you want to boot KoOS directly with grub, you need to do that:
* get and install the package syslinux
* copy /usr/lib/syslinux/memdisk to /boot
* copy your KoOS-image to /boot
* add this lines to your grub.conf:

Code: Select all

label KoOS
   root (hd0,0)  # edit this to your correct partition, given example is hda1
   kernel /boot/memdisk
   initrd /boot/menuet.img

* reboot and enjoy

edit: just tried, it is not necessary to copy the image to /boot, poit your config "root"-entry to your FAT or NTFS-partition, where the image resides, and write the kernel-entry with (hd0,0)/boot/memdisk or where ever your linux partition is.
BTW, one limitation is in this method: The kernel cannot save its boot settings

Насколько я понял это образ будет загружаться с винта, мне нужно что бы KOS работала с раздела HD как она сейчас работает с RD.

..bw

вот что у ми вышло.. как руки дойдут - доделаю и выложу в SVN http://free.kolibrios.org/?p=art&a=0

Понятно. Спасибо что откликнулись.
Я сейчас использую зспособ загрузки MeOSload'ом из FreeDOS. Правда винт недоступен после загрузки системы (ядро 429). Смотрел только kfar'ом из 0.65 релиза.
Позже продолжу разбираться с винтом, сейчас все равно некогда.

p.s. Раздел отформатирован в FAT16 и расположен вторым на винте. Первый сейчас не отформатирован, но в будущем, будет использован для GRUB.

..bw

Mario79

Третий вариант самый лучший, тем более что файловая система может кешировать не секторами а кластерами. Это значительно ускорит работу. Второй плюс - возможность сделать стандартный интерфейс между драйвером устройства и файловой системой. Достаточно небольшого набора функций: read_sectors(dest, start_sector, count), write_sectors(src, start_sector, count), init/reset, get_device_param(). В таком случае к файловой системе можно примонтировать любое устройство - виртуальный, ram, usb или сетевой диск.

Для быстрого поиска сектора подойдёт хеш-таблица. Различные алгоритмы хеширования описаны у Юрова в Ассемблер. Практикум.

Mario79
Ссылки нет. Точное название В. Юров. Assembler: Практикум. http://www.piter.com/bugs/5-272-00380-2/assemb.zip Здесь примеры из книги.

Только надо учесть, что в отсутствии аллокатора памяти уровня ниже страничного, можно сделать только закрытое хэширование, и лучше с квадратичным шагом.
Для хэш-функции для строк вроде понятно, для чисел - умножение на иррац. с последующим mod 1, хороший разброс получается, сам проверял.

To Serge
Одинокий get_device_param() лучше заменить на нечто подобное ioctl в win|*nix - он более функционален и расширяем.
А так - получается типичное блочное устройство. Можно еще символьные добавить - терминалы ака консоли будут. Интерфейс почти такой же =)

Коллизии будут в любом случае, так что размер таблицы не обязательно должен быть равен числу элементов. Например если в кеше 1000 элементов таблица может иметь 100 входов, а каждый вход образовывать односвязный список
struc CACHE_ENTRY
{
.sector dd ?
.data dd ?
.next dd ?
}

Тогда поиск сведётся к просмотру списка до совпадения .sector
Кстати какой у тебя алгоритм замещения кеша, как определяетя какие сектора оставить а какие заменить ?

Mario79

Таблица работает как массив указателей на списки. Элементов CACHE_ENTRY нужно 1000, но если делать таблицу на 1000 входов то на некоторые входы из-за коллизий будет приходиться несколько элементов, другие будут пустыми. В этом случае при закрытом хешировании применяют рехеширование чтобы найти свободную ячейку в таблице. Если использовать списки элементов то размер таблицы может быть любым, в случае коллизии нужный сектор определяется просмотром списка.

Так, немного. О работе дисковых под систем.
1. Учитываем что число каналов больше 2. Актуально для систем со встроенным SATA контролером, дисков может быть 6( 8 ) штук на 4 каналах.
2. Одновременная работа DMA с дисками на одном канале не возможна.
3. Не все контролеры могут одновременно использовать UDMA на двух каналах сразу. Другии могут, но частоту делят на двоих. Третьи нормально работают.

Mario79
Так держать!

Mario79

Спасибо, что тут еще сказать

Заметил такую вещь. Загружаюсь с флешки, на ней есть куча файлов и папок. Не выключая Колибри, вытаскиваю флешку. На другом компьютере копирую на флешку новые файлы и папки, вставляю флешку снова в компьютер с загруженной Колибри. Первое обращение к файлу или папке на флешке, к которой я до этого не обращался обламывается (те файлы и папки, к которым было обращение, прекрасно читаются), последующие обрабатываются как надо, даже если флешка вставлена в другой порт. Но при этом вновь добавленные файлы нет никакой возможности увидеть без перезагрузки. Почему?