Hi, This is the scenario in brief. I need to write a (client) FSD where the storage is distributed over a network. Multiple networks need to be supported. I am thinking of having a layer that is network dependent and making the rest of the driver network independent. Would putting the network dependent part as a seperate driver in the driver stack be a good idea? How much of a performance drag would that be? Can someone comment?Regards,Manoj
Catch all the cricket action. Download Yahoo! Score tracker
Multiple drivers does allow for some interesting support as well
as testing scenarios that I personally think are quite valuable.
As to performance; the addition of calling a routine via a vector
table to another driver is insignificant compared to what a file
system driver does anyway (not to mention netowrk overhead). Allow
you are really adding is a routine address fetch from the table.
Put a vector table of routines to call in the Device Extension
for the network dependent driver and find it’s device object when
you start the network independent file system driver.
Just my opinion,
Rick Cadruvi…
Hi, This is the scenario in brief. I need to write a (client) FSD where the
storage is distributed over a network. Multiple networks need to be supported.
I am thinking of having a layer that is network dependent and making the
rest of the driver n etwork independent. Would putting the network dependent
part as a seperate driver in the driver stack be a good idea? How much of a
performance drag would that be? Can someone comment?Regards,Manoj Catch all
the cricket action. Download Yahoo! Score tracker
Read the RDBSS source from old IFS kits. This is the “network-independent” layer you need.
Max
----- Original Message -----
From: Manoj Joseph
To: File Systems Developers
Sent: Saturday, May 10, 2003 1:19 PM
Subject: [ntfsd] Driver design
Hi,
This is the scenario in brief. I need to write a (client) FSD where the storage is distributed over a network. Multiple networks need to be supported.
I am thinking of having a layer that is network dependent and making the rest of the driver network independent.
Would putting the network dependent part as a seperate driver in the driver stack be a good idea? How much of a performance drag would that be?
Can someone comment?
Regards,
Manoj
Catch all the cricket action. Download Yahoo! Score tracker — You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To unsubscribe send a blank email to xxxxx@lists.osr.com
Rick, Correct me if I am wrong. You mean to say, call the routines in the network dependent driver directly and not pass down the IRP the usual way.Manoj
xxxxx@rdperf.com wrote:Multiple drivers does allow for some interesting support as well
as testing scenarios that I personally think are quite valuable.
As to performance; the addition of calling a routine via a vector
table to another driver is insignificant compared to what a file
system driver does anyway (not to mention netowrk overhead). Allow
you are really adding is a routine address fetch from the table.
Put a vector table of routines to call in the Device Extension
for the network dependent driver and find it’s device object when
you start the network independent file system driver.
Just my opinion,
Rick Cadruvi…
Hi, This is the scenario in brief. I need to write a (client) FSD where the
storage is distributed over a network. Multiple networks need to be supported.
I am thinking of having a layer that is network dependent and making the
rest of the driver n etwork independent. Would putting the network dependent
part as a seperate driver in the driver stack be a good idea? How much of a
performance drag would that be? Can someone comment?Regards,Manoj
Catch all the cricket action. Download Yahoo! Score tracker
>Rick, Correct me if I am wrong. You mean to say, call the routines in the
network dependent driver directly and not pass down the IRP the usual way.Manoj
Exactly! You still get the advantages of splitting the network dependent
parts out (in fact you could have one seperate driver for each network
type and find their table via a lookup in your file system device
extension). Just make the network dependent drivers a bunch of service
routines for your file system driver.
Rick Cadruvi…
======================================================================
xxxxx@rdperf.com wrote:Multiple drivers does allow for some interesting support
as well
as testing scenarios that I personally think are quite valuable.
As to performance; the addition of calling a routine via a vector
table to another driver is insignificant compared to what a file
system driver does anyway (not to mention netowrk overhead). Allow
you are really adding is a routine address fetch from the table.
Put a vector table of routines to call in the Device Extension
for the network dependent driver and find it’s device object when
you start the network independent file system driver.
Just my opinion,
Rick Cadruvi…
Hi, This is the scenario in brief. I need to write a (client) FSD where the
storage is distributed over a network. Multiple networks need to be supported.
I am thinking of having a layer that is network dependent and making the
rest of the driver n etwork independent. Would putting the network dependent
part as a seperate driver in the driver stack be a good idea? How much of a
performance drag would that be? Can someone comment?Regards,Manoj
Catch all the cricket action. Download Yahoo! Score tracker
You are currently subscribed to ntfsd as: xxxxx@rdperf.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–0-785067361-1052646687=:32686
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Rick,
Correct me if I am wrong. You mean to say, call the routines in the network dependent driver directly and not pass down the IRP the usual way.
Manoj
xxxxx@rdperf.com wrote:
Multiple drivers does allow for some interesting support as well
as testing scenarios that I personally think are quite valuable.
As to performance; the addition
of calling a routine via a vector
table to another driver is insignificant compared to what a file
system driver does anyway (not to mention netowrk overhead). Allow
you are really adding is a routine address fetch from the table.
Put a vect
or table of routines to call in the Device Extension
for the network dependent driver and find it’s device object when
you start the network independent file system driver.Just my opinion,
Rick Cadruvi…
>Hi, This is the
scenario in brief. I need to write a (client) FSD where the
>storage is distributed over a network. Multiple networks need to be supported.
> I am thinking of having a layer that is network dependent and making the
>rest of the driver n
ework independent. Would putting the network dependent
>part as a seperate driver in the driver stack be a good idea? How much of a
>performance drag would that be? Can someone comment?Regards,Manoj
Catch all the cricket action. Download
Yahoo! Score tracker
You are currently subscribed to ntfsd as: xxxxx@rdperf.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–0-785067361-1052646687=:32686–