Ищу инфу по обходу ioctl для создания ФС.

Ударился в изучение нулевого кольца (привелегированный режим).

Дошел до создания файловой системы и операциями в ней. Говорят, что IOCTL подходит. Несомненно, но это ужас - страшно представить объем кода. Хочу найти документы по другим методам создания ФС и реализации операций над файлами.
Щас читаю статью, но она, похоже, единственная.

Когда изучу, обещаю составить пошаговое руководство и выложить где-нибудь в инете, а пока - нуждаюсь в документации. Помогите.

 

качай IFS kit с ms и кури
каким боком тут IOCTL я не понял. одного ddk для создания файловых систем будет мало

 

Прошу прощенья за малоинформативность: IOCTL в ext/2
я модуль ядра пишу для UNIX4

 

там всего-то IOCTL'ов:
EXT2_IOC_GETFLAGS и EXT2_IOC_SETFLAGS (см. сорцы fs/ext2/ioctl.c)
а так кури - include/linux/ext2_fs.h

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

 

совсем забыл, что тебе это нужно для BSD, ну там это лежит в /ext2fs/ext2_fs.h

 

В одном документе:

Код (Text):

1. Многочисленные разработчики UNIX-ядра негативно относятся к
2. использованию системного вызова ioctl(), не без оснований считая его, по
3. сути, неконтролируемым способом добавления совершенно нестандартных
4. интерфейсов в ядро.

Согласен. Кроме того, я делаю попытку изучить все аспекты создания ФС и на осное полученных знаний, ради учебного интереса, попытаться создать собственную ФС.

 

прежде, чем создавать свою fs, имеет смысл изучить чужие. благо сорцы есть.
или взять что-то нестартное от сторонних разработчиков, например, вот, я в свое время разбирался с этими сорцами: http://people.freebsd.org/~yar/hfs/

про ioctl в статье явно имели ввиду, что считают его "плохим" средством взаимодействия kernal land и user space, т.к. это типа не unix way, хотя в виндах такой способ рулит и никто не возмущается.

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

 

Классное сравнение.
В некоторых задачах, таких как разработка драйверов терминалов, ioctl просто незаменим.
Можно, конечно, накуриться какой-нибудь дури, сжечь свой мозг и в результате начать писать драйвер на ассемблере с использованием int 80h, но это удел полных @#$%, а для нормальных кодеров приходится выбирать.
Для начала, определимся, как драйвер будет работать с UserSpace. Если мы хотим только получать данные, например, как от ГСЧ, то IOCTL тут не требуется, но если тот же ГСЧ должен будет собирать энтропию, то возникает соответствующая дилемма.
Очень часто разработчики прибегают к использованию таких фундаментальных вещей как IOCTL_SET_MSG и IOCTL_GET_MSG, которые работают на прием/передачу данных. Опять же, в терминальных драйверах это нормально, однако сверхмедленно. В файловых системах применяют нечто иное. ОНО называется file_operations. Вот про это я хочу почитать больше. Я ставлю учебную задачу, разработать такой драйвер, который был бы способен ловить юзерские прихоти, не прибегая к ioctl, но и в то же время был бы способен на максимально оптимизированное взаимодействие с UserSpace плюс возможность отловить программные запросы.

 

device
ну вот это и есть unix-way
через в/в ты можешь управлять своим драйвером. даже если это драйвер терминала, то без всякого IOCTL можно посылать ему управляющие коды через ECHO чего-то-там > куда-то-там. и даже без создания своей файловой системы

 

1. /proc
2. символьные устройства
3. /sysfs
это для Linux, может 1 или 3 в BSD нет

 

rei3er
/sysfs появилась только в FreeBSD 6.2 для эмуляции линуха.

ну еще можно обмениватья данными через общую область памяти, только для акутально лишь для немногих задач. тем которым в/в уже не хватает

 

Ядро инвалидом станет
Конкуренция в памяти - архи актуальная задача. Там же натуральная война процессов идет.

 

device
> Ядро инвалидом станет
с какого это перепугу?

> Конкуренция в памяти - архи актуальная задача.
> Там же натуральная война процессов идет.
а секьюрити зачем? память можно разделять строго межу определенным процессом и ядром, другие процессы просто не получат к ней доступа.
другой вопрос, что это реально требуется только при объмене огромными
объемами данных, когда в/в тормозит однозначно, к тому же без совместного
использования памяти ядро и процесс будут дублировать один и теже данные,
гоняя их друг другу то туда, то обратно. хорошо, если этих данных всего метр,
а если целый гектар?! кстати, мимо меня пробегал трассер уровня ядра,
кидающий лог именно в совместно используемую память. ИМХО вполне
нормальное решение, т.к. в противном случае эту память пришлось бы
выделять в ядре, а поскольку, гарантий что процесс успеет считать
все данные за отведенное время у нас нет, нужно выделять очень
большой буфер, тем более, что логи трассировки занимают сотни метров.
конечно, в данном случае возможны и другие решения, но...
какие?! тормозить трассер при заполнении буфера ядра - не есть хорошо
(тем более это был real-time трассер, т.е. трассирующий код
практически без замедления), кольцевой буфер тоже не катит,
мы не можем терять данные... ну еще вообще-то можно было
гнать вывод в файл, но это опять тормоза, разве что гнать его
на виртуальный диск

 

Я сразу не въехал.

А вот на тему пересылки гектара данных - мне досталась одна книжка. Там есть исходник драйвера транспортного протокола с модифицированной моделью пакета.
Смысл там в том, что блок DATA отсылается сначала в сетевое устройство (виртуальный адаптер), обрабатывается в нем, в то время как остальные секции приходят к получателю с задержкой (delay), а потом получатель, когда освободится, примет DATA. В этот момент он уже готов к приему нового пакета. Это реализуется обработкой IRQ.

