Keeping bus driver version and enumerated device driver version in sync

NTDEV
1

My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

2

How about your function drivers supporting bus versions N and N-1? This way they can be updated on the fly while the underlying bus remains the same

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: James Harper
Sent: Sunday, December 21, 2008 9:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Keeping bus driver version and enumerated device driver version in sync

My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” wrote in message
news:xxxxx@ntdev…
My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

4

While that would be ideal, in reality it is difficult particularly where the
underlying technology (in this case a virtualized system IO bus) is changing
frequently and/or extensively as it is more or less in a rapid development
prototyping stage. If there are functional incompatibilities that cannot be
managed by a support N and N-1 strategy, or at least not managed easily,
then forcing a new function driver by producing a different enough PnP ID
seems like a safe way to go to me.
Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:

> Doron is very correct in having the support for earlier versions of the
> buss
> driver in the function drivers. Also most Windows components use a
> registration structure to indicate the version of the driver making the
> call. This can be done in a bi-directional way so both can communicate
> their versions and maybe what version clients they can support.
>
> “James Harper” wrote in message
> news:xxxxx@ntdev…
> My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
> device (the presence of which indicates that it is a Xen machine), and
> then enumerates network, block (scsiport), and some other devices. The
> enumerated devices may be present at boot time or can be hot-added after
> boot.
>
> I have encountered the situation before where the hot-added device
> remembers the version of the driver it was hot-added with previously,
> even though the driver has since been upgraded. At best this just
> doesn’t work. At worst, a system crash could result (obviously only
> because of a bug in my driver though).
>
> Also, when I upgrade the drivers on a running system, what happens is:
> . bus driver updates but the bus driver is connected to a block device
> which is holding the paging file and operating system, so the
> unload/reload is deferred
> . scsiport driver for the system disk also deferred as above
> . network driver upgrades, unloads, but then can’t reload because the
> bus driver version doesn’t match the upgraded network driver version.
> Suddenly I have no network anymore until the next reboot.
>
> While writing this it occurred to me that maybe I should put a version
> number into the enumerated device, eg currently it is ‘xen\vbd’
> (scsiport) or ‘xen\vif’ (network), but maybe it should be
> ‘xen\vbd_’ or something like that? Will things like boot
> devices get confused? Time for some testing I think :slight_smile:
>
> Is there a ‘best practices’ document or a blog somewhere that discusses
> this?
>
> Thanks
>
> James
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

5

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig > wrote:
Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” > wrote in message
news:xxxxx@ntdev…
My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

Is it possible that your t9 itself has a *spilling* mistake :slight_smile:

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 9:23 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:

Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” wrote in message
news:xxxxx@ntdev…

My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Unless I misread, installing new function drivers for his disk and net pdos
was exactly what he intended to do and his problem was that sometimes the
old incompatible versions were getting installed instead.
I think James is respinning his bus (virtual) hardware and changing its
design and all of his associated pv drivers need to get up-rev’d too. When
the design/implementation stabilizes backwards compatibility should be
supported, probably not worthwhile right now. but that is his call.

Mark Roddy

On Mon, Dec 22, 2008 at 12:23 PM, Doron Holan wrote:

