RamDisk depends on FastFat ??

I am working on the RamDisk sample from the latest WDK (KMDF).

I was trying to create a file in the ram drive and see the flow of functions
therein.

I was expecting RamDisk sample to parse the file path and take care of the
file creating etc..

However, in reality it turns out that another driver (FastFat.sys) is taking
control of the file creation and etc.. functionality, and RamDisk is
receiving the calls in asynchronous mode after the FastFat.

How is this connection established? I see no code dependency in RamDisk for
FastFat.

Does this mean all FAT drivers eventaully depend on FastFat.Sys driver??

Or is FastFat.sys a filter driver??

Yours,
P.Gopalakrishna.

Tim
Thu Nov 16 23:36:44 CST 2006

P.GopalaKrishna <PGopalaKrishna@discussions.microsoft.com> wrote:
>
>I am working on the RamDisk sample from the latest WDK (KMDF).
>
>I was trying to create a file in the ram drive and see the flow of functions
>therein.
>
>I was expecting RamDisk sample to parse the file path and take care of the
>file creating etc..

Nope. RamDisk provides a physical disk, like the SCSI and IDE drivers.
You're asked for a sector, you provide that sector. The file system stuff
is handled by a file system driver. That way, you can have NTFS on IDE,
NTFS on RamDisk, FAT on SCSI, etc., without requiring the physical disk to
understand anything about file systems.

>However, in reality it turns out that another driver (FastFat.sys) is taking
>control of the file creation and etc.. functionality, and RamDisk is
>receiving the calls in asynchronous mode after the FastFat.
>
>How is this connection established? I see no code dependency in RamDisk for
>FastFat.

It's part of the driver stack. The file system driver talks to a physical
disk driver, which might talk to a bus driver (for USB, for example).
Communication is by IRPs.

>Does this mean all FAT drivers eventaully depend on FastFat.Sys driver??

Yes.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Thierry
Fri Nov 17 02:49:01 CST 2006

Hi forum,

Tim Roberts wrote:

>>I was expecting RamDisk sample to parse the file path and take care of the
>>file creating etc..
>
> Nope. RamDisk provides a physical disk, like the SCSI and IDE drivers.

Ramdisk define a new class of device with it's own GUID. Why not using
RAID/SCSI Guid instead ?

> You're asked for a sector, you provide that sector. The file system stuff
> is handled by a file system driver. That way, you can have NTFS on IDE,
> NTFS on RamDisk, FAT on SCSI, etc., without requiring the physical disk to
> understand anything about file systems.

When and who is attaching the good Fs driver on the disk device ?
I watch with devicetree : if the FormatDisk function is called, Fastfat is
automatically attached to the device. On the other way (no format), no Fs
driver is attached. I guess one driver is polling on disk device's sector
boot and attach the good FS. Is it the job of disk's upperfilter PartMgr ?

Tim
Sat Nov 18 22:18:23 CST 2006

Thierry Murail <yarglah@com.invalid> wrote:
>
>Tim Roberts wrote:
>
>>>I was expecting RamDisk sample to parse the file path and take care of the
>>>file creating etc..
>>
>> Nope. RamDisk provides a physical disk, like the SCSI and IDE drivers.
>
>Ramdisk define a new class of device with it's own GUID. Why not using
>RAID/SCSI Guid instead ?

They probably didn't want to have to handle the entire SCSI command set. By
defining a separate class, they could define their command set.

>> You're asked for a sector, you provide that sector. The file system stuff
>> is handled by a file system driver. That way, you can have NTFS on IDE,
>> NTFS on RamDisk, FAT on SCSI, etc., without requiring the physical disk to
>> understand anything about file systems.
>
>When and who is attaching the good Fs driver on the disk device ?
>I watch with devicetree : if the FormatDisk function is called, Fastfat is
>automatically attached to the device. On the other way (no format), no Fs
>driver is attached. I guess one driver is polling on disk device's sector
>boot and attach the good FS. Is it the job of disk's upperfilter PartMgr ?

I'm not sure, but that seems likely. I haven't done disk drivers myself.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

David
Sat Nov 18 23:45:22 CST 2006

If the drive contains a partition that is not formatted, the raw filesystem
will be attached to it. Without a partition, you need to access the
physical device.

"Tim Roberts" <timr@probo.com> wrote in message
news:5imvl25970574k66jl6ss6j1cp76kv16td@4ax.com...
> Thierry Murail <yarglah@com.invalid> wrote:
>>
>>Tim Roberts wrote:
>>
>>>>I was expecting RamDisk sample to parse the file path and take care of
>>>>the
>>>>file creating etc..
>>>
>>> Nope. RamDisk provides a physical disk, like the SCSI and IDE drivers.
>>
>>Ramdisk define a new class of device with it's own GUID. Why not using
>>RAID/SCSI Guid instead ?
>
> They probably didn't want to have to handle the entire SCSI command set.
> By
> defining a separate class, they could define their command set.
>
>>> You're asked for a sector, you provide that sector. The file system
>>> stuff
>>> is handled by a file system driver. That way, you can have NTFS on IDE,
>>> NTFS on RamDisk, FAT on SCSI, etc., without requiring the physical disk
>>> to
>>> understand anything about file systems.
>>
>>When and who is attaching the good Fs driver on the disk device ?
>>I watch with devicetree : if the FormatDisk function is called, Fastfat is
>>automatically attached to the device. On the other way (no format), no Fs
>>driver is attached. I guess one driver is polling on disk device's sector
>>boot and attach the good FS. Is it the job of disk's upperfilter PartMgr ?
>
> I'm not sure, but that seems likely. I haven't done disk drivers myself.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.