From ReactOS

hpoussin: i have a question for you

<arty> hpoussin: i have a question for you
<hpoussin> arty, yes?
<arty> I get that AddDevice is called by a bus driver to signal the owning
          driver that a new device has come to exist
<arty> and that the contents of the BaseConfigVector is a configuration_list
<arty> but my question is, how does the bus driver know which device to call
          AddDevice on?
<arty> so far, i see how everything works
<hpoussin> arty, bus driver returns PDOs for its children devices when it get
           a IRP_MJ_PNP / IRP_MN_QUERY_RELATIONS / BusRelations
<arty> it's actually pretty smart
<arty> hpoussin: but what knows who the PDO belongs to?
<hpoussin> arty, then, pnpmgr sends lots of IRP_MJ_PNP to know information
           about the PDO, then loads the associated driver according to the
           PDO' hardware ID (if not already loaded), and then calls AddDevice
           in the PDO driver
<arty> ahh ok
<hpoussin> arty, sorry, i don't understand your question: "but what knows who
           the PDO belongs to?"
<arty> so pnpmgr consumes the inf information to know which hardware ids have
          which driver
<arty> is that right?
<hpoussin> yes
<arty> ahh, then matches the hardware id and send the pdo to the target
          service?
<hpoussin> to be exact: first, it looks in registry to find if the driver is
           already installed. if not, it looks in .inf files the related
           driver (only with pnp patch in TRUNK)
<arty> ahh
<hpoussin> and then yes, pnpmgr send the pdo to the target service
<arty> last question: how does it know the name of the device to open?
<hpoussin> arty, you mean "PCI\VEN_XXX&DEV_YYY\ZZZ" ?
<arty> no like \Device\Serenum or \Device\Kbdclass ... is it just
          \Device\<ServiceName> ?
<hpoussin> \Device\Serenum and \Device\Kbdclass don't exist...
<hpoussin> you maybe mean the "\Device\Serial0" ?
<arty> hpoussin: but how does \Device\Serial0 even come to exist before any
          AddDevice have been called?
<arty> or maybe i'm not getting something still
<hpoussin> \Device\Serial0 is created by Serial driver
<hpoussin> when Serial/AddDevice is called
<arty> how does the pnp manager get the Serial driver object?
<hpoussin> arty, http://www.rafb.net/paste/results/QfVxnR54.html
<hpoussin> &DeviceNode->ServiceName = "Serial"
<arty> ahh
<arty> that's the part i was missing
<arty> thanks
<arty> do you mind if i wikify our conversation?
<hpoussin> np

hpoussin's wrap-up

<hpoussin> np
<hpoussin> 1) pnpmgr sends IRP_MJ_PNP/IRP_MN_QUERY_RELATIONS/BusRelations to
           ACPI FDO
<hpoussin> 2) ACPI FDO returns a PDO for serial port
<hpoussin> 3) pnpmgr sends IRP_MJ_PNP/IRP_MN_QUERY_ID to the PDO to get its id
<hpoussin> 4) ACPI returns "ACPI\PNP0501\1" for the serial port PDO
<hpoussin> 5) pnpmgr looks in registry if ACPI\PNP501\1 device is already
           installed. if yes, read the service name value. if no, stop
           processing of this device
<hpoussin> 6) pnp loads serial.sys (if not already done), add call AddDevice
<hpoussin> 7) pnp loads serenum.sys (if not already done), call its AddDevice
<arty> (and 7 happens because it's an upper filter, ya?)
<hpoussin> 8) send IRP_MJ_PNP/IRP_MN_START_DEVICE to top of stack
<hpoussin> yes
<hpoussin> (top of stack = serenum FDO)
<arty> heh cool
<hpoussin> then, umpnpmgr is launched
<arty> oh only after?
<hpoussin> yes
<hpoussin> 1) umpnpmgr gets an event for each device arrival (including serial
           port, which is not started because it is not installed)
<hpoussin> 2) if the device is not started, it installs it by using newdev.dll
           and setupapi.dll
<hpoussin> 3) if install succeed, umpnpmgr asks pnpmgr (kernel mode part) to
           start the device, ie go to step 5 of the first list
<hpoussin> arty, now, you have to do the wiki page, and i'll see if you have
           understand :)