Port/Miniport model

Windows NT developers like Port/Miniport driver design.

_Port_ driver is almost always loaded. It communicates to OS, implements some common for specific device class functionality (like interrupt routing, hardware resource claiming, registering devices in the system, etc.). On other hand, it exports some API, useful for _MiniPort_ driver (see below).

_MiniPort_ driver can be loaded either automatically or by PnP manager. _MiniPort_ contains device detection and init code, it services standard (device class specific) requests from _Port_.

For example if scsiminiport (e.g. atapi, uniata) informs scsiport about detected devices and their capabilties, scsiport will create device objects, set up interrupt handler and inform OS about detected hardware.

About UniATA

First versions used scsiport.sys to claim detected devices and used hardware resources. All dirty work like creating device objects, initializing interrupt request service routines, command queue management, etc. was done by scsiport.sys.

Later some limitations was meat: impossibility of PCI device enumeration and searching for generic (but unknown) IDE controllers, PIO/DMA on single channel, simultaneous functioning of multiple channels of single controller with 1 interrupt). In addition command queue reordering required own queue management. Thus I made workarounds using kernel API instead of scsiport API.

Currently one of the the main problems is w2k/XP PnP model. UniATA was initially invented to work on _any_ IDE-compatible controller on _any_ machine without driver reinstall. But when device driver is installed, PnP manager remembers, for what particular hardware the driver is. On further system startups PnP manager enumerates devices and look in registry what driver should be loaded. If we attempt to connect HDD to another MotherBoard (with different controller), PnP manager will not find suitable driver and system will never boot up.

Another thing - non pnp-enumerated devices. Device driver for such device will be loaded anyway (this is driver, which does not belong to any specific device driver class). If such driver simply scan PCI bus and inform ScsiPort about detected controllers, PnP manager will decide, that some devices in system are not pnp-compliant and block Sleep/Hibernate and IDE hot-swap functionality.

Both cases described above comes from scsiport behavior.

We discussed this problem with Vitaliy and came to solution: For w2k/XP UniATA needs own analogue of scsiport, which will always expose to OS either single controller or a set of hardware idependent virtual controllers. All bus scans and device-dependent staff will be hidden from OS.

In this case we shall have logical controller and connected device enumaretion like it was under NT4 (I think that it is much better and flexible architecture)

It will also has dummy hardware dependent do-nothing driver. This do-nothing driver will be installed for each newly detected controller to make PnP manager happy. Like currently UniATA does: it claims in .inf-file all known controllers.