> Adding a version to the instance id will change the identity of the
> device. 2 potential issues.
>
> 1 IIRC, the device instance id should be the same as the first reported hw
> id, so if you change the hw id to include the version, you might need to
> spin up new INFs on every change. I guess you can keep you hw id without the
> version in it as the 2nd hw id reported.
>
> 2 doing this for the boot stack might be very bad mojo because windows
> needs the boot device to be accessible at the early stages of boot, well
> before your revised storage drivers can be installed. The critical device
> database may save you here, but that only works if your driver was
> previously installed on the same hw id
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> ------------------------------
> From: Mark Roddy
> Sent: Monday, December 22, 2008 6:22 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Keeping bus driver version and enumerated device
> driver version in sync
>
> While that would be ideal, in reality it is difficult particularly where
> the underlying technology (in this case a virtualized system IO bus) is
> changing frequently and/or extensively as it is more or less in a rapid
> development prototyping stage. If there are functional incompatibilities
> that cannot be managed by a support N and N-1 strategy, or at least not
> managed easily, then forcing a new function driver by producing a different
> enough PnP ID seems like a safe way to go to me.
> Mark Roddy
>
>
> On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:
>
>> Doron is very correct in having the support for earlier versions of the
>> buss
>> driver in the function drivers. Also most Windows components use a
>> registration structure to indicate the version of the driver making the
>> call. This can be done in a bi-directional way so both can communicate
>> their versions and maybe what version clients they can support.
>>
>> “James Harper” wrote in message
>> news:xxxxx@ntdev…
>> My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
>> device (the presence of which indicates that it is a Xen machine), and
>> then enumerates network, block (scsiport), and some other devices. The
>> enumerated devices may be present at boot time or can be hot-added after
>> boot.
>>
>> I have encountered the situation before where the hot-added device
>> remembers the version of the driver it was hot-added with previously,
>> even though the driver has since been upgraded. At best this just
>> doesn’t work. At worst, a system crash could result (obviously only
>> because of a bug in my driver though).
>>
>> Also, when I upgrade the drivers on a running system, what happens is:
>> . bus driver updates but the bus driver is connected to a block device
>> which is holding the paging file and operating system, so the
>> unload/reload is deferred
>> . scsiport driver for the system disk also deferred as above
>> . network driver upgrades, unloads, but then can’t reload because the
>> bus driver version doesn’t match the upgraded network driver version.
>> Suddenly I have no network anymore until the next reboot.
>>
>> While writing this it occurred to me that maybe I should put a version
>> number into the enumerated device, eg currently it is ‘xen\vbd’
>> (scsiport) or ‘xen\vif’ (network), but maybe it should be
>> ‘xen\vbd_’ or something like that? Will things like boot
>> devices get confused? Time for some testing I think :slight_smile:
>>
>> Is there a ‘best practices’ document or a blog somewhere that discusses
>> this?
>>
>> Thanks
>>
>> James
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

8

My point was that he might not even be able to boot if he enumerates a new storage if he expects the new drivers to be installed on reboot

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Mark Roddy
Sent: Monday, December 22, 2008 9:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Unless I misread, installing new function drivers for his disk and net pdos was exactly what he intended to do and his problem was that sometimes the old incompatible versions were getting installed instead.

I think James is respinning his bus (virtual) hardware and changing its design and all of his associated pv drivers need to get up-rev’d too. When the design/implementation stabilizes backwards compatibility should be supported, probably not worthwhile right now. but that is his call.

Mark Roddy

On Mon, Dec 22, 2008 at 12:23 PM, Doron Holan > wrote:
Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

________________________________
From: Mark Roddy >
Sent: Monday, December 22, 2008 6:22 AM

To: Windows System Software Devs Interest List >
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig > wrote:
Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” > wrote in message
news:xxxxx@ntdev…
My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

9

Me have no T9 on my phone, just a full qwerty keyboard

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Prokash Sinha
Sent: Monday, December 22, 2008 9:31 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Is it possible that your t9 itself has a spilling mistake :slight_smile:

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.
----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Monday, December 22, 2008 9:23 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

________________________________
From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig > wrote:
Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” > wrote in message
news:xxxxx@ntdev…
My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

10

Ah, I meant to say your phone.

" Sent from my phone with no t9, all ****spilling*** mistakes are not intentional"

Not sure if spilling == spelling !

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 9:59 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Me have no T9 on my phone, just a full qwerty keyboard

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Prokash Sinha
Sent: Monday, December 22, 2008 9:31 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Is it possible that your t9 itself has a spilling mistake :slight_smile:

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 9:23 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

----------------------------------------------------------------------------
From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:

Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” wrote in message
news:xxxxx@ntdev…

My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

The mistake is intentional :wink:

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Prokash Sinha
Sent: Monday, December 22, 2008 10:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Ah, I meant to say your phone.

