NT callback functions

NTFSD
1

Hi,
For NT file system drivers that do not implement caching support (but
support memory mapped IO) is it safe to assume the following?

  1. The callback functions
  • AcquireFileForNtCreateSection
  • ReleaseFileForNtCreateSection
  • AcquireForModWrite
  • ReleaseForModWrite
    can all be set to NULL, without worrying about any deadlocks?
  1. The ERESOURCE fields in the common FCB header will never be acquired
    by NT directly (or through callbacks - of which there are no more than
    those mentioned above) and will only be acquired, if necessary, in our FSD
    code? (This further implies that we are free to totally ignore these
    fields and implement some other synchronization mechanism given that
    caching is not being implemented?)

Thanks!
Jagannath

2

(1) is entirely optional; (2) is definitely *not* true.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Jagannath Krishnan [mailto:xxxxx@hotmail.com]
Sent: Wednesday, March 05, 2003 8:47 PM
To: File Systems Developers
Subject: [ntfsd] NT callback functions

Hi,
For NT file system drivers that do not implement caching support (but
support memory mapped IO) is it safe to assume the following?

  1. The callback functions
  • AcquireFileForNtCreateSection
  • ReleaseFileForNtCreateSection
  • AcquireForModWrite
  • ReleaseForModWrite
    can all be set to NULL, without worrying about any deadlocks?
  1. The ERESOURCE fields in the common FCB header will never be acquired
    by NT directly (or through callbacks - of which there are no more than
    those mentioned above) and will only be acquired, if necessary, in our FSD
    code? (This further implies that we are free to totally ignore these
    fields and implement some other synchronization mechanism given that
    caching is not being implemented?)

Thanks!
Jagannath

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Hi,
Could you clarify your answer to (2) a little?

I take back what I said about setting these call backs to NULL, I intended
to provide empty functions for these call backs (so that the NT defaults
dont kick in)
eg.
MyGenericCallBack()
{
/* No resources acquired here*/
}

Again, Im not supporting any cache manager interaction (but support memory
mapped IO).

  • Given this scenario do you think that NT will still be interested in
    acquiring the ERESOURCES in the FCB common header directly?

  • Will the above give rise to some deadlock?

  • Am I now free to ignore ERESOURCES and use some other method of
    synchronization? (I probably wont, but Im just trying to understand what
    the interaction of NT is with the COMMON_FCB_HEADER ERESOURCES for drivers
    that dont implement caching support)

Thanks,
Jagannath

4

> - Am I now free to ignore ERESOURCES and use some other method of

synchronization? (I probably wont, but Im just trying to understand
what

No. In some paths, NT acquires the resources directly.

Max