|
From: Casper H. <ch...@us...> - 2001-11-06 20:02:34
|
> -----Original Message-----
> From: KJK::Hyperion [mailto:no...@li...]
> Sent: 6. november 2001 19:28
> To: ros...@re...
> Subject: [ros-kernel] Re: Proposed new (trivial) device driver
>
>
> At 20.20 05/11/2001 -0500, you wrote:
> >Right... dos/windows/NT has always had nul, but not zero. I
> think our
> >nul
> >device driver should also provide the zero device.
>
> Patch attached. One question: what's the best way to handle multiple
> devices from the same driver? I used the DeviceExtension
> field to store an
> integer from an enum{Null, Zero}, but I'm directly casting
> the integer to a
> PVOID (I wasn't that sure about storing a pointer to a local
> constant),
> will it work? Normally I wouldn't care, but kernel-mode kinda
> scares me :)
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. What use
does it have in ReactOS. A simple memset() would be very much
easier to do and also faster.
Since you stated that it was a programming project I have some
comments for your code.
First of all, have you tested the code? I think everyone would be
happy if patches have undergone simple testing before beeing
committed. No one expects every piece of code submitted to have
been fully tested, but minimal testing would catch a few obvious
bugs and make the lives of other ReactOS developers so much
easier ;o)
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().
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. This
step isn't strictly nescesarry, but in the interrest of
robustness it is useful (e.g. if the pointer match one of your
device object pointers, you can be sure that you can touch the
device extension (if you initialized it).
The device extension is normally used to store device specific
data. It works like this:
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.
typedef struct _COMMON_DEVICE_EXTENSION {
NullDeviceType DeviceType;
} COMMON_DEVICE_EXTENSION, *PCOMMON_DEVICE_EXTENSION;
typedef struct _NULL_DEVICE_EXTENSION {
COMMON_DEVICE_EXTENSION;
// Fields used only for the null device.
} NULL_DEVICE_EXTENSION, *PNULL_DEVICE_EXTENSION;
typedef struct _ZERO_DEVICE_EXTENSION {
COMMON_DEVICE_EXTENSION;
// Fields used only for the zero device.
} ZERO_DEVICE_EXTENSION, *PZERO_DEVICE_EXTENSION;
Status = IoCreateDevice(DriverObject,
sizeof(NULL_DEVICE_EXTENSION),
&NullDeviceName,
FILE_DEVICE_NULL,
0,
FALSE,
&NullDeviceObject);
// Error checking here of course ;o)
DeviceExtension =
(PNULL_DEVICE_EXTENSION)NullDeviceObject->DeviceExtension;
DeviceExtension->DeviceType = Null;
// Same procedure for zero device object
Then in your dispatch routine, you would have something like this:
Common = (PCOMMON_DEVICE_EXTENSION)DeviceObject->DeviceExtension;
switch (Common->DeviceType)
{
case Null:
NullDeviceExtension = (PNULL_DEVICE_EXTENSION)Common;
// Do something on null device
break;
case Zero:
ZeroDeviceExtension = (PZERO_DEVICE_EXTENSION)Common;
// Do something on zero device
break;
}
I hope this helps you a bit.
Casper
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|