" Sent from my phone with no t9, all *spilling mistakes are not intentional"

Not sure if spilling == spelling !

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.
----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Monday, December 22, 2008 9:59 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Me have no T9 on my phone, just a full qwerty keyboard

d

Sent from my phone with no t9, all spilling mistakes are not intentional.


From: Prokash Sinha >
Sent: Monday, December 22, 2008 9:31 AM
To: Windows System Software Devs Interest List >
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Is it possible that your t9 itself has a spilling mistake :slight_smile:

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.
----- Original Message -----
From: Doron Holanmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Monday, December 22, 2008 9:23 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.


From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig > wrote:
Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” > wrote in message
news:xxxxx@ntdev…
My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

12

Okay I will buy it …

Should I put something like this specially on those threads …

" …, all littering mistakes are not intentional and may not be from english litters "

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 10:10 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

The mistake is intentional :wink:

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

From: Prokash Sinha
Sent: Monday, December 22, 2008 10:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Ah, I meant to say your phone.

" Sent from my phone with no t9, all *spilling mistakes are not intentional"

Not sure if spilling == spelling !

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 9:59 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Me have no T9 on my phone, just a full qwerty keyboard

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

----------------------------------------------------------------------------
From: Prokash Sinha
Sent: Monday, December 22, 2008 9:31 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Is it possible that your t9 itself has a spilling mistake :slight_smile:

Well, as if I’ve to sign something !
Prokash Sinha
http://prokash.squarespace.com
Success has many fathers, but failure is an orphan.

----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Monday, December 22, 2008 9:23 AM
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

Adding a version to the instance id will change the identity of the device. 2 potential issues.

1 IIRC, the device instance id should be the same as the first reported hw id, so if you change the hw id to include the version, you might need to spin up new INFs on every change. I guess you can keep you hw id without the version in it as the 2nd hw id reported.

2 doing this for the boot stack might be very bad mojo because windows needs the boot device to be accessible at the early stages of boot, well before your revised storage drivers can be installed. The critical device database may save you here, but that only works if your driver was previously installed on the same hw id

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

--------------------------------------------------------------------------
From: Mark Roddy
Sent: Monday, December 22, 2008 6:22 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Keeping bus driver version and enumerated device driver version in sync

While that would be ideal, in reality it is difficult particularly where the underlying technology (in this case a virtualized system IO bus) is changing frequently and/or extensively as it is more or less in a rapid development prototyping stage. If there are functional incompatibilities that cannot be managed by a support N and N-1 strategy, or at least not managed easily, then forcing a new function driver by producing a different enough PnP ID seems like a safe way to go to me.

Mark Roddy

On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:

Doron is very correct in having the support for earlier versions of the buss
driver in the function drivers. Also most Windows components use a
registration structure to indicate the version of the driver making the
call. This can be done in a bi-directional way so both can communicate
their versions and maybe what version clients they can support.

“James Harper” wrote in message
news:xxxxx@ntdev…

My Xen PV drivers consist of a bus driver that attaches to a virtual PCI
device (the presence of which indicates that it is a Xen machine), and
then enumerates network, block (scsiport), and some other devices. The
enumerated devices may be present at boot time or can be hot-added after
boot.

I have encountered the situation before where the hot-added device
remembers the version of the driver it was hot-added with previously,
even though the driver has since been upgraded. At best this just
doesn’t work. At worst, a system crash could result (obviously only
because of a bug in my driver though).

Also, when I upgrade the drivers on a running system, what happens is:
. bus driver updates but the bus driver is connected to a block device
which is holding the paging file and operating system, so the
unload/reload is deferred
. scsiport driver for the system disk also deferred as above
. network driver upgrades, unloads, but then can’t reload because the
bus driver version doesn’t match the upgraded network driver version.
Suddenly I have no network anymore until the next reboot.

While writing this it occurred to me that maybe I should put a version
number into the enumerated device, eg currently it is ‘xen\vbd’
(scsiport) or ‘xen\vif’ (network), but maybe it should be
‘xen\vbd_’ or something like that? Will things like boot
devices get confused? Time for some testing I think :slight_smile:

