Помогите пожалуйста разобраться. Как Windows (не важно какя из них) работает через драйвер с реальным HarWare, а не с виртуальным, скажем, сидиромом.

BB>Помогите пожалуйста разобраться. Как Windows (не важно какя из них) работает через
>драйвер с реальным HarWare

С каким hardware-то? С сидюком? Отправкой SCSI команд вниз по стеку в storage port driver.

С винчестером точно так же.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>С каким hardware-то?

устройство виртуальное, неважно через какой порт оно подключается. Просто задаем схему устройства(принципиальную допустим), указываем порт через который его подключать к компу. Надо чтобы Винда воспринимала его как реальное устройство. Т.е. драйвер под это виртуальное устройство работал также, как бы он работал, если бы это устройство реально существовало бы в системе.

Здравствуйте, BugiBos, Вы писали:

BB>устройство виртуальное, неважно через какой порт оно подключается. Просто задаем схему устройства(принципиальную допустим), указываем порт через который его подключать к компу. Надо чтобы Винда воспринимала его как реальное устройство. Т.е. драйвер под это виртуальное устройство работал также, как бы он работал, если бы это устройство
реально существовало бы в системе.

Это очень сложно, можно сказать неосуществимо. Драйверу устройств используют так называемый HAL — часть ядра, отвечающая за абстракцию программного обеспечения от аппаратной реализации. Например, если Вам нужно вывести что то в порт, вы напишите WRITE_POT_ULONG (используя HAL) или напрямую: out port, eax
Теперь вы предлагаете написать некий драйвер, который должен перехватить обращение к реальному порту (съемулировать присутствие аппаратуры). В первом случае (использование HAL) можно попробывать запатчить соответствующий компонет HAL. Это еще можно представить. Во втором случае (прямой вызов инструкции ввода/вывода) я даже не знаю осуществимо ли? В принципе в сегменте состояния задачи есть маски запрещения портов, я честно говоря не знаю, что будет при попытке обращения к запрещенному порту. Если исключение — то его в принципе можно обработать.

Мысль вызрела....
Эмулирующий аппаратуру драйвер может использовать отладочные регистры DR0-DR7. Соответственно при обращении к эмулируемому порту возникнет трассировочное исключение, которое можно обработать. Вот тока точек останова только 4. И с отладчиком типа SoftIce ужиться сложно

Здравствуйте, TarasCo, Вы писали:

TC>Вот тока точек останова только 4.
подробнее. почему 4?

Здравствуйте, TarasCo, Вы писали:

TC>Здравствуйте, BugiBos, Вы писали:

TC>Теперь вы предлагаете написать некий драйвер, который должен перехватить обращение к реальному порту

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

Здравствуйте, BugiBos, Вы писали:

BB>Здравствуйте, TarasCo, Вы писали:

TC>>Вот тока точек останова только 4.
BB>подробнее. почему 4?

ну потому что четыре регистра исп. для задания адреса останова. Почитайте какой нибудь инетеловский RTFM, там найдете, я думаю, полную информацию, а мы тут так, малярим понемногу

Здравствуйте, BugiBos, Вы писали:

BB>Здравствуйте, TarasCo, Вы писали:

TC>>Здравствуйте, BugiBos, Вы писали:

TC>>Теперь вы предлагаете написать некий драйвер, который должен перехватить обращение к реальному порту

BB>драйвер ничиго перехватывать не должен. Это должна делать программа эмулирующая устройство. Вернее она должна перехватывать обращения из драйвера к "устройству" и вы давать, если это нужно, ответ обратно драйверу.

"программа, эмулирующая устройство" тоже будет драйвером IMHO

TC>"драйвером IMHO
что это такое?

BB>устройство виртуальное, неважно через какой порт оно подключается. Просто задаем
>схему устройства(принципиальную допустим), указываем порт через который его подключать

Короче, "эмулятор железки".

Это поддерживается только для шины 1394.
Для других шин придется все самому писать, Windows тут не поможет.

>аппаратной реализации. Например, если Вам нужно вывести что то в порт, вы напишите
>WRITE_POT_ULONG (используя HAL) или напрямую: out port, eax

Упущен из виду еще вопрос энумерации такой железки. Мало свой драйвер написать, надо еще, чтобы PCI.SYS доложил о ней в PnP, и проимплементировал работу с конфиг-спэйсом.

TC>Мысль вызрела....
TC>Эмулирующий аппаратуру драйвер может использовать отладочные регистры DR0-DR7.

Проще перекомпилировать, переопределив WRITE_PORT_UCHAR и прочие как вызовы функций в эмуляторе железки

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Упущен из виду еще вопрос энумерации такой железки. Мало свой драйвер написать, надо еще, чтобы PCI.SYS доложил о ней в PnP, и проимплементировал работу с конфиг-спэйсом.

Вроде не огаваривалось, что устройство должно эмулировать порт в пространстве PCI? (кстати — обращу внимание на неточности в собственной терминологии: программной может быть симуляция, эмуляция бувает только аппаратной) Естественно программная симуляция железа, это полный гемор . Делайте железо, отлаживайте ПО на реальных платах (макетных или боевых), все так делают и не разваливаются

Можно написать программный симулятор РС. Прикольная мысль

>быть симуляция, эмуляция бувает только аппаратной) Естественно программная симуляция
>железа, это полный гемор . Делайте железо, отлаживайте ПО на реальных платах

Для 1394 железа это поддерживается.

Насколько я знаю, они сделали IP поверх 1394, и это потребовало возможности для PC быть "отвечателем" на 1394 запросы. А отсюда и выросла virtual 1394 технология.