Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Branch: master
Commits on Dec 13, 2012
  1. [safehook,mainbus] Switch safe hook over to a mini-driver

    Shao Miller authored
    Fix a bug in src/winvblock/mainbus/dummyirp.c where such a PDO
    should really respond directly to an IRP_MJ_PNP:IRP_MN_START_DEVICE.
    
    Assign a PDO to the safe hook FDO bus in
    WvSafeHookPnpQueryDeviceRelations.  That way, it's linked for the
    the later PnP probe for its capabilities, and also linked for its
    later removal.
    
    Fix a bug in WvSafeHookPnpRemoveDevice where a safe hook FDO would
    try to pass WvlDeleteDevice a null pointer.
    
    Add a DummyPdo member to S_WV_SAFE_HOOK_DUMMY_WRAPPER so we can
    calculate the offset of the dummy IDs relative to the wrapper's
    beginning.
    
    Remove a hack for the old, non-mini-driver safe hook PDOs.
    
    Actually create the safe hook PDO in WvlCreateSafeHookDevice,
    instead of it calling the old, non-mini-driver code.
  2. [safehook] Probe for an ancestor hook when queried

    Shao Miller authored
    When queried for BusRelations, a safe hook FDO should probe the
    previous hook in the chain and create a PDO, if appropriate.
  3. [safehook] Note the previous INT 0x13 handler

    Shao Miller authored
    Cache a record of a safe hook's ancestor in the chain.
  4. [safehook] Claim the safe hook for the FDO

    Shao Miller authored
    (And "unclaim" it when the FDO is removed.)
  5. [driver] Add missing extern specifiers

    Shao Miller authored
  6. [driver] Add WvlMapUnmapLowMemory

    Shao Miller authored
    For mapping/unmapping the first 1 MiB of memory.
  7. [safehook] Implement WvSafeHookDriveDevice

    Shao Miller authored
    This will test for a safe hook PDO and drive it with an FDO.
  8. [safehook] Unlink and delete any child PDO

    Shao Miller authored
    When the FDO is established, it will produce and link the child
    PDO (if there is one), so this is the corresponding tear-down.
    
    Note: WvSafeHookDriveDevice isn't actually implemented yet.
  9. [mainbus] Use WvlAssignDeviceToBus

    Shao Miller authored
    Thus hiding some of the "is linked" implementation details.
  10. [driver] New WvlAssignDeviceToBus function

    Shao Miller authored
    This function doesn't deal with how a bus device responds to a
    BusRelations query (that's up to each mini-driver), but it
    does increment or decrement a reference count on the bus
    device, so each assignment call must be matched by a
    corresponding unassignment call at some point during the child
    device's lifetime.
Commits on Dec 11, 2012
  1. [driver] Use WvDriverLinkDevice and WvDriverUnlinkDevice

    Shao Miller authored
    These two new functions are now used by WvlAttachDeviceToDeviceStack
    and WvlDetachDevice to set and unset the "linked" flag for a device.
  2. [safehook] Use WvlMergeDeviceRelations

    Shao Miller authored
  3. [mainbus] Use WvlMergeDeviceRelations

    Shao Miller authored
    Also, upon failure, release any higher device's report.
  4. [driver] WvlMergeDeviceRelations utility function

    Shao Miller authored
    Because it's fairly common to accumulate device relations during
    processing of an IRP_MJ_PNP:IRP_MN_QUERY_DEVICE_RELATIONS, this
    utility function should help with taking a higher device's list
    and merging in the current device's list.
  5. [safehook] Introduce safe hook bus FDO

    Shao Miller authored
    There is little purpose to a safe hook bus other than to possibly
    expose another safe hook PDO.
Commits on Dec 10, 2012
  1. [safehook] WvlGetSafeHook should return a SEG16:OFF16

    Shao Miller authored
    Other than the IDs, the SEG16:OFF16 is really the only other
    piece of what makes a safe hook PDO unique.  The IDs could be
    taken care of by the dummy logic.
  2. [safehook] Alignment for WvSafeHookDefaultDummyIds

    Shao Miller authored
    A future call to WvDummyAdd should have an aligned ExtraDataOffset
    argument, so calculate it ahead of time.
  3. [mainbus] Add WvDummyPnpQueryCapabilities

    Shao Miller authored
    Supports IRP_MJ_PNP:IRP_MN_QUERY_CAPABILITIES.
  4. [mainbus] Add WvDummyPnpQueryBusInfo

    Shao Miller authored
    Supports IRP_MJ_PNP:IRP_MN_QUERY_BUS_INFORMATION.  There's a to-do
    note, since it's possible that dummy PDOs could query a parent bus
    device for this information; undecided.
  5. [safehook] Introduce WvSafeHookDummyIds

    Shao Miller authored
    Generate a safe hook instance's dummy IDs, suitable for use
    with WvDummyAdd.  It isn't currently used, but it's planned.
  6. [mainbus] Dummy support for DeviceTextDescription

    Shao Miller authored
    Dummy PDOs now support the IRP_MJ_PNP:IRP_MN_QUERY_DEVICE_TEXT,
    DeviceTextDescription type.  This is the description that shows
    up in the "Found New Hardware Wizard", if an .INF file doesn't
    override it.
Commits on Dec 9, 2012
  1. [mainbus] WvDummyAdd now takes a mini-driver parameter

    Shao Miller authored
    The function now takes an optional mini-driver parameter.  If
    it is null, the main bus will own the dummy device.  If non-null,
    the specified mini-driver will own the dummy device.
  2. [driver,mainbus] Fix device tear-down

    Shao Miller authored
    Remove the NotAvailable member of the WV_S_DEV_EXT structure.
    Replace part of its use with a new CvWvlDeviceFlagAvailable flag.
    
    Introduce a new CvWvlDeviceFlagLinked flag.  This flag is set
      - For PDOs: When they are added to a parent bus
      - For FDOs: When they are attached to a device stack
    
    Introduce a new CvWvlDeviceFlagThread flag.  This flag controls
    whether or not IRPs and work items can be added to the device's
    IRP queue.
    
    The dummy PDO logic now handles a surprise-removal by incrementing
    the resource usage for the device and decrementing it during the
    subsequent IRP_MN_REMOVE_DEVICE.  This prevents the device's
    thread from stopping and deleting the device before the removal
    has been completed.  (See below regarding the resource usage.)
    
    Device tear-down now works like this: The device's thread always
    has ultimate responsibility for deleting a device.  The thread
    will accept IRPs and work items until such a time as:
      - The device is not linked (see explanation above)
      - The device is no longer available due to WvlDeleteDevice
      - The device, as a tracked resource, is only being used by
        the thread
    
    If any of these conditions are false, the thread continues to
    service IRPs and work items.  It is up to the IRP dispatcher
    to allow PnP IRPs to be processed and to disallow other IRPs.
    (A mini-driver might have special PnP handling or other IOCTLs
    that it wishes to service, even when a device is on its way
    to deletion.)
    
    WvMainBusAddDevice and WvlAttachDeviceToDeviceStack both link
    a device.  WvMainBusRemoveDevice and WvlDetachDevice both unlink
    a device.
  3. [mainbus] Make dummy devices mini-driver devices

    Shao Miller authored
    AoE and HTTPDisk adjusted to add their dummy devices using
    WvlAddDeviceToMainBus.
    
    Removed unused WvDummyRemove function.
    
    Removed OldDevice member of S_WVL_DUMMY_PDO.
    
    Fixed a bug in WvMainBusPnpRemoveDevice where it was trying to
    walk a list that was being modified in between steps.  Heh.
    
    dummyirp.c now uses WvlPassIrpUp instead of IoCompleteRequest.
    Tried to remove traces of the old style involving "bus nodes"
    and WV_S_DEV_T.  Use WvlCreateDevice instead of IoCreateDevice
    and use WvlDeleteDevice instead of IoDeleteDevice.
    
    Fixed an arithmetic bug in WvMainBusRemoveDevice.
    
    TODO: Dummy device removal doesn't quite work.
  4. [libbus,mainbus] Lessen the PDO-adding hacks

    Shao Miller authored
    Old-style "bus nodes," when added to the main bus using the
    old-style methods, will now _also_ be added to the main bus
    using the new methods.  Unfortunately, this means that removing
    the devices isn't working so well, just now.
  5. [driver,mainbus] Track a device's parent bus

    Shao Miller authored
    It's possible that any mini-driver PDO might wish to know what
    its parent bus device is, so track it.
  6. [mainbus] Replace WvlIrpComplete calls with IoCompleteRequest

    Shao Miller authored
    In preparation for using WvlPassIrpUp, instead.
  7. [mainbus] Give WvMainBusMiniDriver external linkage

    Shao Miller authored
    So it can be accessed by dummyirp.c.
  8. [mainbus] Change WvDummyIds to WvDummyPnpQueryId

    Shao Miller authored
  9. [mainbus] Changes to WvDummyIrpDispatch...

    Shao Miller authored
    ...and changed WvDummyPnp to WvDummyDispatchPnpIrp.
  10. [mainbus] Change parameters for WvDummyAdd

    Shao Miller authored
    It is starting to more closely resemble WvlCreateDevice, because
    eventually it will call it.
    
    A caller, such as the safe hook mini-driver, could call this
    function to produce a dummy device with the specified IDs _and_
    extend that dummy device with additional safe-hook-specific
    data.  This is actually the goal, since a safe hook PDO only
    has to carry around a note about where the INT 0x13 hook is.
    
    Crazy parameter-checking in this function...  A dummy PDO device
    extension will usually be followed by some dummy IDs, which are
    always going to be wrapped with an even larger structure of
    arbitrary size, and then the caller might want more storage
    beyond all that, and it all has to be aligned properly.  Phew.
Commits on Dec 8, 2012
  1. [mainbus,aoe,httpdisk] Responsibility for WvlBusAddNode...

    Shao Miller authored
    ...is no longer WvDummyAdd's.  A dummy device should be possible
    to add to any bus.
  2. [mainbus] Don't send WvDummyAdd request through an IRP

    Shao Miller authored
    A user-land utility still can, but there's not really a need
    for a driver to, unless the driver is trying to avoid a dependency
    on WinVBlock, which seems kind of contrived.
  3. [mainbus] Add interim hack to WvDummyAdd_

    Shao Miller authored
    The semantics for adding a dummy device to a bus will eventually be
    that the caller creates a dummy device, then adds it to whatever
    bus.  Right now, WvDummyAdd does both and chooses the main bus
    unconditionally, but we don't want that.
    
    While things are shuffled around, there will be some hacks just to
    make the transition smooth.  It's good if WinVBlock still works
    after every commit.
    
    In this one WvDummyAdd_ more resembles what the final
    WvlCreateDummyDevice will look like.  It ties all details together
    into a single device extension which is freed when the device is
    deleted.
Something went wrong with that request. Please try again.