Is there a ‘best practices’ document or a blog somewhere that discusses
this?

Thanks

James

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

13

Yes I understand, but I think James was having the opposite problem, with
old drivers replacing good new ones and causing his system, which once
worked, to die a virtual death.
Once his xenbus has settled down and is not growing incompatible new
features, building in backward compatibility would be an excellent idea.

The point being that changing the hardwareid is easy and solves his
immediate problem while fitting in backwards compatibility is not so easy.

Mark Roddy

On Mon, Dec 22, 2008 at 12:56 PM, Doron Holan wrote:

> My point was that he might not even be able to boot if he enumerates a
> new storage if he expects the new drivers to be installed on reboot
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not intentional.
>
> ------------------------------
> From: Mark Roddy
> Sent: Monday, December 22, 2008 9:36 AM
>
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Keeping bus driver version and enumerated device
> driver version in sync
>
> Unless I misread, installing new function drivers for his disk and net
> pdos was exactly what he intended to do and his problem was that sometimes
> the old incompatible versions were getting installed instead.
> I think James is respinning his bus (virtual) hardware and changing its
> design and all of his associated pv drivers need to get up-rev’d too. When
> the design/implementation stabilizes backwards compatibility should be
> supported, probably not worthwhile right now. but that is his call.
>
> Mark Roddy
>
>
> On Mon, Dec 22, 2008 at 12:23 PM, Doron Holan wrote:
>
>> Adding a version to the instance id will change the identity of the
>> device. 2 potential issues.
>>
>> 1 IIRC, the device instance id should be the same as the first reported hw
>> id, so if you change the hw id to include the version, you might need to
>> spin up new INFs on every change. I guess you can keep you hw id without the
>> version in it as the 2nd hw id reported.
>>
>> 2 doing this for the boot stack might be very bad mojo because windows
>> needs the boot device to be accessible at the early stages of boot, well
>> before your revised storage drivers can be installed. The critical device
>> database may save you here, but that only works if your driver was
>> previously installed on the same hw id
>>
>> d
>>
>> Sent from my phone with no t9, all spilling mistakes are not intentional.
>>
>> ------------------------------
>> From: Mark Roddy
>> Sent: Monday, December 22, 2008 6:22 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Keeping bus driver version and enumerated device
>> driver version in sync
>>
>> While that would be ideal, in reality it is difficult particularly
>> where the underlying technology (in this case a virtualized system IO bus)
>> is changing frequently and/or extensively as it is more or less in a rapid
>> development prototyping stage. If there are functional incompatibilities
>> that cannot be managed by a support N and N-1 strategy, or at least not
>> managed easily, then forcing a new function driver by producing a different
>> enough PnP ID seems like a safe way to go to me.
>> Mark Roddy
>>
>>
>> On Mon, Dec 22, 2008 at 12:52 AM, David Craig wrote:
>>
>>> Doron is very correct in having the support for earlier versions of the
>>> buss
>>> driver in the function drivers. Also most Windows components use a
>>> registration structure to indicate the version of the driver making the
>>> call. This can be done in a bi-directional way so both can communicate
>>> their versions and maybe what version clients they can support.
>>>
>>> “James Harper” wrote in message
>>> news:xxxxx@ntdev…
>>> My Xen PV drivers consist of a bus driver that attaches to a virtual
>>> PCI
>>> device (the presence of which indicates that it is a Xen machine), and
>>> then enumerates network, block (scsiport), and some other devices. The
>>> enumerated devices may be present at boot time or can be hot-added after
>>> boot.
>>>
>>> I have encountered the situation before where the hot-added device
>>> remembers the version of the driver it was hot-added with previously,
>>> even though the driver has since been upgraded. At best this just
>>> doesn’t work. At worst, a system crash could result (obviously only
>>> because of a bug in my driver though).
>>>
>>> Also, when I upgrade the drivers on a running system, what happens is:
>>> . bus driver updates but the bus driver is connected to a block device
>>> which is holding the paging file and operating system, so the
>>> unload/reload is deferred
>>> . scsiport driver for the system disk also deferred as above
>>> . network driver upgrades, unloads, but then can’t reload because the
>>> bus driver version doesn’t match the upgraded network driver version.
>>> Suddenly I have no network anymore until the next reboot.
>>>
>>> While writing this it occurred to me that maybe I should put a version
>>> number into the enumerated device, eg currently it is ‘xen\vbd’
>>> (scsiport) or ‘xen\vif’ (network), but maybe it should be
>>> ‘xen\vbd_’ or something like that? Will things like boot
>>> devices get confused? Time for some testing I think :slight_smile:
>>>
>>> Is there a ‘best practices’ document or a blog somewhere that discusses
>>> this?
>>>
>>> Thanks
>>>
>>> James
>>>
>>>
>>>
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>> visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

