Устройство диспетчера объектов???

Тема в разделе "WASM.NT.KERNEL", создана пользователем Crackjack, 27 дек 2006.

  1. Crackjack

    Crackjack Евгений

    Публикаций:
    0
    Регистрация:
    27 дек 2006
    Сообщения:
    9
    Адрес:
    Саров
    Ищю информацию по диспетчеру объектов. Теоритическое его описание читал, возможно оно было не очень подробное. Задавал вопросы на других форумах, но народ либо не отвечает в силу своей занятости, либо не обладает такими специфическими знаниями. Хотелось посмотреть его реализацию, структуры, функции, как он перенаправляет вызовы. Пытаюсь повторить модель диспетчера объектов в своей задаче, понимаю что окончательно запутываюсь, поэтому не хочу двигаться дальше, не посмотрев или не поговорив на эту тему.
    В конечном итоге хочу придти к тому чтобы дополнить win2k набором драйверов(или библиотеками на "C"), для работы с которыми будут использоваться ф-ии CreateFile, ReadFile, WriteFile, CloseHandle, GetOverlapedResault(или что-то подобное). Эти драйвера будут представлять из себя транспортный уровень, отвечающий за передачу данных, но с одним интерфейсом пользователя. Работа будет осуществляться либо с модемом, через RS232, либо с RS232 напрямую, либо с UDP, либо с TCP.
     
  2. n0name

    n0name New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2004
    Сообщения:
    4.336
    Адрес:
    Russia
    gloomy писал статью "ДИСПЕТЧЕР ОБЪЕКТОВ WINDOWS NT ИЗНУТРИ".
     
  3. gilg

    gilg New Member

    Публикаций:
    0
    Регистрация:
    19 май 2005
    Сообщения:
    527
    Crackjack
    Не совсем понимаю, зачем для решения этой задачи требуется повторять архитектуру диспетчера объектов. Гораздо проще реализовать свою модель. Например:

    ==== пользовательские приложения ====
    /\
    ||
    \/
    функции вида CreateFile, WriteFile, ReadFile
    /\
    ||
    \/
    ==== файловая система (может быть полностью портабельной) ====
    /\
    ||
    \/
    внутренние интерфейсы
    /\
    ||
    \/
    ==== драйверы устройств (OS-depended) ====
     
  4. n0name

    n0name New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2004
    Сообщения:
    4.336
    Адрес:
    Russia
    Я так понял, ему нужно не функции вида, а имено эти стандартные функции.
     
  5. gilg

    gilg New Member

    Публикаций:
    0
    Регистрация:
    19 май 2005
    Сообщения:
    527
    Тогда это обычный драйвер получается:
    IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE и т.д.
     
  6. n0name

    n0name New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2004
    Сообщения:
    4.336
    Адрес:
    Russia
    Угу, только ИМХО нужно открывать не девайс, а что-то типа "ftp://ftp.intel.com/", то есть когда открываешь файл через CreateFile драйвер фильтровал такие имена.
     
  7. gilg

    gilg New Member

    Публикаций:
    0
    Регистрация:
    19 май 2005
    Сообщения:
    527
    Ага. А еще в основной драйвер добавить возможность регистрации других драйверов и проксить запросы им. Тогда можно будет расширять эту штуку сколько угодно
     
  8. Crackjack

    Crackjack Евгений

    Публикаций:
    0
    Регистрация:
    27 дек 2006
    Сообщения:
    9
    Адрес:
    Саров
    Sory! Почему то на мыло уведомления об ответах в теме не приходили.

    Для начала интерфейс:
    Он общий для всех ус-ов.

    DEV create_file(char *name, );
    int read_file(DEV hdev, ...);
    int write_file(DEV hdev, ...);
    void close_handle(DEV hdev);

    для модема и порта:
    int set_param(...);

    для модема:
    int dial(DEV hdev, ...);

    для IP:
    int connect(DEV hdev, ...);
    int disconnect(DEV hdev, ...);

    Хочется придти к тому, что для работы с разными физическими интерфейсами можно было бы использовать одни и те же ф-ии.
    Все тупо и просто:

    Код (Text):
    1. HDEV hDev[64];
    2. hDev[1] = create_file("DEV\\MODEM1\\COM1", FLAG_OVERLAPED);
    3. hDev[2] = create_file("DEV\\MODEM1\\COM2", FLAG_OVERLAPED);
    4. hDev[3] = create_file("DEV\\COM3", FLAG_OVERLAPED);
    5. hDev[4] = create_file("DEV\\TCP", FLAG_OVERLAPED);
    6. hDev[5] = create_file("DEV\\UDP", FLAG_OVERLAPED);
    7. ...
    8.  
    9. while(1)
    10. {
    11.   dwWait = WaitForMultipleObjects(hEvents, 64, FALSE, INFINITE);
    12.  
    13.   switch(dwWait)
    14.   {
    15.   case 0:
    16.     for(i = 1; i < 64; i++)
    17.     {
    18.       close_handle(hDev[i])
    19.     }
    20.     break;
    21.  
    22.   case 1:case 2:case 3:
    23.     res = GetAsincResault(hDev[dwWait], Device[dwWait].nBytes);
    24.  
    25.     nNeedOper = ProcessData(Device[dwWait], res);
    26.  
    27.     switch(nNeedOper)
    28.     {
    29.     case READ:
    30.       read_file(hDev[dwWait], Device[dwWait].io_buf, Device[dwWait].nBytes);
    31.       break;
    32.  
    33.     case WRITE:
    34.       write_file(hDev[dwWait], Device[dwWait].io_buf, Device[dwWait].nBytes);
    35.       break;
    36.  
    37.     case DIAL:
    38.       dial(hDev[dwWait], Device[dwWait].telephone);
    39.       break;
    40.  
    41.     case CONNECT:
    42.       connect(hDev[dwWait], Device[dwWait].ip)
    43.       break;
    44.  
    45.      и т.д.
    46.     }
    47.     break;
    48.   }
    49. connect(hDev, telephone, &ovr);
    50. }
    Получается что код обработки данных полностью переносим на другие платформы. Код транспорта можно повторить на других осях, оставив тот же интерфейс. Имеем: разработка одной задачи, а как результат: потдержка устройства на разных осях. + разработка одной задачи для потдержки устройства со своим протоколом сведется к написанию одной лишь ф-ии ProcessData.

    Для начала хочу реализовать это все на уровне приложения, а потом возможно какую-то часть оформить в качестве драйверов. Расширить POSIX подсистему, дополнив набором ф-ий для асинхронного в/в.

    Вот в принципе и все.

    Но ни как не поиму, как диспетчер объектов разбирается с вызовами таких ф-ий как SetCommTimeouts. Это же ф-ия специфичная для устройства, и у него явно нет о ней информации. Или же есть?
     
  9. gilg

    gilg New Member

    Публикаций:
    0
    Регистрация:
    19 май 2005
    Сообщения:
    527
    Конкретно SetCommTimeouts вызывает NtDeviceIoControlFile. То есть нужен аналогичныый механизм - device_io_control(DEV hdev, ...);
     
  10. Crackjack

    Crackjack Евгений

    Публикаций:
    0
    Регистрация:
    27 дек 2006
    Сообщения:
    9
    Адрес:
    Саров
    Это что же тогда получается? Вызывается ф-ия файл-орентированного устройства SetCommTimeouts, которая вызывает ф-ию NtDeviceIoControlFile диспетчера объектов, которая перенаправляет вызов в драйвер, простым вызовом ф-ии обратного вызова, которую у диспетчера зарегистрировал в свою очередь драйвер COM-порта. Таким образом, пишется драйвер ком порта, а к нему еще набор специфичных ф-ий, которые обслуживают драйвер и перенаправляют вызовы в диспетчер объектов? Картина правильная?
     
  11. Crackjack

    Crackjack Евгений

    Публикаций:
    0
    Регистрация:
    27 дек 2006
    Сообщения:
    9
    Адрес:
    Саров
    Прочитал статью, интересно, но ничерта не понятно!:)
     
  12. Crackjack

    Crackjack Евгений

    Публикаций:
    0
    Регистрация:
    27 дек 2006
    Сообщения:
    9
    Адрес:
    Саров
    А может кто подскажет, кде можно взять посмотреть реализацию драйвера, ну допустим для COM-порта, или любого другого файл-ориентированного устройства? Хоть бы в живую взглянуть на общение драйвера, юзера и диспетчера объектов windows.
     
  13. n0name

    n0name New Member

    Публикаций:
    0
    Регистрация:
    5 июн 2004
    Сообщения:
    4.336
    Адрес:
    Russia
    Более или менее.
    Читай до просветления =)
    ReactOS
     
  14. gilg

    gilg New Member

    Публикаций:
    0
    Регистрация:
    19 май 2005
    Сообщения:
    527
    Исходники из DDK. Драйвер COM-порта в kernel/serial

    Да

    ????? Не понял, что имеешь в виду.
    Драйвер COM-порта экспортирует функцию DeviceDispatch, через которую производится взаимодействие с драйвером. В случае вызова SetCommTimeouts в конечном итоге вызывается функция DeviceDispatch с major кодом IRP_MJ_DEVICE_CONTROL, каким-то minor кодом и буфером параметров. Драйвер проверяет коды, разгребает параметры и выполняет требуемые действия. После он заполняет буфер результатов и возвращает статус.

    Суммарно получается, что есть базовый набор функций, одинаковых для всех файлов: NtCreateFile, NtReadFile и т.д. - и функция для выполнения device-specific действий NtDeviceIoControlFile. Думаю, нужно идти этим же путем