Regarding: Hardware knowledge

Hi Guys,

i have two questions ?

Q1) i am new to Device Driver development, during my study i found that the hardware knowledge of the device is essential, in that case should i also focus on learning some hardware stuff, if yes, what aspects of hardware should i focus such that it applies to majority of hardware.

also that Microsoft ships class drivers for many devices like USB,Keyboard etc , my initial thought was to learn USB drivers and USB hardware and become a USB Driver specialist, but as Microsoft is already shipping a class driver for it, i don’t see many job opportunities in this filed.

Q2) as you guys have been in device driver development for long, what types of hardware do you suggest me to focus keeping in view of current market needs

Regards
DG

Q1: What kinds of hardware do you plan to interface to? PCI (in its
various forms)? USB?

They are quite different and the “majority” of hardware is not a good
characterization. For all practical purposes, 100% of all devices are
either PCI or USB (1394 resembles USB, but these devices are not common).
For PCI, there really isn’t a whole lot to learn; you can get nearly
everything you need it about half an hour of study (not counting
understanding how the device itself works, which is unique to every
device; just understanding the PCI interface issues for all PCI devices).
Yes, there’s a ton of obscure corner cases, but you rarely find these in
practice.

For USB, download the USB standard from the USB site. Read it. Then look
at sample USB drivers. USB is actually more complex than PCI in terms of
how you interact with it, because you are not actually talking to the
hardware; you are talking to USBD, which talks to the USB minidriver,
which talks to the hardware. Understand how USB has different layers.
Learn about USB configurations. Get comfortable with reading an existing
USB driver, or two or three. It isn’t the hardware you need to worry
about, it’s the layer below you.

Q2: USB and/or PCI. Beyond that, you might specialize; network-level
drivers seem to be a hot topic, but I don’t know if they would guarantee a
revenue stream. File-system minifilters seem to be another hot topic,
although I see them being used for all sorts of inappropriate solutions to
non-problems. That’s just what I glean from reading these newsgroups.
I’m retired, and no longer care much.
joe

Hi Guys,

i have two questions ?

Q1) i am new to Device Driver development, during my study i found that
the hardware knowledge of the device is essential, in that case should i
also focus on learning some hardware stuff, if yes, what aspects of
hardware should i focus such that it applies to majority of hardware.

also that Microsoft ships class drivers for many devices like USB,Keyboard
etc , my initial thought was to learn USB drivers and USB hardware and
become a USB Driver specialist, but as Microsoft is already shipping a
class driver for it, i don’t see many job opportunities in this filed.

Q2) as you guys have been in device driver development for long, what
types of hardware do you suggest me to focus keeping in view of current
market needs

Regards
DG


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

In the driver world, people are most typically experts in a particular technology area… PLUS they are driver experts. So, for example, an engineer might know a lot about storage and thus specialize in storage drivers. Or know a lot about USB, and specialize in USB drivers.

As I’ve been telling people for years now, what makes the biggest difference in being employable or not (or being a busy contractor or not) is the added-value you bring to a project BEYOND just “I can eventually write a driver for that device.” That added value might be your subject matter expertise, it might be the speed at which you can crank-out bug free code, it might be your ability to write a clear and detailed design and maintenance guide, it might be the vast experience you have in doing many similar projects, it might be your abililty to understand the user-level folks needs and write a front-end DLL and C# class library that interfaces with the device and makes it *really* easy to use for user-mode folks, it might be your ability to clearly articular and share what you know.

So, understand that knowing how to call WdfDeviceCreate or IoCreateDeviceSecure doesn’t separate you from many other engineers. This is common knowledge (at least among kernel driver writers), and something that any learner can do. The experience and expertise that you have BEYOND simply knowing how to write a driver is what distinguishes you from other engineers.

Peter
OSR

Dr. Newcomer,

This is very different from my experience. Knowing how to access PCI bus,
setup DMA is simple not enough. I write/wrote video, network, and SAN HBA
drivers for food. One thing in comment is PCI and its friends. My employers
designed their own PCIe IP (logic, protocol stack and PHY/sedes) instead of
taking existing design from others. I also need to work
with prototype system from OEMs. Over the years, I have been seeing tons of
interesting PCI bugs at bus and electrical level. I’ve seen driver
developers very good at debugging problems at this level. But some will
never pick up no matter how many times (s)he bumped into it. For those
don’t, they just don’t know where to look, how to get started, or using
inappropriate approach akin to unscrewing a torx with Philips. I think
peoples’ brains are hard wired differently.

