Question about PDO and RAMDisk

Two question:

  1. As we known, there PDO and FDO and also FiDO.

PDO is physical device object
FDO is functional device object
FiDo is filter device object

In fact, FDO and FiDO is more or less the same property Device object, which differ from one is create by functional driver, and the other is by filter driver.

While I known, that Bus driver create PDO for each device on the bus, and then functional driver create FDO based on the PDO.

For example:
USB hub driver create PDO for each USB device/hub connect on the hub.
Then USB device functional driver then create FDO for each device/hub connect on the hub.

And same for PCI/PCIe driver:
PCI driver create PDO for the usb host, such as ehci or o/uhci, xhci.
then xhci functional driver create FDO for the PDO.

But I still now very clear:
Why PDO is needed, why MS originally design PDO, what’s MS’s original opinion?
What’s the function of PDO?

  1. RAMDisk

My question is

  1. How to install the software-only driver?
    The documents only supply instruction on Winxp and W2K, but not onWIN7.

  2. By what method, RAMDisk driver could be lower of the drivers that could send:
    IOCTLs such as:
    IOCTL_DISK_GET_PARTITION_INFO
    IOCTL_DISK_GET_MEDIA_TYPES
    IOCTL_DISK_GET_DRIVE_GEOMETRY
    IOCTL_DISK_CHECK_VERIFY
    IOCTL_DISK_IS_WRITABLE
    IOCTL_DISK_SET_PARTITION_INFO
    IOCTL_MOUNTMGR_QUERY_POINTS
    IOCTL_MOUNTDEV_QUERY_DEVICE_NAME
    FT_BALANCED_READ_MODE
    IOCTL_DISK_FORMAT_TRACKS

I think it is by:

FILE_DEVICE_DISK in following code, right?

**************************************************
//
// Create the device object
//
status = IoCreateDevice(
DriverObject,
sizeof(DEVICE_EXTENSION),
&uniDeviceName,
FILE_DEVICE_DISK , // old value = FILE_DEVICE_VIRTUAL_DISK , // corrected proposed by MS
(FILE_DEVICE_SECURE_OPEN),
FALSE, // This isn’t an exclusive device
&functionDeviceObject
);
**************************************************

Because I have only WIN7 SYSTEM.
So I could install the RAMDisk driver onto it.

After successfully installation, what’s driver is on top of the RAMDISK driver in the driver stack?

workingmailing@163.com wrote:

For example:
USB hub driver create PDO for each USB device/hub connect on the hub.
Then USB device functional driver then create FDO for each device/hub connect on the hub.

And same for PCI/PCIe driver:
PCI driver create PDO for the usb host, such as ehci or o/uhci, xhci.
then xhci functional driver create FDO for the PDO.

But I still now very clear:
Why PDO is needed, why MS originally design PDO, what’s MS’s original opinion?
What’s the function of PDO?

It’s a reasonable question. Here’s an MSDN page that helped make this
whole topic clearer for me. Take note of the diagram at the very bottom:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff544545.aspx

The key point, in my view, is to notice the overlap between the “created
by” and the “device stack” groupings. Take the example of a USB
camera. The USB bus driver will create a PDO for the camera. That PDO
is considered part of the camera’s device stack, but it is OWNED BY the
bus driver. Requests to that PDO go to the bus driver, not to the
camera driver.

That’s the reason for a PDO. It represents the camera, but it is
handled by the bus. Any alternative schemes without the PDO/FDO
separation make it hard to have that relationship. You could, for
example, have the camera FDO send requests directly to the bus FDO, but
then how does the bus let the operating system know that it needs to
load a camera driver? It just makes for a cleaner separation to have
the PDO in there.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> Why PDO is needed, why MS originally design PDO, what’s MS’s original opinion?

What’s the function of PDO?

An object representing the “conceptual hole where the device is plugged”.

It can be a downstream USB hub port, or PCI slot, or SCSI LUN, or such.

The division of labor between the 2 is a must. For instance, PCI config space belongs (conceptually) to a PCI slot and not to the device in it.

The implementation of PCI config space access belongs to pci.sys and not to the card’s driver.

Same is true on QUERY_ID.

Same is true on some kinds of power management.

And, for protocol-based buses (USB, 1394, SCSI, (S)ATA) - it is the PDO that actually executes the bus transaction. The FDO just tells the PDO on what transaction to execute.

  1. How to install the software-only driver?

PnP or non-PnP?

Because I have only WIN7 SYSTEM.
So I could install the RAMDisk driver onto it.

