С начала вопросы:
1. Как пишутся открытые драйверы, для каждой ОСи отдельно или есть святой грааль?
2. В зависимости от ответа на первый вопрос, есть ли на свете что-то типа сабжа?
3. Если это не возможно то почему?
Ведь что получается. С одной стороны мы имеем множество ОСей с другой множество железок,
логично ведь писать драйверы один раз, используя некий ДрайверСДК. Этот СДК будет задавать
обощенный интерфейс для ОСей, на уровне исходников, повторюсь НА УРОВНЕ ИСХОДНИКОВ.
O>С наступающим всех.
И вас также!
O>С начала вопросы: O>1. Как пишутся открытые драйверы, для каждой ОСи отдельно или есть святой грааль?
Для каждой оси отдельно.
O>2. В зависимости от ответа на первый вопрос, есть ли на свете что-то типа сабжа?
Есть DDK/WDK/WDF/WTF, но оно только для мс виндовз.
Не знаю по поводу фреймворков для никсов, но там и модель попроще, если не ошибаюсь.
O>3. Если это не возможно то почему?
Идея двигателя внутреннего сгорания едина, цель — тоже одна: обеспечить движение, а реализации — разные для Жигулей и Т-34.
O>Ведь что получается. С одной стороны мы имеем множество ОСей с другой множество железок, O>логично ведь писать драйверы один раз, используя некий ДрайверСДК. Этот СДК будет задавать O>обощенный интерфейс для ОСей, на уровне исходников, повторюсь НА УРОВНЕ ИСХОДНИКОВ.
См. выше.
Здравствуйте, pva, Вы писали:
pva>Идея двигателя внутреннего сгорания едина, цель — тоже одна: обеспечить движение, а реализации — разные для Жигулей и Т-34.
Здравствуйте, vayerx, Вы писали:
V>на Жигули и Т-34 ставится одно и то же железо?
Железо в чисто механических системах — это аналог связки дрова+железо в ПК. А более абстрактно — это реализация идеи решения задачи для достижения конкретной цели.
А теперь спрецируйте этот пост на мой предыдущий.
O>1. Как пишутся открытые драйверы, для каждой ОСи отдельно или есть святой грааль?
Если имеются в виду ОС одного семейства (например, различные версии Windows), то зачастую реально написать драйвер, работающий от 98 до Vista. Если имеются в виду ОС разного семейства (Windows и Linux, или Linux и MacOS, например), то придётся воспользоваться абстракцией.
O>2. В зависимости от ответа на первый вопрос, есть ли на свете что-то типа сабжа?
Для Windows — есть, только называется он DDK. Кроме того, можно использовать фреймворки от Microsoft — например, KMDF.
O>логично ведь писать драйверы один раз, используя некий ДрайверСДК. Этот СДК будет задавать O>обощенный интерфейс для ОСей, на уровне исходников, повторюсь НА УРОВНЕ ИСХОДНИКОВ.
Наверняка есть такие абстракции aka wrapper'ы над системными вызовами различных ОС, но лично я таких не знаю, не интересовался.
Здравствуйте, otoko, Вы писали:
O>С наступающим всех. O>С начала вопросы: O>1. Как пишутся открытые драйверы, для каждой ОСи отдельно или есть святой грааль? O>2. В зависимости от ответа на первый вопрос, есть ли на свете что-то типа сабжа? O>3. Если это не возможно то почему?
O>Ведь что получается. С одной стороны мы имеем множество ОСей с другой множество железок, O>логично ведь писать драйверы один раз, используя некий ДрайверСДК. Этот СДК будет задавать O>обощенный интерфейс для ОСей, на уровне исходников, повторюсь НА УРОВНЕ ИСХОДНИКОВ.
Кхм. Ну была в свое время у меня такая идея, даже сделал SDK, позволяющий более менее кроссплатформенно писать драйвера для всякого виртуального железа, а-ля криптодиск и т.п. Даже на SF выложил. Даже с примерами. Но на практике идея малоприменимая — если речь идет о реальном железе, слишком много специфики. Ну как Вы ту же идею с IRQL вынесете на абстрактный уровень... В итоге, мой SDK пошел развиваться в сторону совместимости между Kernel Mode, User Mode и PocketPC... Ну и, разумеется, всяких вкусных объектных оберток вокруг DDK.
Здравствуйте, otoko, Вы писали:
O>Ведь что получается. С одной стороны мы имеем множество ОСей с другой множество железок, O>логично ведь писать драйверы один раз, используя некий ДрайверСДК. Этот СДК будет задавать O>обощенный интерфейс для ОСей, на уровне исходников, повторюсь НА УРОВНЕ ИСХОДНИКОВ.
Такие попытки были, но как-то все заглохли. Все-таки, у разных операционных систем разная модель жизни, и особенно заметно отличие юниксов от виндов.
С другой стороны, у меня был проект wi-fi драйвера, который вполне успешно жил под линухом, вендой и в эмуляторе, да еще и работал с двумя очень разными чипами, что было достигнуто путем разделения содержательной, машинно-зависимой и аппаратно-зависимой частей. Для wi-fi драйвера это имело смысл, т.к. содержательная часть в нем очень большая, порядка 30К строк.
Здравствуйте, otoko, Вы писали:
O>С начала вопросы: O>1. Как пишутся открытые драйверы, для каждой ОСи отдельно или есть святой грааль?
Отдельно.
O>2. В зависимости от ответа на первый вопрос, есть ли на свете что-то типа сабжа?
Нет.
O>3. Если это не возможно то почему?
Невозможно. Слишком разные архитектуры.
Самое близкое что есть — это проекты типа FUSE (Filesystem in User SpacE)/CUSE (Character device in User SpacE), которые позволяют абстрагировать некоторые виды драйверов от ОС.
Здравствуйте, Cyberax, Вы писали:
C>Самое близкое что есть — это проекты типа FUSE (Filesystem in User SpacE)/CUSE (Character device in User SpacE), которые позволяют абстрагировать некоторые виды драйверов от ОС.
А эквиавалента FUSE для network address family еще не придумали?
Здравствуйте, Pzz, Вы писали:
C>>Самое близкое что есть — это проекты типа FUSE (Filesystem in User SpacE)/CUSE (Character device in User SpacE), которые позволяют абстрагировать некоторые виды драйверов от ОС. Pzz>А эквиавалента FUSE для network address family еще не придумали?
TDI? Unix STREAMS?
Здравствуйте, Cyberax, Вы писали:
Pzz>>А эквиавалента FUSE для network address family еще не придумали? C>TDI? Unix STREAMS?
C>Raw sockets?
Я имею ввиду, моя програмка могла зарегистрировать новую address family (например, AF_MYFAMILY), и все операции с сокетами, открытыми через socket(AF_MYFAMILY,...) проходили через мою програмку — аналогично тому, как FUSE позволяет писать програмки, добавляющие новый тип файловых систем.
Это удобно, чтобы экспериментировать с новыми сетевыми протоколами.
Raw socket — совсем не то. Сырые сокеты позволяют формировать пакеты в user space, я же хочу создать сокет, все операции с которым заворачиваются ко мне, и который при этом выглядит как настоящий сокет.
В венде грубый эквиавалент этой функциональности — layered socket provider, хотя архитектурно он совсем по-другому устроен.
Здравствуйте, Pzz, Вы писали:
C>>Raw sockets? Pzz>Я имею ввиду, моя програмка могла зарегистрировать новую address family (например, AF_MYFAMILY), и все операции с сокетами, открытыми через socket(AF_MYFAMILY,...) проходили через мою програмку — аналогично тому, как FUSE позволяет писать програмки, добавляющие новый тип файловых систем.
Сделать-то не так уж и сложно (аббревиатура SUSE получится ). Но вот смысл? Оно нужно ну уж оооооооооочень редко.
И когда нужно бывает — то уж замени в своей программе вызовы socket() на my_custom_socket() и всякие read/write на соответствующие my_custom_read/my_custom_write.
Здравствуйте, Cyberax, Вы писали:
Pzz>>Я имею ввиду, моя програмка могла зарегистрировать новую address family (например, AF_MYFAMILY), и все операции с сокетами, открытыми через socket(AF_MYFAMILY,...) проходили через мою програмку — аналогично тому, как FUSE позволяет писать програмки, добавляющие новый тип файловых систем. C>Сделать-то не так уж и сложно (аббревиатура SUSE получится ). Но вот смысл? Оно нужно ну уж оооооооооочень редко.
Нужно, нужно. Затем же, зачем и FUSE. Про аббревиатуру я тоже успел подумать
C>И когда нужно бывает — то уж замени в своей программе вызовы socket() на my_custom_socket() и всякие read/write на соответствующие my_custom_read/my_custom_write.
Ну во-первых, это не так просто, как тебе кажется. Подумай о том, как должен быть устроен select() (или poll()), чтобы он работал и с самодельными сокетами, и с нормальными, причем в любом сочетании.
Во-вторых, бывает потребность использовать уже существующий код с самодельными сокетами. И там не всегда удобно менять имена.
C>Опять же, никто не отменял LD_PRELOAD.
Здравствуйте, Pzz, Вы писали:
C>>Сделать-то не так уж и сложно (аббревиатура SUSE получится ). Но вот смысл? Оно нужно ну уж оооооооооочень редко. Pzz>Нужно, нужно. Затем же, зачем и FUSE. Про аббревиатуру я тоже успел подумать
В принципе, я посмотрел внутрь CUSE — там вроде это легко добавить можно. В принципе, даже уже сейчас можно использовать, если вызов socket() заменить на open("/dev/yourdevice",...).
C>>И когда нужно бывает — то уж замени в своей программе вызовы socket() на my_custom_socket() и всякие read/write на соответствующие my_custom_read/my_custom_write. Pzz>Ну во-первых, это не так просто, как тебе кажется. Подумай о том, как должен быть устроен select() (или poll()), чтобы он работал и с самодельными сокетами, и с нормальными, причем в любом сочетании.
А ещё кто-то говорил, что WFMO в Юниксах не нужен
Здравствуйте, Cyberax, Вы писали:
C>В принципе, я посмотрел внутрь CUSE — там вроде это легко добавить можно. В принципе, даже уже сейчас можно использовать, если вызов socket() заменить на open("/dev/yourdevice",...).
Там, наверное, не хватает некоторого количества вызовов, специфических для сокетов: таких, как bind(), connect(), listen()...
А поддержка select'а есть, да?
Pzz>>Ну во-первых, это не так просто, как тебе кажется. Подумай о том, как должен быть устроен select() (или poll()), чтобы он работал и с самодельными сокетами, и с нормальными, причем в любом сочетании. C>А ещё кто-то говорил, что WFMO в Юниксах не нужен
Здравствуйте, Pzz, Вы писали:
C>>В принципе, я посмотрел внутрь CUSE — там вроде это легко добавить можно. В принципе, даже уже сейчас можно использовать, если вызов socket() заменить на open("/dev/yourdevice",...). Pzz>Там, наверное, не хватает некоторого количества вызовов, специфических для сокетов: таких, как bind(), connect(), listen()...
Это да. Но не так сложно вроде добавить. Опять же, как раз их легко переписать на кастомные функции.
Pzz>А поддержка select'а есть, да?
Вроде бы да.
C>>А ещё кто-то говорил, что WFMO в Юниксах не нужен Pzz>Что такое WFMO?
WaitForMultipleObjects (как сказал x64) — позволяет ждать события на любом наборе объектов (event'ы, хэндлы процессов, файлы...). Т.е. такой select+join+sleep+... в одном флаконе.
Здравствуйте, Cyberax, Вы писали:
Pzz>>Что такое WFMO? C>WaitForMultipleObjects (как сказал x64) — позволяет ждать события на любом наборе объектов (event'ы, хэндлы процессов, файлы...). Т.е. такой select+join+sleep+... в одном флаконе.
Ну в принципе, select() это и есть юниксный эквиавалент WFMO. Просто увы, в современном унихе не всё является файлом. Ну и в венде не все объекты являются waitable handle. Например, в WFMO не засунешь critical section, completion port, хендл окна, созданного другим потоком, ...
