Hello everybody. I need to build a configuration parameter policy for my
driver in order to merge different versions
of my implementation in one. In other words I need to build a configuration
*.ini like file that it will be used by the
driver at DriverEntry in order to notify h/w memory addresses. What is the
best way to do that?
Thank you in advance.
When you say h/w memory addresses, I suppose you mean things that are
WITHIN your hardware architecture, rather than what teh PnP system in
Windows can detect or know about?
One way to store values, in general, is by storing the values in the
registry. This is a “general dumping ground” for various information that
is used by the driver (or other software).
You can write registry entries from your driver, or use the .inf
installation file to set up the correct values.
In general, however, it’s good to not rely on anything but the driver
itself. So for instance, if you have two pieces of different hardware that
you can distinguish in software, you should try to distinguish them by
software in the driver, rather than by distinguishing them in the setup
program.
So for example, lets say that HW A has a ExtraFeature, which isn’t
available on HW B (cheaper model). Then let the driver detect which version
the hardware is, and enable the use of ExtraFeature when it’s HW A. There
are many different ways to achieve this, and which is better depends A LOT
on what you’re trying to do.
–
Mats
xxxxx@lists.osr.com wrote on 11/08/2004 02:43:03 PM:
Hello everybody. I need to build a configuration parameter policy
for my driver in order to merge different versions
of my implementation in one. In other words I need to build a
configuration *.ini like file that it will be used by the
driver at DriverEntry in order to notify h/w memory addresses. What
is the best way to do that?Thank you in advance.
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00006EB6
Thank you very much.
The board has a rapid prototype chip (Xilinx) and one add on card for
physical connection. So, it’s up to software to download the correct Xilinx
version.
Ok. If so, I’d add a registry entry that contains the filename to be
downloaded, combined with a CRC or some such to make sure that the file
you’re trying to load is actually a correct one.
You can then write a tool for updating the Xilinx code by updating the CRC
and the new file.
Obviously, you’d need to check the CRC before you download (or during
download if there is an option to reset the downloaded data if the CRC
doesn’t match). But presumably it’s not a huge amount of data, so I suspect
you can allocate a suitable buffer, load it up, CRC it, and then transfer
to the Xilinx part.
Another, completely different approach is of course to have the filename
sent in by a IOCTL call to the device that you’re representing, and letting
the user-mode software decide what it needs to download. This is probably a
better option in the case where the customer is often changing the
hardware, and less good an option if the user is often loading and
unloading the user-mode software.
Of course, in either case, make sure you’re checking the data coming in
thoroughly, so that noone can use your code to hack the system (for
example. make sure you only read as much file as your buffer can hold).
–
Mats
xxxxx@lists.osr.com wrote on 11/08/2004 03:39:17 PM:
Thank you very much.
The board has a rapid prototype chip (Xilinx) and one add on card for
physical connection. So, it’s up to software to download the correct
Xilinx
version.
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00006ECE
What is your hardware? If it is not a non-PnP ISA card, then avoid dealing with hardware resources there. It is a job of PnP. Your driver must silently accept what PnP will assign to it.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Nikolas Stylianides
To: Windows System Software Devs Interest List
Sent: Monday, November 08, 2004 5:43 PM
Subject: [ntdev] Configuration Parameters
Hello everybody. I need to build a configuration parameter policy for my driver in order to merge different versions
of my implementation in one. In other words I need to build a configuration *.ini like file that it will be used by the
driver at DriverEntry in order to notify h/w memory addresses. What is the best way to do that?
Thank you in advance.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
You obviously got the picture. The user can select a variaty of bin files
To download, thus changing completely CTRL registers that the driver uses in
order to configure the Xilinx implementation.
So, I think that I can have a registry entry for the location of the bin
file and another entry of a txt mode or bin mode initialization file. Does
this make sence to you?
Thank you very much.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Monday, November 08, 2004 5:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Configuration Parameters
Ok. If so, I’d add a registry entry that contains the filename to be
downloaded, combined with a CRC or some such to make sure that the file
you’re trying to load is actually a correct one.
You can then write a tool for updating the Xilinx code by updating the CRC
and the new file.
Obviously, you’d need to check the CRC before you download (or during
download if there is an option to reset the downloaded data if the CRC
doesn’t match). But presumably it’s not a huge amount of data, so I suspect
you can allocate a suitable buffer, load it up, CRC it, and then transfer
to the Xilinx part.
Another, completely different approach is of course to have the filename
sent in by a IOCTL call to the device that you’re representing, and letting
the user-mode software decide what it needs to download. This is probably a
better option in the case where the customer is often changing the
hardware, and less good an option if the user is often loading and
unloading the user-mode software.
Of course, in either case, make sure you’re checking the data coming in
thoroughly, so that noone can use your code to hack the system (for
example. make sure you only read as much file as your buffer can hold).
–
Mats
xxxxx@lists.osr.com wrote on 11/08/2004 03:39:17 PM:
Thank you very much.
The board has a rapid prototype chip (Xilinx) and one add on card for
physical connection. So, it’s up to software to download the correct
Xilinx
version.
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00006ECE
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@4plus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It’s easy to get the picture when you’re given enough details to know
roughtly what someone is doing.
Yes, that makes sense to me.
In the case of the “initialization file”, I would go for something that is
easy to parse in the driver, so thus avoiding anything that is text-based.
I know it’s easier to modifiy a text file, but the advantage of not having
to parse text files in driver wins, since if nothing else, it’s a security
issue.
Another thought: if the configuration information is relatively small, such
as this structure:
struct IOAdress {
ULONG base;
ULONG size;
ULONG type;
};
If you have a few of these (say less than 20), you could easily put these
in a “binary” registry entry, rather than putting them in a file. And just
read it straight out of the registry entry. If you make the first entry a
size, so that you know how many entries you’ve got, then you’re able to
write a tiny little read-routine, that stuffs the data from the registry
into an array for the driver to set things up.
And writing a small application to generate a registry file isn’t
particularly hard work. Then apply the registry file to the registry, and
voila, you have a new setup.
Even fancier would be to have an IOCTL that re-reads the registry when
you’ve changed the setup, and perhaps also reload the binary, if that’s an
option.
Best of luck.
–
Mats
xxxxx@lists.osr.com wrote on 11/09/2004 10:45:46 AM:
You obviously got the picture. The user can select a variaty of bin files
To download, thus changing completely CTRL registers that the driver uses
in
order to configure the Xilinx implementation.So, I think that I can have a registry entry for the location of the bin
file and another entry of a txt mode or bin mode initialization file.
Does
this make sence to you?Thank you very much.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Monday, November 08, 2004 5:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Configuration ParametersOk. If so, I’d add a registry entry that contains the filename to be
downloaded, combined with a CRC or some such to make sure that the file
you’re trying to load is actually a correct one.You can then write a tool for updating the Xilinx code by updating the
CRC
and the new file.Obviously, you’d need to check the CRC before you download (or during
download if there is an option to reset the downloaded data if the CRC
doesn’t match). But presumably it’s not a huge amount of data, so I
suspect
you can allocate a suitable buffer, load it up, CRC it, and then transfer
to the Xilinx part.Another, completely different approach is of course to have the filename
sent in by a IOCTL call to the device that you’re representing, and
letting
the user-mode software decide what it needs to download. This is probably
a
better option in the case where the customer is often changing the
hardware, and less good an option if the user is often loading and
unloading the user-mode software.Of course, in either case, make sure you’re checking the data coming in
thoroughly, so that noone can use your code to hack the system (for
example. make sure you only read as much file as your buffer can hold).–
Matsxxxxx@lists.osr.com wrote on 11/08/2004 03:39:17 PM:
> Thank you very much.
>
> The board has a rapid prototype chip (Xilinx) and one add on card for
> physical connection. So, it’s up to software to download the correct
Xilinx
> version.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com> ForwardSourceID:NT00006ECE
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@4plus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00006FC2
Great, I really like multiple choices. I will propably try both registry
entries and binary file.
Again, thank you very much.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Tuesday, November 09, 2004 1:07 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Configuration Parameters
It’s easy to get the picture when you’re given enough details to know
roughtly what someone is doing.
Yes, that makes sense to me.
In the case of the “initialization file”, I would go for something that is
easy to parse in the driver, so thus avoiding anything that is text-based.
I know it’s easier to modifiy a text file, but the advantage of not having
to parse text files in driver wins, since if nothing else, it’s a security
issue.
Another thought: if the configuration information is relatively small, such
as this structure:
struct IOAdress {
ULONG base;
ULONG size;
ULONG type;
};
If you have a few of these (say less than 20), you could easily put these
in a “binary” registry entry, rather than putting them in a file. And just
read it straight out of the registry entry. If you make the first entry a
size, so that you know how many entries you’ve got, then you’re able to
write a tiny little read-routine, that stuffs the data from the registry
into an array for the driver to set things up.
And writing a small application to generate a registry file isn’t
particularly hard work. Then apply the registry file to the registry, and
voila, you have a new setup.
Even fancier would be to have an IOCTL that re-reads the registry when
you’ve changed the setup, and perhaps also reload the binary, if that’s an
option.
Best of luck.
–
Mats
xxxxx@lists.osr.com wrote on 11/09/2004 10:45:46 AM:
You obviously got the picture. The user can select a variaty of bin files
To download, thus changing completely CTRL registers that the driver uses
in
order to configure the Xilinx implementation.So, I think that I can have a registry entry for the location of the bin
file and another entry of a txt mode or bin mode initialization file.
Does
this make sence to you?Thank you very much.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Monday, November 08, 2004 5:46 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Configuration ParametersOk. If so, I’d add a registry entry that contains the filename to be
downloaded, combined with a CRC or some such to make sure that the file
you’re trying to load is actually a correct one.You can then write a tool for updating the Xilinx code by updating the
CRC
and the new file.Obviously, you’d need to check the CRC before you download (or during
download if there is an option to reset the downloaded data if the CRC
doesn’t match). But presumably it’s not a huge amount of data, so I
suspect
you can allocate a suitable buffer, load it up, CRC it, and then transfer
to the Xilinx part.Another, completely different approach is of course to have the filename
sent in by a IOCTL call to the device that you’re representing, and
letting
the user-mode software decide what it needs to download. This is probably
a
better option in the case where the customer is often changing the
hardware, and less good an option if the user is often loading and
unloading the user-mode software.Of course, in either case, make sure you’re checking the data coming in
thoroughly, so that noone can use your code to hack the system (for
example. make sure you only read as much file as your buffer can hold).–
Matsxxxxx@lists.osr.com wrote on 11/08/2004 03:39:17 PM:
> Thank you very much.
>
> The board has a rapid prototype chip (Xilinx) and one add on card for
> physical connection. So, it’s up to software to download the correct
Xilinx
> version.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com> ForwardSourceID:NT00006ECE
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@4plus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
ForwardSourceID:NT00006FC2
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@4plus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com