If you can drop XP, then the RAMDISK should be developed as virtual storage miniport driver.

After successfully installation, what’s driver is on top of the RAMDISK driver in the driver stack?

Depends on how RAMDISK is implemented (there are several ways).


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Sorry, I develop the usb general functional driver.

Most or 100% the irp target a FDO, not to a PDO.

So what kind of driver, should I study to access PDO.

And:
I will paste the INF following:

; RAMDISK.INF
; Windows 2000 installation file for installing the Ramdisk driver
; Copyright (c) 1990-2000 Microsoft Corporation All rights Reserved
; Copyright (c) 2002 QSoft [Quality Software]

[Version]
Signature=“$WINDOWS NT$”
Class=RamDisk
ClassGuid={FFA1C341-4539-11D3-B88D-00C04FAD5172}
Provider=%QSOFT%
DriverVer=09/30/2002,5.00.0001.0

[DestinationDirs]
DefaultDestDir = 12
RamDiskInstaller=11

[ClassInstall32]
Addreg=RamDiskClassReg
CopyFiles=RamDiskInstaller

[RamDiskClassReg]
HKR,0,%ClassName%
; If we don’t provide our own Installer32, ICON’s from “SETUPAPI.DLL” will be selected
; HKR,Icon,-5
; HKR,Icon,-159

HKR,Installer32,“RAMDisk.dll,ClassInstaller”
HKR,Icon,“105”
HKR,EnumPropPages32,“RAMDisk.dll,PropPageProvider”

[RamDiskInstaller]
RAMDisk.dll,%COPYFLG_NOSKIP%
msvcr70.dll,%COPYFLG_NOSKIP%
mfc70u.dll,%COPYFLG_NOSKIP%

[DiskCopyfiles]
ramdisk.sys
ramdisk.dll

[SourceDisksNames]
1=%InstDisk%,

[SourceDisksFiles]
ramdisk.sys=1

[Manufacturer]
%QSOFT% = DiskDevice

[DiskDevice]
%DiskDevDesc% = DiskInstall, Ramdisk

[DiskInstall.NT]
CopyFiles = DiskCopyfiles

[DiskInstall.NT.Services]
AddService = Ramdisk, %SPSVCINST_ASSOCSERVICE%, DiskServiceInst

[DiskServiceInst]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_BOOT_START%
ErrorControl = %SERVICE_ERROR_NORMAL%
DisplayName = %DiskServiceDesc%
ServiceBinary = %12%\ramdisk.sys
AddReg = DiskAddReg

[DiskAddReg]
HKR, “Parameters”, “BreakOnEntry”, %REG_DWORD%, 0x00000000
HKR, “Parameters”, “DebugLevel”, %REG_DWORD%, 0x00000005
HKR, “Parameters”, “DebugComp”, %REG_DWORD%, 0xFFFFFFFF
HKR, “Parameters”, “DiskSize”, %REG_DWORD%, 0x00320000
HKR, “Parameters”, “DriveLetter”, %REG_SZ%, “B:”
HKR, “Parameters”, “RootDirEntries”, %REG_DWORD%, 0x00000200
HKR, “Parameters”, “SectorsPerCluster”, %REG_DWORD%, 0x00000002

[Strings]
QSOFT = “QSoft”
ClassName = “RAM Disk”
DiskDevDesc = “Ramdisk [QSoft]”
DiskServiceDesc = “Ramdisk [QSoft]”
InstDisk = “Ramdisk Install Disk”
;*******************************************
;Handy macro substitutions (non-localizable)
SPSVCINST_ASSOCSERVICE = 0x00000002
SERVICE_KERNEL_DRIVER = 1
SERVICE_BOOT_START = 0
SERVICE_ERROR_NORMAL = 1
REG_DWORD = 0x00010001
REG_SZ = 0x00000000
COPYFLG_NOSKIP = 2

> Sorry, I develop the usb general functional driver.

Most or 100% the irp target a FDO, not to a PDO.

So what kind of driver, should I study to access PDO.

You pass your own USB IRPs to USB PDO for USB bus to execute transactions.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

On Fri, Jan 17, 2014 at 7:01 AM, wrote:
> Sorry, I develop the usb general functional driver.
>
> Most or 100% the irp target a FDO, not to a PDO.
And where is your driver sending IOCTL_INTERNAL_USB_SUBMIT_URB?

> So what kind of driver, should I study to access PDO.
Look at the toaster bus + func samples.

Kris

