>garbage collection issues.
If core Windows components are fine with Ex pool and lookasides - then why shouldn’t your code be?
We defined everything statically on the heap or on the stack in some cases
Stack variables in the kernel are evil.
Have you ever got 0x0000007F/8 BSOD from your code?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
I know what Ex Pool memory allocations are, but I don’t know what a
“lookaside” is.
Our Stack variables are mostly ints and other minor variables. I don’t
know if we got a "0x0000007F/8 BSOD"during development or not
(specifically) back in 2000/2001, but again, we’ve sold hundreds of
machines with this code meant for running years in an equipment rack
without being turned off, and it’s not BSODing for anyone… We did
have one machine BSOD in 2002 for one customer who was using a new
feature, but we figured out what we were doing wrong (writing past end
of array due to incorrectly written bounds check).
Cheers,
Jeff
On 21-Dec-15 12:23, Maxim S. Shatskih wrote:
> garbage collection issues.
If core Windows components are fine with Ex pool and lookasides - then why shouldn’t your code be?> We defined everything statically on the heap or on the stack in some cases
Stack variables in the kernel are evil.Have you ever got 0x0000007F/8 BSOD from your code?
–
Cheers,
Jeff Long
President
Granite Precision Inc.
www.graniteprecision.com
xxxxx@graniteprecision.com
661.977.9729 x710 v 661.977.9729 f
“The more complex the mind, the greater the need for the simplicity of play.”
– Captain Kirk
>Stack variables in the kernel are evil.
In terms of its stupidity the above statement is pretty much the same as “carrot juice is dangerous”…
Certainly you can die from vitamin A poisoning if you start drinking 15 litres of carrot juice a day,
or run out of the stack space if you start declaring arrays and"monster" structures of the size comparable to that of ETHREAD, on it. After all, no matter what idiots do, they to tend to blow it out of proportion which, in many cases, harms them this or that way. However, it does not necessarily imply these things are bad if properly used by reasonable people…
Anton Bassov
On Mon, Dec 21, 2015 at 3:16 PM, wrote:
> Hi all,
> I am still on the fence as to whether or not I’ve heard here if it’s
> definitive that, for sure we can have the driver attach to one card in
> the system, and still have all the other cards as driver objects in the
> same driver, and access all the objects at DIRQL. None of the other cards
> needs it’s own ISR or servicing, they will all be accessed only from this
> driver, and the other access outside the one ISR is for one card that gets
> a DMA interrupt to keep filling a buffer (an audio card), but other than
> that, polling the cards or writing to them when the main card’s ISR happens
> is just fine and what we do now.
>
>
If you need to coordinate across multiple interrupts - as you might
because of your “one card that gets a DMA interrupt” then you have to pay
attention to the SpinLock field of the WDF_INTERRUPT_CONFIG structure
passed to WdfInterruptCreate, You will need to use one lock for both of
your interrupts. Of course that assumes you need to synchronize across
ISRs, which may not be the case at all, especially if you can defer all
shared state processing to your DPC routines.
See
https://msdn.microsoft.com/en-us/library/windows/hardware/ff544728(v=vs.85).aspx
for a discussion of how to handle sycnchronization of multiple interrupt
sources with a single spinlock.
Mark Roddy