Hi,
Are there a kernel mode equivelents to the win32 Tls* calls?
Thanks,
Joel
thread local storage in kernel mode> Are there a kernel mode
equivelents to the win32 Tls* calls?
Unfortunately, no, and this is very grieveous.
Max
Just out of curiocity, why would you need this?
At 04:14 AM 12/12/00 +0300, you wrote:
thread local storage in kernel mode> Are there a kernel mode
equivelents to the win32 Tls* calls?Unfortunately, no, and this is very grieveous.
Max
You are currently subscribed to ntfsd as: xxxxx@iag.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
–>Phillip Susi
xxxxx@iag.net
As a means of detecting reentrancy; I am developing a file system
filter. I am building up a prefix table of paths for file’s in the system.
The prefix table entries point to a unique identifier (either an FCB or an
ID, I haven’t decided yet) so that I can quickly and unambiguously resolve
contexts assigned to directory nodes (regardless of filename format, long,
short, etc). In order to do this, I traverse each node of the path in
create, checking the prefix on each iteration to see if it is in the prefix
table. If the prefix is not in the prefix table, I open it, get the unique
id, and add an entry to the prefix table.
I am using ZwCreateFile to open each prefix from the create dispatch
routine. I considered rolling my own irp to avoid the reentrancy or
employing a reparse scheme, but decided the reentrant employment of
ZwCreateFile would be adequate and easiest to implement. It would be nice
to have a counter in TLS to detect the reentrancy for efficiency reasons;
without TLS, I have to maintain a table with proper synchronization. With
TLS, I would not have to acquire any synchronization primitives and would
not have to keep the counter in a table.
Note that none of this is implemented yet, so there may be holes in
the logic.
-Joel
-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Monday, December 11, 2000 10:39 PM
To: File Systems Developers
Subject: [ntfsd] Re: thread local storage in kernel mode
Just out of curiocity, why would you need this?
At 04:14 AM 12/12/00 +0300, you wrote:
thread local storage in kernel mode> Are there a kernel mode
equivelents to the win32 Tls* calls?Unfortunately, no, and this is very grieveous.
Max
You are currently subscribed to ntfsd as: xxxxx@iag.net
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
–>Phillip Susi
xxxxx@iag.net
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
RE: [ntfsd] Re: thread local storage in kernel modeJoel,
you could try hacking your own TlsAlloc etc, if you knew the composition of the TlsArray.
In Win95, fs:[0x2C] points to an array of TLS pointers (64 of them) you could try finding an empty slot and
insert your information in there. The same could be true on NT/W2K.
Of course all of what I said requires experimentation on NT/W2K and research, I suggest reading Matt Pietrek’s Win95 System Programming Secrets on the composition of the structure located at fs:0 (Thread Information Block), Inside Windows NT 2nd ed by David A. Solomon, for an NT perspective on this and finally in the CRT/DDK .h files for any information that you can find.
The assumption that I have made, is that a kernel mode thread is similar to a user mode thread, ie using the same structures.
I haven’t done any of this so you are own you own if you decide to test this theory out, but I would be interested in what you find out.
John
----- Original Message -----
From: Smith, Joel
To: File Systems Developers
Sent: Tuesday, December 12, 2000 6:38 AM
Subject: [ntfsd] Re: thread local storage in kernel mode
As a means of detecting reentrancy; I am developing a file system filter. I am building up a prefix table of paths for file’s in the system. The prefix table entries point to a unique identifier (either an FCB or an ID, I haven’t decided yet) so that I can quickly and unambiguously resolve contexts assigned to directory nodes (regardless of filename format, long, short, etc). In order to do this, I traverse each node of the path in create, checking the prefix on each iteration to see if it is in the prefix table. If the prefix is not in the prefix table, I open it, get the unique id, and add an entry to the prefix table.
I am using ZwCreateFile to open each prefix from the create dispatch routine. I considered rolling my own irp to avoid the reentrancy or employing a reparse scheme, but decided the reentrant employment of ZwCreateFile would be adequate and easiest to implement. It would be nice to have a counter in TLS to detect the reentrancy for efficiency reasons; without TLS, I have to maintain a table with proper synchronization. With TLS, I would not have to acquire any synchronization primitives and would not have to keep the counter in a table.
Note that none of this is implemented yet, so there may be holes in the logic.
-Joel
-----Original Message-----
From: Phillip Susi [mailto:xxxxx@iag.net]
Sent: Monday, December 11, 2000 10:39 PM
To: File Systems Developers
Subject: [ntfsd] Re: thread local storage in kernel mode
Just out of curiocity, why would you need this?
At 04:14 AM 12/12/00 +0300, you wrote:
>thread local storage in kernel mode> Are there a kernel mode
>equivelents to the win32 Tls* calls?
>
>Unfortunately, no, and this is very grieveous.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@iag.net
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
–>Phillip Susi
xxxxx@iag.net
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntfsd as: xxxxx@paceap.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
RE: [ntfsd] Re: thread local storage in kernel mode> I am using
ZwCreateFile to open each prefix from the create dispatch
routine. I considered rolling my own irp to avoid the reentrancy or
employing a
reparse scheme, but decided the reentrant employment of ZwCreateFile
would be adequate and easiest to implement. It would be nice to have a
counter in TLS to detect the reentrancy for efficiency reasons; without
TLS, I
You can detect the ZwCreateFile reentrancy by decorating the file name in
your ZwCreateFile by some suffix and then scan for it in the CREATE handler.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
RE: [ntfsd] Re: thread local storage in kernel mode>The assumption that I
have made, is that a kernel mode thread is similar to a
user mode thread, ie using the same structures.
No.
In kmode, FS segment points to the PCR - Processor Control Region.
IIRC its layout is documented.
Yes, fs:[0] is still the exception frame list head (this is hardcoded in the
compiler’s code generators) - but this is the only similarity between the
PCR and the user mode TEB.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Is it possible to Create 1 IRP and send it lower driver for createing File
instead of ZwCreateFile ??
----- Original Message -----
From: “Maxim S. Shatskih”
To: “File Systems Developers”
Sent: Wednesday, December 13, 2000 9:46 PM
Subject: [ntfsd] Re: thread local storage in kernel mode
> RE: [ntfsd] Re: thread local storage in kernel mode> I am using
> ZwCreateFile to open each prefix from the create dispatch
> >routine. I considered rolling my own irp to avoid the reentrancy or
> employing a
> >reparse scheme, but decided the reentrant employment of ZwCreateFile
> >would be adequate and easiest to implement. It would be nice to have a
> >counter in TLS to detect the reentrancy for efficiency reasons; without
> TLS, I
>
> You can detect the ZwCreateFile reentrancy by decorating the file name in
> your ZwCreateFile by some suffix and then scan for it in the CREATE
handler.
>
> Max
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Yes, it is possible to allocate and initialize an IRP_MJ_CREATE irp,
but there is no documentation on the proper way to do this (setting up some
of the security stuff is non-trivial). Some smarter programmers than I have
figured out how to do it, and if you search the ntfsd archives, you can find
at least one implementation.
Thanks,
Joel
-----Original Message-----
From: Satish [mailto:xxxxx@aalayance.com]
Sent: Wednesday, December 13, 2000 11:23 PM
To: File Systems Developers
Subject: [ntfsd] Re: thread local storage in kernel mode
Is it possible to Create 1 IRP and send it lower driver for createing File
instead of ZwCreateFile ??
----- Original Message -----
From: “Maxim S. Shatskih”
To: “File Systems Developers”
Sent: Wednesday, December 13, 2000 9:46 PM
Subject: [ntfsd] Re: thread local storage in kernel mode
> RE: [ntfsd] Re: thread local storage in kernel mode> I am using
> ZwCreateFile to open each prefix from the create dispatch
> >routine. I considered rolling my own irp to avoid the reentrancy or
> employing a
> >reparse scheme, but decided the reentrant employment of ZwCreateFile
> >would be adequate and easiest to implement. It would be nice to have a
> >counter in TLS to detect the reentrancy for efficiency reasons; without
> TLS, I
>
> You can detect the ZwCreateFile reentrancy by decorating the file name in
> your ZwCreateFile by some suffix and then scan for it in the CREATE
handler.
>
> Max
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@aalayance.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com