Prev: Out-of-band data
Next: NDIS61 Header Data Split question
From: Ben Voigt [C++ MVP] on 12 May 2008 09:43
Pavel A. wrote:
> IMHO it would be nice to have "uniform" way to talk to services,
> whether they are kernel drivers or normal usermode services.
> Ioctls are only for kernel drivers.
> I'd like to be able to eventually move my stuff out of kernel (by same
> reasons as for moving drivers to UMDF),
> but keep same interface.
> If pipes are out, what else is left - maybe lpc?

A user-mode wrapper interface that hides the communication details perhaps.

>
> --PA
>
>
> "Don Burn" <burn(a)stopspam.windrvr.com> wrote in message
> news:e$XInUpsIHA.2064(a)TK2MSFTNGP05.phx.gbl...
>> I'm suspect it is the undocumented calls, once I saw the performance
>> I took the approach of when I see them in a driver, rip it out, why
>> bother with something that provides no benefit.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>>
>>
>> "Pavel A." <pavel_a(a)NOwritemeNO.com> wrote in message
>> news:Oxvt9RpsIHA.4476(a)TK2MSFTNGP06.phx.gbl...
>>> Then, how these pipes manage to work between usermode processes?
>>> Is the problem only in (erroneous) use of undocumented calls?
>>>
>>> Regards,
>>> --PA
>>>
>>> "Don Burn" <burn(a)stopspam.windrvr.com> wrote in message
>>> news:#LUfVxosIHA.524(a)TK2MSFTNGP05.phx.gbl...
>>>> Kerem,
>>>>
>>>> I cannot spell them out, but having tried the samples that
>>>> have showed up on this, they all crash the system, either
>>>> immediately or with a system stress test. Then if you go look at
>>>> the undocumented calls, you start finding that they are not
>>>> accurately documented. Finally, even the ones that do work
>>>> (until stress) are very slow, so why bother? --
>>>> Don Burn (MVP, Windows DDK)
>>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>>> Website: http://www.windrvr.com
>>>> Blog: http://msmvps.com/blogs/WinDrvr
>>>> Remove StopSpam to reply
>>>>
>>>>
>>>>
>>>> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message
>>>> news:uQEM2alsIHA.4848(a)TK2MSFTNGP05.phx.gbl...
>>>>> Hi Tim,
>>>>>
>>>>>> Too many special cases to handle.
>>>>>
>>>>> Can you tell some special cases that must be taken care of,
>>>>> please,... I did not use any kernel pipe stuff for inter driver
>>>>> communication yet. So what do we have to take care of or what
>>>>> special cases can someone expect,...?
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Kerem
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------
>>>>> Beste Gr�sse / Best regards / Votre bien devoue
>>>>> Kerem G�mr�kc�
>>>>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>>> Latest Open-Source Projects: http://entwicklung.junetz.de
>>>>> -----------------------
>>>>> "This reply is provided as is, without warranty express or
>>>>> implied." "Tim Roberts" <timr(a)probo.com> schrieb im Newsbeitrag
>>>>> news:2t6a24lpvicge63ripcjerbu9pjr3igssp(a)4ax.com...
>>>>>> mirage2k2 <mirage2k2(a)discussions.microsoft.com> wrote:
>>>>>>>
>>>>>>> I have always performed I/O between user mode and kernel mode
>>>>>>> via traditional IOCTRL. I have seen examples where named pipes
>>>>>>> have been used. My understanding is that using named pipes is
>>>>>>> possible but non-standard and
>>>>>>> should be avoided. Any comments.
>>>>>>
>>>>>> I agree with Maxim. I actually implemented a user/kernel pair
>>>>>> that used
>>>>>> named pipes, and in the end I tore it out and implemented an
>>>>>> ioctl scheme.
>>>>>> Too many special cases to handle.
>>>>>> --
>>>>>> Tim Roberts, timr(a)probo.com
>>>>>> Providenza & Boekelheide, Inc.


From: Ben Voigt [C++ MVP] on 12 May 2008 09:44
Don Burn wrote:
> I'm suspect it is the undocumented calls, once I saw the performance
> I took the approach of when I see them in a driver, rip it out, why
> bother with something that provides no benefit.

What's the IOCTL equivalent (from userspace) to OVERLAPPED pipe I/O?
Undocumented NtDeviceIoControl or is there an approved mechanism?


From: Don Burn on 12 May 2008 10:26
Well DeviceIoControl allows OVERLAPPED, and of course completion ports can
make this pretty fast.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply





"Ben Voigt [C++ MVP]" <rbv(a)nospam.nospam> wrote in message
news:OhUrAXDtIHA.1872(a)TK2MSFTNGP04.phx.gbl...
> Don Burn wrote:
>> I'm suspect it is the undocumented calls, once I saw the performance
>> I took the approach of when I see them in a driver, rip it out, why
>> bother with something that provides no benefit.
>
> What's the IOCTL equivalent (from userspace) to OVERLAPPED pipe I/O?
> Undocumented NtDeviceIoControl or is there an approved mechanism?
>


From: Alexander Grigoriev on 12 May 2008 10:34
Ultimately, DevIoCtl and pipe IO go through similar paths. Pipe I/O might
then go through additional pains of framing the message, etc. IOCTL doesn't
need all that overhead.

"Ben Voigt [C++ MVP]" <rbv(a)nospam.nospam> wrote in message
news:OhUrAXDtIHA.1872(a)TK2MSFTNGP04.phx.gbl...
> Don Burn wrote:
>> I'm suspect it is the undocumented calls, once I saw the performance
>> I took the approach of when I see them in a driver, rip it out, why
>> bother with something that provides no benefit.
>
> What's the IOCTL equivalent (from userspace) to OVERLAPPED pipe I/O?
> Undocumented NtDeviceIoControl or is there an approved mechanism?
>


From: Maxim S. Shatskih on 12 May 2008 17:44
> What's the IOCTL equivalent (from userspace) to OVERLAPPED pipe I/O?
> Undocumented NtDeviceIoControl or is there an approved mechanism?

DeviceIoControl supports both OVERLAPPED and IOCPs, it only does not support
the APC completion notification (there is no DeviceIoControlEx).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Out-of-band data
Next: NDIS61 Header Data Split question