By asking some selected questions in PCI(e) in an interview, you quickly
discover his work style.

Calvin Guan
Sent from my PC on WIN8

On Wed, Jan 9, 2013 at 4:19 AM, wrote:

> For PCI, there really isn’t a whole lot to learn; you can get nearly
> everything you need it about half an hour of study (not counting
> understanding how the device itself works, which is unique to every
> device; just understanding the PCI interface issues for all PCI devices).
> Yes, there’s a ton of obscure corner cases, but you rarely find these in
> practice.
>

I’ve had to deal with hardware bugs as well. And seriously screwed-up
designs. Most often as a consultant, I’ve had to say “This design is
rubbish; send it back to the designers and tell them to read the PCI
spec”. Someone I know have been forced to use a PCI Bus Analyzer to prove
that he was not sending commands to the PCI chip that caused a
malfunction. When I isolated a bug in one vendor’s product, and said “It
is clear this is a hardware bug”, they wanted to know why. It turned into
an impromptu two-hour lecture on the PCI bus and its behavior. For
example, most people don’t know it is fundamentally an analog bus, and
critically depends on reflections from its unterminated ends to peak the
signal so it can be detected by the devices (back when I was learning
radio, reflections were the worst thing you could have in a transmission
line; PCI was developed /relying/ on them!) There is no way to limit the
amount of information you need to know to do successful hardware, but
every little bit (pun intended) helps. But that only comes with
experience, and trading stories with others.

At least part of my problem is that I was originally a hardware guy, who
fell into software, rather than a software guy who is trying to learn
hardware. As a software person, if you believe the hardware works, then
it is really easy–unless the design is really bizarre and takes lots of
operations to accomplish simple things; that’s probably a bad design.
Devices where there are hard real-time constraints on responding to events
are bad designs; you need to realistically assume that your host is a
general-purpose operating system that is not realtime-friendly. But
ultimately, at some point you have to assume the hardware is working
correctly. Flaky bus interactions (particularly when plugging a device
into the bus causes other devices to start malfunctioning) represent a
different level analysis, and the only thing a software developer needs to
learn is how to point to the device and say “it doesn’t work” and hand it
back to the hardware designers.

I heard of one case where the PCI BIOS of a particular machine
misprogrammed the PCI-to-PCI bridge chip. There was nothing wrong with
the device; the bug was deeper (I believe this was found by extensive
analysis of PCI bus traces from a bus analyzer).

As with any debugging, there are those who develop intuitions on how to do
analysis and those who never will. I’ve had to try to teach programmers
how to debug, and some “get it” and others never do.
joe

Dr. Newcomer,

This is very different from my experience. Knowing how to access PCI bus,
setup DMA is simple not enough. I write/wrote video, network, and SAN HBA
drivers for food. One thing in comment is PCI and its friends. My
employers
designed their own PCIe IP (logic, protocol stack and PHY/sedes) instead
of
taking existing design from others. I also need to work
with prototype system from OEMs. Over the years, I have been seeing tons
of
interesting PCI bugs at bus and electrical level. I’ve seen driver
developers very good at debugging problems at this level. But some will
never pick up no matter how many times (s)he bumped into it. For those
don’t, they just don’t know where to look, how to get started, or using
inappropriate approach akin to unscrewing a torx with Philips. I think
peoples’ brains are hard wired differently.

By asking some selected questions in PCI(e) in an interview, you quickly
discover his work style.

Calvin Guan
Sent from my PC on WIN8

On Wed, Jan 9, 2013 at 4:19 AM, wrote:
>
>> For PCI, there really isn’t a whole lot to learn; you can get nearly
>> everything you need it about half an hour of study (not counting
>> understanding how the device itself works, which is unique to every
>> device; just understanding the PCI interface issues for all PCI
>> devices).
>> Yes, there’s a ton of obscure corner cases, but you rarely find these in
>> practice.
>>
>
> —
> 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

And the really good ones can quickly write bug free code for the driver and
any interface DLL(s), write clear and concise documentation and do it all
for a device class they have never touched before - I don’t know too many of
them but I am always hoping to meet more

wrote in message news:xxxxx@ntdev…

In the driver world, people are most typically experts in a particular
technology area… PLUS they are driver experts. So, for example, an
engineer might know a lot about storage and thus specialize in storage
drivers. Or know a lot about USB, and specialize in USB drivers.

