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

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: KJK::Hyperion [mailto:no...@li...] 
> Sent: 7. november 2001 02:01
> To: ros...@re...
> Subject: [ros-kernel] Re: RE: Re: Proposed new (trivial) device driver
> 
> 
> 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

Ok, I'm convinced that a zero device is useful ;o)

> 
> >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)

Try Vmware from www.vmware.com. It is available for both linux and NT.
It will run ReactOS just fine. I use it sometimes under Mandrake Linux.

> 
> >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?

Yes you are right. That's definitely a bug in the current null device
driver. Null.sys is not loaded on startup, which is probably why no one
noticed it.

> or does 
> that apply only 
> to the DeviceExtension field?

No.

> 
> >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. 

The dispatch routine(s) usually only run in the context of the
caller (user mode thread) if the driver is a filesystem driver.
Lower level driver dispatch routines usually run in the context
of a system thread (e.g. in the system process).

> 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?

If the data is in the data segment, it can be reached from any
routine.

> 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

Kernel mode threads have about 12KB of stack space. Usually this
is enough, even for large drivers if they do not perform recursive
function calls. IMHO recursive calls in kernel mode is a no-no.

Even if the driver is very simple, I too would definitely have put
a call to the read and write routines in there (for clearity). Some
people might disagree, saying that not doing the call would be
faster. They probably optimize idle loops too ;o)

  Casper

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