Prev: IoGetDeviceProperty returns STATUS_OBJECT_NAME_NOT_FOUND
Next: Confusing INFGate.EXE Errors
From: Mahboob on 31 Jan 2009 18:14
From the figure one will correctly conclude that pci.sys is lowest level
driver, but it also gives the impression that pciide.sys and pciidex.sys lie
in between atapi.sys and pci.sys. I thought it would be piidex.sys,
pciide.sys, atapi.sys and pci.sys in that order.

Thanks.

"Don Burn" wrote:

> What PCI.sys does is manage access to the PCI bus. The PCI driver is
> repsonsible for finding the device on the PCI bus, reporting it to the I/O
> subsystem with the resources (ports, memory and interrupts for the device)
> and managing the overall resources of the bus. So PCI.sys finds the atapi
> device and lets the system know that a device with that device ID is
> present, at which point the Plug andPlay subsystem loads the appropriate
> driver on top of PCI.sys which provides the physical device object for the
> device. So yes PCI.sys (or another bus driver is always the bottom of the
> stack).
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
>
> "Mahboob" <Mahboob(a)discussions.microsoft.com> wrote in message
> news:069B496D-6764-4985-AEF2-D1DE73542D54(a)microsoft.com...
> > Dear Don,
> >
> > One more question:
> >
> > By looking at deviceree, I would assume that pciidex.sys, pciide.sys are
> > above atapi.sys in the driver stack. atapi.sys is the lowest one that
> > actually reads the hardware IO ports asit uses
> > READ_PORT_BUFFER_USHORT
> > READ_PORT_UCHAR
> > READ_PORT_USHORT
> > WRITE_PORT_BUFFER_USHORT
> > WRITE_PORT_UCHAR
> >
> > IBut the picture in http://msdn.microsoft.com/en-us/library/dd445532.aspx
> > is
> > bit confusing to me. Could you shed some light. Thank you.
> >
> >
> > "Don Burn" wrote:
> >
> >> No, it is sitting below the partmgr which is not the class driver.
> >> IRP_MJ_SCSI is a redefinition of
> >> IRP_MJ_INTERNAL_DEVICE_CONTROL, it is in wdm.h. The class driver does
> >> typically scsiport, storport or atapi.
> >>
> >>
> >> --
> >> Don Burn (MVP, Windows DDK)
> >> Windows Filesystem and Driver Consulting
> >> Website: http://www.windrvr.com
> >> Blog: http://msmvps.com/blogs/WinDrvr
> >>
> >>
> >>
> >>
> >> "Mahboob" <Mahboob(a)discussions.microsoft.com> wrote in message
> >> news:ABC4A202-44EF-4910-AF6A-D1A4001242F4(a)microsoft.com...
> >> > When I use the device manager to look at drivers for my western digital
> >> > disk
> >> > drive listed under disk drives I see that it uses disk.sys and
> >> > partmgr.sys.
> >> > My questions are:
> >> >
> >> > 1. I assume that disk.sys is the class driver. If I use the DDK tool
> >> > devicetree I can see that it is sitting on top of partmgr.sys. Is the
> >> > partmgr.sys the storage port driver?
> >> >
> >> > 2. By looking at the code in DDK's sample I would conclude that
> >> > disk.sys
> >> > sends IRP_MJ_SCSI to send SRBs to port driver. But I do not see
> >> > IRP_MJ_SCSI
> >> > listed in "Major function code supported" listed by devicetree for
> >> > partmgr.sys. Any idea why?
> >> >
> >> > 3. If partmgr.sys does not handle the IRP_MJ_SCSI from disk.sys, then
> >> > who
> >> > handles them.
> >>
> >>
> >>
>
>
>
From: Maxim S. Shatskih on 31 Jan 2009 18:24
> 1. I assume that disk.sys is the class driver. If I use the DDK tool
> devicetree I can see that it is sitting on top of partmgr.sys. Is the
> partmgr.sys the storage port driver?

No, UpperFilter for Disk class.

ScsiPort or StorPort or Atapi or Ataport or UsbStor or Sbp2Port are storage ports.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Maxim S. Shatskih on 31 Jan 2009 18:28
> By looking at deviceree, I would assume that pciidex.sys, pciide.sys are
> above atapi.sys in the driver stack. atapi.sys is the lowest one that
> actually reads the hardware IO ports asit uses
> READ_PORT_BUFFER_USHORT
> READ_PORT_UCHAR
> READ_PORT_USHORT
> WRITE_PORT_BUFFER_USHORT
> WRITE_PORT_UCHAR

I think it is more complex.

Atapi is the storage port bus driver (enumerates disks as PDOs) and the FD for the _IDE channel_.

Atapi can access hardware alone, but only in PIO mode using READ_PORT_BUFFER_USHORT on port 0x1f0.

To use DMA, Atapi needs the support from the PDO below it (IDE channel PDO), which is created by the PCIIDEX bus driver. PCIIDEX bus driver is also an FD for the _IDE controller_.

PCIIDE is one of the pluggable miniports to PCIIDEX, namely the driver for Intel's DMA-capable IDE controlers. VIAIDE is IIRC another such miniport. MSAHCI is yet another.

The PCIIDE/PCIIDEX combo only enumerates the channels on the IDE controller and provide the DMA feature for Atapi.

--
Maxim S. Shatskih

Windows DDK MVP

maxim(a)storagecraft.com

http://www.storagecraft.com


First  |  Prev  | 
Pages: 1 2
Prev: IoGetDeviceProperty returns STATUS_OBJECT_NAME_NOT_FOUND
Next: Confusing INFGate.EXE Errors