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
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.
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 met: 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
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