19Oct06 Chat followup, Oren_MS: Feature Request: See all CF's as FIXED

[jimt]

Sorry for this redundant post. A MS person suggested I begin this thread
with Oren's name in the subject so we could follow up on a question I asked
in this morning's XPe chat. This question is a followon to my "Faking out
the CF fixed/removable query bit" thread in this NG, where the following was
learned:

- My request is to have the OS see _any_ CF as FIXED media in order to put
multiple partitions on it. If we use CF from a different vendor, the
OS must
still see it as FIXED without our having to change the XPe runtime
image.

- The XPeFiles.com lower level filter driver "Hitachi Microdrive driver"
can do
this, but the INF must be edited when newer vendor CF's are used with
the
runtime image.

- Oren suggested during the chat that we use an upper filter on the class
driver.

I had heard that a class driver change would ripple down to all drives, not
just the CF drives. The next question is: Is there a way to limit the
upper filter on the class driver to just the CFs that are, say, installed on
a particular port, or only drives that are CF?

Thanks,

 

[Oren Winter [MS]]

Hey Jim,
I apologize for not being able to answer your question this morning (due to
some technical difficulties).
You are right that this will be rippled to all drives. When I've tried it
several years ago I didn't care since I had only one removable device which
I wanted to "fix". So this is indeed the easy solution. If you'd like to
distinguish and not filter out the removable flag for every device then you
will need to write some code in the driver to do that, basically by querying
the stack that you're attached to and figure out the STORAGE_DEVICE_NUMBER
of the device you want (you can use the IOCTL for that; more details in the
DDK).
I hope this helps; sorry I couldn't find as easier solution for you.

Oren

 

[Stuart Langley]

I know this is a little bit off topic, but I am not entirely certain why you
would want to implement this feature, from a quality control point of view.

There are plenty of variables between different manufacturers of CF cards
besides the setting of the fixed/removable bit. If you allow end users (or
manufacturing for that matter) to use any old flash cards they want in your
product then you are opening a big can of worms regarding the correct
operation of your product.

If you are concerned about sourcing CF cards with the fixed bit set in the
first place, the list of quality manufactures that will do this with a
qualified part number is as long as your arm. Simpletech, Transcend and
Pretec all leap to mind.

Regards,

Stuart

Hey Jim,
I apologize for not being able to answer your question this morning (due
to some technical difficulties).
You are right that this will be rippled to all drives. When I've tried it
several years ago I didn't care since I had only one removable device
which I wanted to "fix". So this is indeed the easy solution. If you'd
like to distinguish and not filter out the removable flag for every device
then you will need to write some code in the driver to do that, basically
by querying the stack that you're attached to and figure out the
STORAGE_DEVICE_NUMBER of the device you want (you can use the IOCTL for
that; more details in the DDK).
I hope this helps; sorry I couldn't find as easier solution for you.

Oren

 

[jimt]

Good points, all. But the flexibility on vendors is for our convenience,
not for our end users. The CF sits deep inside our target. You need to
shut down the target and disassemble it to reach the CF in question. There
is no worry that our end user will be inserting their own choice of CF.

We would like a solution that can take a new CF that we might identifiy and
approve without our having to cut a new XPe image or patch the target. BTW
the vendors you list can be a little pricey (although the quality is quite
good). Our hw team would like the flexibility of shopping for lower priced
CF.

But thanks anyway for the comment, it is a good point to keep in mind.

--
jimt

I know this is a little bit off topic, but I am not entirely certain why
you would want to implement this feature, from a quality control point of
view.

There are plenty of variables between different manufacturers of CF cards
besides the setting of the fixed/removable bit. If you allow end users (or
manufacturing for that matter) to use any old flash cards they want in
your product then you are opening a big can of worms regarding the correct
operation of your product.

If you are concerned about sourcing CF cards with the fixed bit set in the
first place, the list of quality manufactures that will do this with a
qualified part number is as long as your arm. Simpletech, Transcend and
Pretec all leap to mind.

Regards,

Stuart

 

[jimt]

Hi Oren,

Thanks for your response. I'm told this would be easy to do. Not as easy
as flipping a registry entry, but still doable. I guess our conclusions to
providing vendor independent flash that can be partitioned is:

(1) Use USB and FP2007. The USB flash drive would be partitionable under
FP2007
(2) Choice 2 is to write the high level class filter driver mentioned
below and use CF.
(3) Choice 3 is the XPeFiles.com "Hitachi" driver, which would be vendor
specific, for CF

Unless MS or someone else comes up with a more general solution, I think
these are my top 3 choices.

Thanks to you and your colleagues for your suggestions.

 

[Oren Winter [MS]]

Correct, these are the options. We (at the embedded team) are looking into
providing the solution described in #2 in some form but plans are still not
materialized. I haven't looked into option #3 but maybe the filter driver is
generic enough so just playing with the registry entried / installation inf
file can make it a filter for the class and not just this specific vendor?
Thanks,
Oren

 

[jimt]

Yes, we would start with the xpefiles Hitatchi driver as a starting point
for option #2. However, our first effort will involve convincing my hw team
to use USB flash. Some of these are available for install on a PCBoard
directly, which would take care of the shock issues. Failing that, it's off
to our driver writer I go.

Thanks for the suggestions. I hope you get #2 implemented at some point,
perhaps controlled via a registry entry or some other method.

Bye,