Это один из наиболее распространенных выходов. Для этого и создаются VFS.
Интересно, а массивы устройств бывают?
Ну типа если они соединены так:

Kernel------->TerminalDevice------->NetworkDevice-------->| еще что-то |

 

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

конечно, это опять не unix-way...
Unix-way это унификация. в частности, если лог трассера идет через в/в или vfs, то его можно обрабатывать любой никсовой утилитой. а если же он в памяти, то это ласты. необходимо создавать свой собственный "читатель" этой памяти. с другой стороны, если ядерный трассер часть отладчика, то унификация совершенно необязательна, т.е. его лог будет читать только интерфейсная надстройка и никто другой.
если лог текстовой - то унификация еще имеет какой-то смысл, а если же он бинарный и недокументированный, то какой смысл давать другим программам его читать, если они все равно не знают как его обрабатывать и его формат может изменится в любой момент?!
но, повторяюсь, это не unix-way, сами никсы сделали исключение только для иксов.

 

Собственно, IOCTL

SIGALRM / SIGUSR1 / SIGUSR2 - перехват, передача управления другому драйверу для выяснения обстоятельств кончины адресного пространства -----> выделение памяти ----> возврат управления. Я так вижу. Обрабатывая разные IRQ можно управлять памятью на 100%. Если пользовательский процесс их (данные) не принимает - делаем процесс-зомби и поднимаем его после выяснения обстоятельств.

 

device
> Собственно, IOCTL
?! скорее уж что-то a = *p;
это же память процесса

> SIGALRM / SIGUSR1 / SIGUSR2
"проснуться" я имел ввиду, что ядро не может быть на 100% уверено, что процесс действительно успеет вычитать буфер за отведенное время. допустим, процесс читает буфер, переводит его в текстовую форму и пишет на очень тормозной сильно фрагментированный диск. а почему нет?! и как ты ему ни сигналь, от этого диск быстрее писать не будет, а процесс _ничего_ не может предпринять в таких условиях, ну разве что сохранять данные на диск в двоичном виде, чтобы писалось быстрее или сначала жать их, а потом писать, но это уже из области фантастики

> выделение памяти ----> возврат управления
ну, да. если кодер думает головой, то вообще-то следует учесть и такую ситуацию. а вот как ее обойти... универсального решения нет. если говорить конкретно о трассировщике, который трассирует код без замедления, то при определенном соотношении скорости работы ЦП/производительности подсистемы дискового в/в, мы _гарантировано_ получим тормоза, т.к. не будем успевать записывать данные по мере их поступления на диск хоть убейся о газель. значит, нужно заранее оптимизировать формат вывода так, чтобы мы успевали. или потребовать наличия офигенного кол-ва памяти. или чтобы там был сверх-быстрый диск на основе флеш. это, конечно, при условии, что данные терять нельзя, как нельзя замедлить и скорость их поступления.
ладно, забудем о трассере и возьмем ну например охранную камеру (камеры). дропать кадры нельзя. и потому мы должны заранее просчитать пиковую нагрузку на дисковую систему с учетом ее возможной фрагментации. это если писать несжатое видео. а если сжатое - то нужно учесть скорость работы ЦП, чтобы он гарантированно успевал сжимать содержимое буфера до его заполнения, что тоже в общем случае невозможно, особенно на современных ЦП, которые при перегрузке запросто могут сбросить частоту и плевать им на драйвер и его проблемы

> Обрабатывая разные IRQ можно управлять памятью на 100%
> Если пользовательский процесс их (данные) не принимает
> делаем процесс-зомби и поднимаем его после выяснения обстоятельств.
ну а смысл? есть куча ситуаций, в которых ты просто физически не успеваешь обрабатывать данные по мере их поступления. и это мы рассматривали идеализированную ситуацию, а в жизни бывает и не такое. например, в системе появился процесс(ы) жрущие ресурсы и грузящие ЦП. и все... нашему процессу не хватает времени/памяти для обработки данных и они поступают в буфер быстрее, чем обрабатываются.

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

кстати, я это не просто так говорю. совсем недавно хачил одну охранную систему, в которой камеры при возникновении движения начинали писать на диск несжатое видео, типа чтобы лучше было видно бандита. идея интересная, но когда к системе подключено N камер слежения, каждая из которых генерирует X байт данных в сек при записи в несжатом виде, а пропускная способность дисковой подсистемы Y байт в сек, где N*X >> Y (знак >> - _много_ больше), то это просто трындец какой-то. а поскольку система аппаратная и доставить новых винтов туда нельзя, единственный путь - хачить софтверную часть, определяя коф. сжатия так, чтобы не дропать кадры

 

боюсь, после того как он станет зомби восстановить процесс не удасться

а если в момент выделения нового участка памяти придут новые данные?

а X-сервер разве не через символьное устройство взаимодействует с драйвером видеокарточки?
(типа /dev/dri/card0)

 

Если без сжатия, то почему бы и нет?

Вот на тему критических ситуаций - можно все контролировать на самом начальном этапе. Если схема приема/передачи данных составлена верно, если была тренировочная модель взимодействия, если транзакции описаны в соответствии со стандартами, то критическая ситуация и не возникнет вообще.... ну, или почти не возникнет. Я пытаюсь рассмотреть способы взаимодействия разных девайсов и UserSpace.

Не разработана модель взаимодействия. Когда от балды творишь что-то --- результаты плачевны. Решение проблемы - при условии отсутствия аппаратных средств ----- распределять вычисления.

 

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



P.s.: А че в теме только 3 человека общаются?