As I’ve been telling people for years now, what makes the biggest difference
in being employable or not (or being a busy contractor or not) is the
added-value you bring to a project BEYOND just “I can eventually write a
driver for that device.” That added value might be your subject matter
expertise, it might be the speed at which you can crank-out bug free code,
it might be your ability to write a clear and detailed design and
maintenance guide, it might be the vast experience you have in doing many
similar projects, it might be your abililty to understand the user-level
folks needs and write a front-end DLL and C# class library that interfaces
with the device and makes it *really* easy to use for user-mode folks, it
might be your ability to clearly articular and share what you know.

So, understand that knowing how to call WdfDeviceCreate or
IoCreateDeviceSecure doesn’t separate you from many other engineers. This
is common knowledge (at least among kernel driver writers), and something
that any learner can do. The experience and expertise that you have BEYOND
simply knowing how to write a driver is what distinguishes you from other
engineers.

Peter
OSR

> And the really good ones can quickly write bug free code for the driver and any interface DLL(s),

write clear and concise documentation and do it all for a device class they have never touched before

To be honest, seems to be more of a fantasy world, taking into consideration that different device classes
may have absolutely nothing to do with one another and may have totally different API. Furthermore, API details may have various quirks that are known only to those who have worked with it for quite a while. For example, how can you do all the above for, say, NIC driver if you have never worked with NDIS before???

Anton Bassov

How can one possibly write “bug free” code for any practical shipping
product? Bug free means zero bug, right?

On Wed, Jan 9, 2013 at 4:39 PM, wrote:

>
> > And the really good ones can quickly write bug free code for the driver
> and any interface DLL(s),
> >write clear and concise documentation and do it all for a device class
> they have never touched before
>
>
> To be honest, seems to be more of a fantasy world, taking into
> consideration that different device classes
> may have absolutely nothing to do with one another and may have totally
> different API. Furthermore, API details may have various quirks that are
> known only to those who have worked with it for quite a while. For
> example, how can you do all the above for, say, NIC driver if you have
> never worked with NDIS before???
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

Well, the comments made by Peter is a figure of speech, I think!!!

It is to indicate, that one should strive for it, given the current technology at hand !

-pro
Bug’s R us

On Jan 9, 2013, at 7:09 PM, Calvin Guan (news) wrote:

How can one possibly write “bug free” code for any practical shipping product? Bug free means zero bug, right?

On Wed, Jan 9, 2013 at 4:39 PM, wrote:
>
> > And the really good ones can quickly write bug free code for the driver and any interface DLL(s),
> >write clear and concise documentation and do it all for a device class they have never touched before
>
>
> To be honest, seems to be more of a fantasy world, taking into consideration that different device classes
> may have absolutely nothing to do with one another and may have totally different API. Furthermore, API details may have various quirks that are known only to those who have worked with it for quite a while. For example, how can you do all the above for, say, NIC driver if you have never worked with NDIS before???
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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 OSR is HIRING!! See http://www.osr.com/careers 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

One of the reasons I would never consider going into file systems was
hearing Tony Mason describe some file system driver issues at a Driver
DevCon. One of the things that was clear was the depth of his knowledge
about the file system architecture, a knowledge which I have had in other
areas, and which took me years to gain. I decided I didn’t have enough
years to gain the knowledge he had. Network drivers, video drivers,
printer drivers all have their own unique in-depth issues. None of which
have anything to do with “hardware knowledge”. For example, knowing how
to create overflow regions in pages of a file to attempt to maintain
locality-of-reference (a trick I knew from my days working with IBM’s
VISAM file system) is not something that is intuitively obvious. But it
has nothing to do with “hardware”.

I once did a system that could allow an 8088 to keep up with a
squishy-real-time requirement by using clever encodings, hints, and LRU
caches. None of which had anything to do with “hardware”, but had to do a
lot with getting clever algorithms that would run efficiently on dead-slow
hardware. The breadth of knowledge I brought to bear was considerable,
but I accomplished the “impossible”.

Perhaps Don Burn could say how much of his knowledge about file systems
deals with knowing exactly what commands to send to disk drives, and how
much deals with knowing how Windows storage stacks work. The OP was
asking about “hardware knowledge”, which is not nearly as important as
truly understanding the Windows architecture issues. [comments, Don?]

You may notice that most of the questions in these NGs have little to do
with hardware, and a lot to do with the protocols of interacting with the
Windows driver environment.
joe

> And the really good ones can quickly write bug free code for the driver
> and any interface DLL(s),
>write clear and concise documentation and do it all for a device class
> they have never touched before

To be honest, seems to be more of a fantasy world, taking into
consideration that different device classes
may have absolutely nothing to do with one another and may have totally
different API. Furthermore, API details may have various quirks that are
known only to those who have worked with it for quite a while. For
example, how can you do all the above for, say, NIC driver if you have
never worked with NDIS before???