>
> And:
> I will paste the INF following:
>
>
> ; RAMDISK.INF
> ; Windows 2000 installation file for installing the Ramdisk driver
> ; Copyright (c) 1990-2000 Microsoft Corporation All rights Reserved
> ; Copyright (c) 2002 QSoft [Quality Software]
>
>
> [Version]
> Signature=“$WINDOWS NT$”
> Class=RamDisk
> ClassGuid={FFA1C341-4539-11D3-B88D-00C04FAD5172}
> Provider=%QSOFT%
> DriverVer=09/30/2002,5.00.0001.0
>
> [DestinationDirs]
> DefaultDestDir = 12
> RamDiskInstaller=11
>
> [ClassInstall32]
> Addreg=RamDiskClassReg
> CopyFiles=RamDiskInstaller
>
> [RamDiskClassReg]
> HKR,0,%ClassName%
> ; If we don’t provide our own Installer32, ICON’s from “SETUPAPI.DLL” will be selected
> ; HKR,Icon,-5
> ; HKR,Icon,-159
>
> HKR,Installer32,“RAMDisk.dll,ClassInstaller”
> HKR,Icon,“105”
> HKR,EnumPropPages32,“RAMDisk.dll,PropPageProvider”
>
>
> [RamDiskInstaller]
> RAMDisk.dll,%COPYFLG_NOSKIP%
> msvcr70.dll,%COPYFLG_NOSKIP%
> mfc70u.dll,%COPYFLG_NOSKIP%
>
> [DiskCopyfiles]
> ramdisk.sys
> ramdisk.dll
>
>
> [SourceDisksNames]
> 1=%InstDisk%,
>
> [SourceDisksFiles]
> ramdisk.sys=1
>
> [Manufacturer]
> %QSOFT% = DiskDevice
>
> [DiskDevice]
> %DiskDevDesc% = DiskInstall, Ramdisk
>
> [DiskInstall.NT]
> CopyFiles = DiskCopyfiles
>
> [DiskInstall.NT.Services]
> AddService = Ramdisk, %SPSVCINST_ASSOCSERVICE%, DiskServiceInst
>
> [DiskServiceInst]
> ServiceType = %SERVICE_KERNEL_DRIVER%
> StartType = %SERVICE_BOOT_START%
> ErrorControl = %SERVICE_ERROR_NORMAL%
> DisplayName = %DiskServiceDesc%
> ServiceBinary = %12%\ramdisk.sys
> AddReg = DiskAddReg
>
> [DiskAddReg]
> HKR, “Parameters”, “BreakOnEntry”, %REG_DWORD%, 0x00000000
> HKR, “Parameters”, “DebugLevel”, %REG_DWORD%, 0x00000005
> HKR, “Parameters”, “DebugComp”, %REG_DWORD%, 0xFFFFFFFF
> HKR, “Parameters”, “DiskSize”, %REG_DWORD%, 0x00320000
> HKR, “Parameters”, “DriveLetter”, %REG_SZ%, “B:”
> HKR, “Parameters”, “RootDirEntries”, %REG_DWORD%, 0x00000200
> HKR, “Parameters”, “SectorsPerCluster”, %REG_DWORD%, 0x00000002
>
> [Strings]
> QSOFT = “QSoft”
> ClassName = “RAM Disk”
> DiskDevDesc = “Ramdisk [QSoft]”
> DiskServiceDesc = “Ramdisk [QSoft]”
> InstDisk = “Ramdisk Install Disk”
> ; *******************************************
> ;Handy macro substitutions (non-localizable)
> SPSVCINST_ASSOCSERVICE = 0x00000002
> SERVICE_KERNEL_DRIVER = 1
> SERVICE_BOOT_START = 0
> SERVICE_ERROR_NORMAL = 1
> REG_DWORD = 0x00010001
> REG_SZ = 0x00000000
> COPYFLG_NOSKIP = 2
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


Kris

workingmailing@163.com wrote:

Sorry, I develop the usb general functional driver.

Most or 100% the irp target a FDO, not to a PDO.

So what kind of driver, should I study to access PDO.

Actually, your statement is not quite correct. When you send an URB,
you’re sending it to a hub driver. Your call to IoCallDriver is going
to send to your device’s PDO, which was created by the hub. You don’t
actually know whether the PDO will handle that IRP or send it on to the
FDO, and you shouldn’t care. Both of those are handled by the same driver.

Any sample that includes bus driver functionality will have PDO and FDO
handling. The Toaster is a good example.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.