[ros-kernel] Re: making vfat asynchronous

[Phillip S. <ps...@cf...>]

At 10:37 AM 11/10/2001 +0100, you wrote:
>Each driver, that will handle i/o asynchronous, needs context switching.
>For a lower level driver, which access hardware directly, is this an
>interrupt service routine or for a polling device a timer dpc. A higher
>level driver use for this worker threads or anything else. Each
>asynchronous i/o has at least two context switches.

This is just not true.  A higher level driver that context switches to 
another thread only to have it block until IO completion is just as nasty 
of a kludge as a lower level driver that constantly busy waits until it's 
device is done, rather than waiting for the device to interrupt.  The whole 
idea behind async IO is that a program can request the IO, the FSD tells 
the device driver to request the IO, and the device driver tells the 
hardware to start the IO, and returns back to the calling program which can 
then do other work while the IO is in progress.  The device can then 
interrupt, and then IO be completed back to the calling program, all 
without a single context switch, as long as the calling program has enough 
other work to keep it busy while the IO is going on, and if it doesn't have 
any more work to do, then switching to the idle thread isn't wasting any 
cycles that could be better used anyhow.  By the way, an ISR and DPC is not 
a context switch, at least in NT terminology.  Switching threads is far 
more costly than handling an interrupt or calling a DPC in 
KeLowerIrql().  NT and all other decent kernels that support async IO do it 
this way, and so should we.

>The current cache manger can only handle small memory segments. This
>results in many calls to the fsd, when there is a read or write with large
>datas, which are not in the cache. The cooperation betwen the cache and the
>memory manger isn't good. Each missing page results in a single call to the
>fsd for 4K page. The cache manager has no read ahead or delayed write
>function. But this is not only the problem of the cache or memory manger.
>Vfatfs must also provide some functions for the cache manager.

I see.  So you think we need to implement the cache manager the NT way then?


>Vfat doesn't need the complete security functions. When a file/directorie
>is created/opened, vfat needs informations over the access and share
>rights. Many kernel components calls the open file function without any
>share access rights. A second open for a dll (msvcrt.dll, ..) will fail,
>when vfat handle access rights.

You mean a request to open the file read-write will be denied, because when 
it is mapped, it is opened without shared write access, only shared read, 
right?


>Some functions, which can handle asynchronos access from user mode, fails.
>They access datas, that are not available after an asynchronous operation
>or they wait for the completion, but the calling function should wait for
>the completion.
>
>When there is a complete/large rewrite for vfat or an other fsd or redir
>ector, the kernel needs also a rewrite. This the reason, why I think, that
>is better, to do some small steps.

Could you be more specific with what functions do these things?  It sounds 
like they should be easy to fix.


====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================