Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master

Dec 13, 2012

  1. [safehook,mainbus] Switch safe hook over to a mini-driver

    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
    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.
    authored December 13, 2012
  2. [safehook] Probe for an ancestor hook when queried

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

    Cache a record of a safe hook's ancestor in the chain.
    authored December 12, 2012
  4. [safehook] Claim the safe hook for the FDO

    (And "unclaim" it when the FDO is removed.)
    authored December 12, 2012
  5. [driver] Add missing extern specifiers

    authored December 12, 2012
  6. [driver] Add WvlMapUnmapLowMemory

    For mapping/unmapping the first 1 MiB of memory.
    authored December 12, 2012
  7. [safehook] Implement WvSafeHookDriveDevice

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

    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.
    authored December 12, 2012
  9. [mainbus] Use WvlAssignDeviceToBus

    Thus hiding some of the "is linked" implementation details.
    authored December 12, 2012
  10. [driver] New WvlAssignDeviceToBus function

    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.
    authored December 12, 2012

Dec 11, 2012

  1. [driver] Use WvDriverLinkDevice and WvDriverUnlinkDevice

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

    authored December 11, 2012
  3. [mainbus] Use WvlMergeDeviceRelations

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

    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.
    authored December 11, 2012
  5. [safehook] Introduce safe hook bus FDO

    There is little purpose to a safe hook bus other than to possibly
    expose another safe hook PDO.
    authored December 10, 2012

Dec 10, 2012

  1. [safehook] WvlGetSafeHook should return a SEG16:OFF16

    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.
    authored December 10, 2012
  2. [safehook] Alignment for WvSafeHookDefaultDummyIds

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

    authored December 10, 2012
  4. [mainbus] Add WvDummyPnpQueryBusInfo

    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.
    authored December 10, 2012
  5. [safehook] Introduce WvSafeHookDummyIds

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

    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.
    authored December 09, 2012

Dec 09, 2012

  1. [mainbus] WvDummyAdd now takes a mini-driver parameter

    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.
    authored December 09, 2012
  2. [driver,mainbus] Fix device tear-down

    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.
    authored December 09, 2012
  3. [mainbus] Make dummy devices mini-driver devices

    AoE and HTTPDisk adjusted to add their dummy devices using
    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.
    authored December 09, 2012
  4. [libbus,mainbus] Lessen the PDO-adding hacks

    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.
    authored December 09, 2012
  5. [driver,mainbus] Track a device's parent bus

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

    In preparation for using WvlPassIrpUp, instead.
    authored December 09, 2012
  7. [mainbus] Give WvMainBusMiniDriver external linkage

    So it can be accessed by dummyirp.c.
    authored December 09, 2012
  8. [mainbus] Change WvDummyIds to WvDummyPnpQueryId

    authored December 08, 2012
  9. [mainbus] Changes to WvDummyIrpDispatch...

    ...and changed WvDummyPnp to WvDummyDispatchPnpIrp.
    authored December 08, 2012
  10. [mainbus] Rename WvBusIrpDispatch to WvMainBusIrpDispatch

    authored December 08, 2012
  11. [mainbus] Change parameters for WvDummyAdd

    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.
    authored December 08, 2012

Dec 08, 2012

  1. [mainbus,aoe,httpdisk] Responsibility for WvlBusAddNode... no longer WvDummyAdd's.  A dummy device should be possible
    to add to any bus.
    authored December 08, 2012
  2. [mainbus] Don't send WvDummyAdd request through an IRP

    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.
    authored December 08, 2012
  3. [mainbus] Add interim hack to WvDummyAdd_

    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
    authored December 08, 2012
Something went wrong with that request. Please try again.