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

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

 

gloomy писал статью "ДИСПЕТЧЕР ОБЪЕКТОВ WINDOWS NT ИЗНУТРИ".

 

Crackjack
Не совсем понимаю, зачем для решения этой задачи требуется повторять архитектуру диспетчера объектов. Гораздо проще реализовать свою модель. Например:

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

 

Я так понял, ему нужно не функции вида, а имено эти стандартные функции.

 

Тогда это обычный драйвер получается:
IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE и т.д.

 

Угу, только ИМХО нужно открывать не девайс, а что-то типа "ftp://ftp.intel.com/", то есть когда открываешь файл через CreateFile драйвер фильтровал такие имена.

 

Ага. А еще в основной драйвер добавить возможность регистрации других драйверов и проксить запросы им. Тогда можно будет расширять эту штуку сколько угодно

 

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. Это же ф-ия специфичная для устройства, и у него явно нет о ней информации. Или же есть?

 

Конкретно SetCommTimeouts вызывает NtDeviceIoControlFile. То есть нужен аналогичныый механизм - device_io_control(DEV hdev, ...);

 

Это что же тогда получается? Вызывается ф-ия файл-орентированного устройства SetCommTimeouts, которая вызывает ф-ию NtDeviceIoControlFile диспетчера объектов, которая перенаправляет вызов в драйвер, простым вызовом ф-ии обратного вызова, которую у диспетчера зарегистрировал в свою очередь драйвер COM-порта. Таким образом, пишется драйвер ком порта, а к нему еще набор специфичных ф-ий, которые обслуживают драйвер и перенаправляют вызовы в диспетчер объектов? Картина правильная?

 

Прочитал статью, интересно, но ничерта не понятно!

 

А может кто подскажет, кде можно взять посмотреть реализацию драйвера, ну допустим для COM-порта, или любого другого файл-ориентированного устройства? Хоть бы в живую взглянуть на общение драйвера, юзера и диспетчера объектов windows.

 

Более или менее.

Читай до просветления =)

ReactOS

 

Исходники из DDK. Драйвер COM-порта в kernel/serial

Да

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

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