[ros-kernel] Re: RE: Re: Proposed new (trivial) device driver

[KJK::Hyperion <no...@li...>]

At 20.57 06/11/2001 +0100, you wrote:
>I can see the relevance of this in a unix like environment, because of the 
>shell scripting abillities, but not in a Windows environment, where script 
>files don't access device objects directly.

I can assure you that I miss a /dev/zero on NT a lot. That's because I need 
to use it very often: as I said, dd+/dev/zero is the best way to initialize 
binary files, especially disk images

>First of all, have you tested the code?

Nope :) I added a P.S. to my first message on the issue, exactly asking for 
hints on kernel mode debugging :)

Plus, I haven't been able to boot ReactOS yet (problems with mtools and no 
ancient hardware to sacrifice)

>You access the NullDeviceObject and ZeroDeviceObject before they are 
>initialized. This will probably crash the system when the driver is 
>loaded. You should only access those after the call(s) to IoCreateDevice().

Excuse me, but in the main function of the current null.c isn't the device 
object accessed before the creation of the device? or does that apply only 
to the DeviceExtension field?

NTSTATUS STDCALL
DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{

[...]

    DeviceObject->Flags=0;

[...]

    Status = IoCreateDevice(...);

[...]

}

>You use a cast to differentiate between the two device objects. This would 
>work, but it is not terribly flexible. Normally you would store the device 
>object references (NullDeviceObject and ZeroDeviceObject) in the global 
>data segment and in your dispatch routines compare the stored device 
>object pointers with the one passed into the dispatch routine.

I kind of figured that one out. Problem is, I have a very "scholastic" 
(i.e. purely theorical) knowledge of kernel mode drivers, enough to know 
that the dispatcher routine(s) run in the context of the caller and not 
that of the kernel process, but not enough to know how to solve the issue. 
So, a simple assignment will do? I was afraid that data accessible from the 
DriverEntry was inaccessible from the dispatcher(s), but now I guess that 
DriverEntry runs in the global segment, right?

>You define a struct that contains the device specific data. In this case 
>one struct is enough, but you may want to have a different struct for each 
>type of device object. So you split the device specific data into a common 
>part and a device type part.

ooh-kay, thanks a lot. Mine looks so crude and old-fashioned now :)

A final question: don't you find using two separate functions for reading 
and writing a bit overkill in such a trivial driver? I know from the DDK 
that kernel mode code has very limited stack space, for example

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================