14

>

Yes I understand, but I think James was having the opposite problem,
with
old drivers replacing good new ones and causing his system, which once
worked, to die a virtual death.

Once his xenbus has settled down and is not growing incompatible new
features, building in backward compatibility would be an excellent
idea.

The point being that changing the hardwareid is easy and solves his
immediate problem while fitting in backwards compatibility is not so
easy.

I’ve been giving this some more thought and I’m not sure that backwards
compatibility would really buy me anything - the full driver suite gets
released each time. The only thing it could give me is that the updated
network driver gets installed without rebooting.

My idea of changing the name of the pdo (eg xen/vif_version or something
like that) was indeed flawed as I would have to rehash my inf files each
time, but I think I could create a new instance id which only gets
enumerated once I reboot and the new bus driver takes effect.

I’m in the middle of some major changes at the moment but once I have
those settled I’ll do some testing with the new instance id’s.

Thanks for the ideas.

James

15

> My idea of changing the name of the pdo (eg xen/vif_version or
something

like that) was indeed flawed as I would have to rehash my inf files
each
time, but I think I could create a new instance id which only gets
enumerated once I reboot and the new bus driver takes effect.

I’m in the middle of some major changes at the moment but once I have
those settled I’ll do some testing with the new instance id’s.

Changing the instance id to include a protocol version number works fine
for block devices, but of course windows sees a new network adapter and
so the IP address and other info on the adapter is lost. Doh.

My fallback would be to not let the adapter be removed for the purposes
of updating the driver version, but I don’t think that that is possible
unless I make the adapter not removable at all, which means I would no
longer be able to remove it from xen. Does anyone know if there is a way
to always defer a driver update until reboot but still allow surprise
removal?

Thanks

James

16

Surprise removal (reporting missing in a QDR) and orderly removal (query remove->remove) are two distinct things. You can have w/out the other. You are not given the reason for an orderly removal (disable, driver uninstall, driver update, etc) though, so once you fail query remove you fail all reasons that a q.r. is sent w/out a way to distinguish between those reasons at the driver level. Failing q.r. at the driver level is a very difficult thing for the user to react to since they have no idea why (unless you log something to the event log and hope that they find it there) b/c you do not have the ability show UI to the user.

D

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, December 22, 2008 6:27 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Keeping bus driver version and enumerated device driver version in sync

My idea of changing the name of the pdo (eg xen/vif_version or
something
like that) was indeed flawed as I would have to rehash my inf files
each
time, but I think I could create a new instance id which only gets
enumerated once I reboot and the new bus driver takes effect.

I’m in the middle of some major changes at the moment but once I have
those settled I’ll do some testing with the new instance id’s.

Changing the instance id to include a protocol version number works fine
for block devices, but of course windows sees a new network adapter and
so the IP address and other info on the adapter is lost. Doh.

My fallback would be to not let the adapter be removed for the purposes
of updating the driver version, but I don’t think that that is possible
unless I make the adapter not removable at all, which means I would no
longer be able to remove it from xen. Does anyone know if there is a way
to always defer a driver update until reboot but still allow surprise
removal?

Thanks

James

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer