My main problem with this driver is, I want to avoid using OS
APIs, because the code must work transparently in all my OS’s
(including Linux 32 and 64 bit, Solaris, and I hear noises of
other flavors of Unix coming up) and I don’t want to write
multiple copies of this code: the driver has an OS-dependent
layer, but I want to keep that layer as small as I can! On the
other hand, things are kind of easier in the sense that this is
not a video driver but a high speed, dedicated, volume rendering
driver running on specialized hardware, and I do not have to
handle any system stuff such as GDI, Direct 3D or OpenGL. The
array is just a fixed-size local variable, and I use it to
compose the command stream I’m going to send out to the chip’s
hardware queues. The problem is, a whole lot of things can go
wrong while I’m building that command stream, so I set it up on
my own store, and I only commit the finished stream to the hw
queues when I know everything is nice and dandy. To complicate
things, I may have multiple boards in the system and multiple
devices in one board, which means that I may not only be
concurrently setting up multiple streams to different devices,
but I may also have multiple opens on the same device setting up
multiple streams too.
I believe that one problem I have here is that this is the DDK
compiler should by default generate kernel-safe code in all
circumstances. I can just as easy write my own version of
__chkstk(), but I wish the DDK included a version of it for me!
Alberto.
----- Original Message -----
From: “David J. Craig”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, September 16, 2005 12:29 AM
Subject: Re:[ntdev] Re:Access to parallel ports from Win32
>I know you know this, but you can use look aside lists for
>memory allocations. Since this is a video driver, I am not
>sure if they are as restricted as file systems. It can work,
>but you will have to handle the chkstk function. The one
>Microsoft supplies with the compiler is just for user mode. It
>will not work in the kernel. How can it make the calls to find
>the stack size and pointer properly? It is most probably an
>artifact of the compiler that the DDK team didn’t or couldn’t
>get modified for their version.
>
> “Alberto Moreira” wrote in message
> news:xxxxx@ntdev…
>> You know, I don’t know if I like the idea of the compiler
>> inserting calls into my object code and the linker not
>> filling them up. Because this is a checked build, I’m not
>> sure I care about what kind of code they generate for me, as
>> long as it works! But I believe that if the compiler
>> includes a call to chkstk, the linker should fill it up; and
>> I’m using the DDK compiler, mind you. So, to me at least this
>> looks like a bug.
>>
>> Anyway, I’ll use the pragma, because I can do that without
>> messing up with batch and make files: I hate to do that kind
>> of thing. This buffer is a staging area for setting up a
>> stream of graphics rendering commands to my chip, and that
>> stream can be rather longish; the alternative is to put it in
>> the nonpaged pool, but why waste time allocating and
>> deallocating memory if I can do it otherwise ? Another
>> consideration is, this is portable code, it must run just the
>> same under Windows, Linux and Solaris, so, I can’t be too
>> particular about API issues or I end up multiplying by three
>> the number of lines of code I have to write.
>>
>> The other thing is, this is a very high performance
>> environment, which uses a huge amount of memory, so, it can
>> be quite tricky to allocate and use resources without
>> bringing the whole machine to its knees! The driver is very
>> carefully tuned to extract the maximum throughput from the
>> chip and from the bus, and that’s the major consideration
>> here. Trading performance for safety may not be a feasible
>> strategy in my case! So, even if the checked build doesn’t
>> like it, if it works in the production free build I’m happy
>> with it. But meanwhile I have a daily build to satisfy and a
>> QA manager that will be on my back in no time if I
>> systematically break that build!
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “David J. Craig”
>> Newsgroups: ntdev
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Thursday, September 15, 2005 12:13 PM
>> Subject: Re:[ntdev] Access to parallel ports from Win32
>>
>>
>>>A couple of people provided advice to suppress this behavior,
>>>but I disagree. Any local stack usage should be carefully
>>>examined and anything large should be a pointer on the stack
>>>that is allocated from either the paged or nonpaged pool.
>>>Try driver prefast and it will flag all allocations larger
>>>than 1KB and the utility permits this to be varied so it will
>>>report even smaller stack usage by a single function. I
>>>think anything about 256 bytes in a single function is
>>>probably excessive and a potential danger.
>>>
>>> You can’t use the __chkstk() function in drivers since it is
>>> not aware of the rules. It could be replaced by your own
>>> function that uses the correct stack limits and usage calls,
>>> but I prefer to just not cause a problem. Of course, this
>>> becomes far more critical in file system filters.
>>>
>>> “Alberto Moreira” wrote in message
>>> news:xxxxx@ntdev…
>>>> Hi, Guys,
>>>>
>>>> I’m having an annoying problem that’s simple enough that I
>>>> feel I should know the answer, yet it’s buried within the
>>>> structure of the Microsoft DDK toolset that I’m reluctant
>>>> to dig into. So I wonder if someone has some wisdom to
>>>> share with me ?
>>>>
>>>> The problem is this, whenever I have a structure on the
>>>> stack that’s larger than a certain size, the C compiler
>>>> generates a call to__chkstk() in my checked builds. That
>>>> reference, for this or that reason, is not satisfied by the
>>>> linker. I want to either suppress the generation of that
>>>> code or to find which library that function is defined; I’d
>>>> prefer that the compiler doesn’t generate that call to
>>>> begin with.
>>>>
>>>> Do any of you know how to do it ? Tks,
>>>>
>>>>
>>>> Alberto.
>>>>
>>>>
>>>
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>> To unsubscribe send a blank email to
>>> xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