Anton Bassov


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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

Thank you all for sharing your experiences and knowledge, very informative and bit scary too.

regards
DJ

Since Joe asked, I’ve been involved with 3 file systems, but only one
commercial file system filter. Even there the difference is
significant, and since all the file systems were for video my knowledge
is limited in many ways. I have done hardware driver development
including prototypes that ended in my having to read the VHDL (amazing
how everything is programming these days), But I have also done at
least 40 commercial drivers with no hardware. It really depends on
what your clients are looking for.

As far as the hardware guys writing bug free code, there probably is
someone but most of them write code that reflects that they think about
hardware. It is amazing how many times they have bug because that
annoying operating system won’t allow them to do things they know the
processor is capable of doing such as sub-millisecond timer.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

xxxxx@flounder.com” wrote in message
news:xxxxx@ntdev:

> One of the reasons I would never consider going into file systems was
> hearing Tony Mason describe some file system driver issues at a Driver
> DevCon. One of the things that was clear was the depth of his knowledge
> about the file system architecture, a knowledge which I have had in other
> areas, and which took me years to gain. I decided I didn’t have enough
> years to gain the knowledge he had. Network drivers, video drivers,
> printer drivers all have their own unique in-depth issues. None of which
> have anything to do with “hardware knowledge”. For example, knowing how
> to create overflow regions in pages of a file to attempt to maintain
> locality-of-reference (a trick I knew from my days working with IBM’s
> VISAM file system) is not something that is intuitively obvious. But it
> has nothing to do with “hardware”.
>
> I once did a system that could allow an 8088 to keep up with a
> squishy-real-time requirement by using clever encodings, hints, and LRU
> caches. None of which had anything to do with “hardware”, but had to do a
> lot with getting clever algorithms that would run efficiently on dead-slow
> hardware. The breadth of knowledge I brought to bear was considerable,
> but I accomplished the “impossible”.
>
> Perhaps Don Burn could say how much of his knowledge about file systems
> deals with knowing exactly what commands to send to disk drives, and how
> much deals with knowing how Windows storage stacks work. The OP was
> asking about “hardware knowledge”, which is not nearly as important as
> truly understanding the Windows architecture issues. [comments, Don?]
>
> You may notice that most of the questions in these NGs have little to do
> with hardware, and a lot to do with the protocols of interacting with the
> Windows driver environment.
> joe
>
>
> >
> >> And the really good ones can quickly write bug free code for the driver
> >> and any interface DLL(s),
> >>write clear and concise documentation and do it all for a device class
> >> they have never touched before
> >
> >
> > To be honest, seems to be more of a fantasy world, taking into
> > consideration that different device classes
> > may have absolutely nothing to do with one another and may have totally
> > different API. Furthermore, API details may have various quirks that are
> > known only to those who have worked with it for quite a while. For
> > example, how can you do all the above for, say, NIC driver if you have
> > never worked with NDIS before???
> >
> > Anton Bassov
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
> >

On Thu, Jan 10, 2013 at 10:02 AM, wrote:
> Thank you all for sharing your experiences and knowledge,
> very informative and bit scary too.

Firstly I am not a driver guy, not even a software guy. I am a hardware
engineer who has some side interests in USB (both host and
device side).

I think I agree with you that the the driver world (especially Windows
or Mac OS X driver world) is a scary world and it seems to be a very
narrow world. A more popular world may be embedded software
and the filed is quite wide. In fact, in my company, hardware engineers
are out-numbered by firmware engineers by a lot. The firmware engineers
need to know a bit of hardware but usually the hardware engineers will
come out of the HW/FW interface (the firmware engineers will need to
come out with FW/SW interface). They need to know more about
RTOS, file system, TCP/IP stack, USB stack etc. Maybe that is
a better field to go in than the system driver world.


Xiaofan

Well, you know… writing bug free code isn’t hard. The hard part is PROVING the code is bug free.

:wink:

Peter
OSR

> Well, you know… writing bug free code isn’t hard. The hard part is PROVING the code is bug free.

"Beware of bugs in the above code; I have only proved it correct, not tried it. " - Donald Knuth,
Notes on the van Emde Boas construction of priority deques: An instructive use of recursion (1977)

Anton Bassov

“Calvin Guan (news)” wrote in message
news:xxxxx@ntdev…
> How can one possibly write “bug free” code for any practical shipping
> product? Bug free means zero bug, right?

Customer pays for the code, and gets all the bugs free
– pa