disk.sys/partmgr.sys
in [Device Drivers]
|
From: Mahboob on 31 Jan 2009 15:55 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: Don Burn on 31 Jan 2009 16:19 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: Mahboob on 31 Jan 2009 16:37 Thank you for quick reply. In devicetree (for the system I am using) I do not see any stopport.sys or scsiport.sys, but I can see atapi.sys and it lists IRP_MJ_INTERNAL_DEVICE_CONTROL in the function supported list. "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: Mahboob on 31 Jan 2009 17:13 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: Don Burn on 31 Jan 2009 17:50 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. >> >> >>
|
Next
|
Last
Pages: 1 2 Prev: IoGetDeviceProperty returns STATUS_OBJECT_NAME_NOT_FOUND Next: Confusing INFGate.EXE Errors |