Cultural differences in developing software

Discretion prevents me from going into detail, but I really do have to ask a
question.

If you were tasked with developing a legacy device driver that is to control
hardware for platforms running NT4, 2K, XP, or Server 2003, how many of you
would configure and initialize the adapter even though the BIOS has applied
a configuration during POST?

How many of you would depend upon the platform BIOS to have done the task
for you,
and not initialize and configure the adapter as a basic component of your
driver? The BIOS may be any BIOS available,

My feeling is this — My job, my driver, I control the hardware so I am
going to stop, init, config and restart the adapter.


Gary G. Little
Seagate Technologies, LLC

Gary,

I guess I would say that depends. I have dealt with firms whose
hardware and BIOS are so bad, that I would leave the StartDevice routine
without perform all initializations and diagnostics I possibly could. At
the other end of the extreme I done driver for an almost embedded
environment, where the hardware is stable and would not waste my clients
time on doing any of this.

Overall this is a judgement call based on a lot of things (including
have you been burned before), but I do agree that for the most part I want
to initialize things the way my driver expects them, since I don’t trust
that the on card BIOS with the motherboard BIOS is going to do the right
thing.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Friday, January 09, 2004 10:52 AM
Subject: [ntdev] Cultural differences in developing software

> Discretion prevents me from going into detail, but I really do have to ask
a
> question.
>
> If you were tasked with developing a legacy device driver that is to
control
> hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
you
> would configure and initialize the adapter even though the BIOS has
applied
> a configuration during POST?
>
> How many of you would depend upon the platform BIOS to have done the task
> for you,
> and not initialize and configure the adapter as a basic component of your
> driver? The BIOS may be any BIOS available,
>
> My feeling is this — My job, my driver, I control the hardware so I am
> going to stop, init, config and restart the adapter.
>
> –
> Gary G. Little
> Seagate Technologies, LLC
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Don,

Yeah, I can agree that when I’m in an embedded, very restricted, and or
controlled platform, initializing the hardware for my “driver” may not be
needed. But then I know that the upfront code most likely will not change
simply because a bean-counter found a good deal for Mom’s Motherboards in
Podunk, Alaska. But with NT, 2K, XP etc. etc. etc. I will for sure make sure
I have applied a good initialization and configuration to my adapter. There
I agree with Alberto … “I don’ need no shtinking BIOS”. :slight_smile:


Gary G. Little
Seagate Technologies, LLC

“Don Burn” wrote in message news:xxxxx@ntdev…
> Gary,
>
> I guess I would say that depends. I have dealt with firms whose
> hardware and BIOS are so bad, that I would leave the StartDevice routine
> without perform all initializations and diagnostics I possibly could. At
> the other end of the extreme I done driver for an almost embedded
> environment, where the hardware is stable and would not waste my clients
> time on doing any of this.
>
> Overall this is a judgement call based on a lot of things (including
> have you been burned before), but I do agree that for the most part I want
> to initialize things the way my driver expects them, since I don’t trust
> that the on card BIOS with the motherboard BIOS is going to do the right
> thing.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> ----- Original Message -----
> From: “Gary G. Little”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Friday, January 09, 2004 10:52 AM
> Subject: [ntdev] Cultural differences in developing software
>
>
> > Discretion prevents me from going into detail, but I really do have to
ask
> a
> > question.
> >
> > If you were tasked with developing a legacy device driver that is to
> control
> > hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
> you
> > would configure and initialize the adapter even though the BIOS has
> applied
> > a configuration during POST?
> >
> > How many of you would depend upon the platform BIOS to have done the
task
> > for you,
> > and not initialize and configure the adapter as a basic component of
your
> > driver? The BIOS may be any BIOS available,
> >
> > My feeling is this — My job, my driver, I control the hardware so I am
> > going to stop, init, config and restart the adapter.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

The problem is, there are bioses and there are bioses. You can never know
what a bios really does to your device. If it is a bog standard kind of
device, well, we can probably assume that the bios is going to handle it ok;
but if it is not, who knows ? A good bios will handle it properly, but a not
so good bios might not. I would be tempted to initialize the device myself
anyway, just to be safe, unless of course I had to barge into the HAL and
rewrite a part of it to make ends meet ! Yet, depending on the device, you
might be able to read the state and see if all’s there, if not, well, reinit
it.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary G. Little
Sent: Friday, January 09, 2004 11:39 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Cultural differences in developing software

Don,

Yeah, I can agree that when I’m in an embedded, very restricted, and or
controlled platform, initializing the hardware for my “driver” may not be
needed. But then I know that the upfront code most likely will not change
simply because a bean-counter found a good deal for Mom’s Motherboards in
Podunk, Alaska. But with NT, 2K, XP etc. etc. etc. I will for sure make sure
I have applied a good initialization and configuration to my adapter. There
I agree with Alberto … “I don’ need no shtinking BIOS”. :slight_smile:


Gary G. Little
Seagate Technologies, LLC

“Don Burn” wrote in message news:xxxxx@ntdev…
> Gary,
>
> I guess I would say that depends. I have dealt with firms whose
> hardware and BIOS are so bad, that I would leave the StartDevice routine
> without perform all initializations and diagnostics I possibly could. At
> the other end of the extreme I done driver for an almost embedded
> environment, where the hardware is stable and would not waste my clients
> time on doing any of this.
>
> Overall this is a judgement call based on a lot of things (including
> have you been burned before), but I do agree that for the most part I want
> to initialize things the way my driver expects them, since I don’t trust
> that the on card BIOS with the motherboard BIOS is going to do the right
> thing.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
> ----- Original Message -----
> From: “Gary G. Little”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Friday, January 09, 2004 10:52 AM
> Subject: [ntdev] Cultural differences in developing software
>
>
> > Discretion prevents me from going into detail, but I really do have to
ask
> a
> > question.
> >
> > If you were tasked with developing a legacy device driver that is to
> control
> > hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
> you
> > would configure and initialize the adapter even though the BIOS has
> applied
> > a configuration during POST?
> >
> > How many of you would depend upon the platform BIOS to have done the
task
> > for you,
> > and not initialize and configure the adapter as a basic component of
your
> > driver? The BIOS may be any BIOS available,
> >
> > My feeling is this — My job, my driver, I control the hardware so I am
> > going to stop, init, config and restart the adapter.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@acm.org
> > 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=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

What is the cost to you redoing the initialization?

Is the BIOS on-card BIOS that is controlled by the company or BIOS in the
host machine?

Is it easy to tell if the BIOS has initialized the card or not?

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> Discretion prevents me from going into detail, but I really do have to ask
a
> question.
>
> If you were tasked with developing a legacy device driver that is to
control
> hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
you
> would configure and initialize the adapter even though the BIOS has
applied
> a configuration during POST?
>
> How many of you would depend upon the platform BIOS to have done the task
> for you,
> and not initialize and configure the adapter as a basic component of your
> driver? The BIOS may be any BIOS available,
>
> My feeling is this — My job, my driver, I control the hardware so I am
> going to stop, init, config and restart the adapter.
>

Hi Gary,

I just thought I’d give the solution for graphics cards (at least our
ones)…

We have a particularly difficult device to set up, with all the variations
of memory speeds & setup, chip speeds and some sensitive setup for delays
depending on board design.

This either means that the driver needs to know (and be updated) with every
board revision & model. This is quite a hard task to keep synched. So we
have a different solution:

In the BIOS (VGA BIOS) that is used to give the Boot screen etc, we have
some code to set things up. However, this is not necessarily run on all
systems, for instance when more than one graphics adapter is in the system,
or the system isn’t capable of running 8086 code (Itanic/Alpha).

So, the solution is to have a table in the BIOS, which contains the relevant
setup information for the board specific setup (memory timing, clock speeds,
delays for the video, etc). The driver will then determine if the board has
been setup or not, and if not, read the stuff fromt the BIOS and perform the
right setup. If it’s already been setup, it’s probably a good setup, so we
don’t touch it.

This solution is of course based on the fact that there is a “Adapter BIOS”
fitted to the graphics card, which may or may not be true for other types of
hardware (Networking, SCSI controllers etc can have “option ROM”).


Mats

-----Original Message-----
From: Gary G. Little [mailto:xxxxx@sbcglobal.net]
Sent: Friday, January 09, 2004 3:52 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Cultural differences in developing software

Discretion prevents me from going into detail, but I really
do have to ask a
question.

If you were tasked with developing a legacy device driver
that is to control
hardware for platforms running NT4, 2K, XP, or Server 2003,
how many of you
would configure and initialize the adapter even though the
BIOS has applied
a configuration during POST?

How many of you would depend upon the platform BIOS to have
done the task
for you,
and not initialize and configure the adapter as a basic
component of your
driver? The BIOS may be any BIOS available,

My feeling is this — My job, my driver, I control the
hardware so I am
going to stop, init, config and restart the adapter.


Gary G. Little
Seagate Technologies, LLC


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

Mats,

You point out a possible definition problem … is it BIOS or is it option
ROM? What does that BIOS message that pops up on many Scsi/ATA adapters
really mean?

The particular situation I originally referred to was HBAs controlling hard
disks. Every ScsiMiniport driver I am aware of will init/config that adapter
upon entry into the ScsiMiniports FindAdapter/Initialize routines. The ATA
stack, which is no longer a ScsiMiniport, may no longer do that init/config
but I do assume that it does.

Doug,

BIOS to me is that which runs when I press the on/off button on a Dell
Optiplex.

To me the cost is minimal since the driver is going to initialize during
Boot/Scsi Miniport time. It can take as long as required, and I would rather
do that than depend upon a BIOS written by Fly-by-Night Software applying an
incorrect configuration, or doing a “generic” configuration that could well
slow down my nifty lightspeed spin-dizzy holy-graphic storage device.


Gary G. Little
Seagate Technologies, LLC

wrote in message news:xxxxx@ntdev…
> Hi Gary,
>
> I just thought I’d give the solution for graphics cards (at least our
> ones)…
>
> We have a particularly difficult device to set up, with all the variations
> of memory speeds & setup, chip speeds and some sensitive setup for delays
> depending on board design.
>
> This either means that the driver needs to know (and be updated) with
every
> board revision & model. This is quite a hard task to keep synched. So we
> have a different solution:
>
> In the BIOS (VGA BIOS) that is used to give the Boot screen etc, we have
> some code to set things up. However, this is not necessarily run on all
> systems, for instance when more than one graphics adapter is in the
system,
> or the system isn’t capable of running 8086 code (Itanic/Alpha).
>
> So, the solution is to have a table in the BIOS, which contains the
relevant
> setup information for the board specific setup (memory timing, clock
speeds,
> delays for the video, etc). The driver will then determine if the board
has
> been setup or not, and if not, read the stuff fromt the BIOS and perform
the
> right setup. If it’s already been setup, it’s probably a good setup, so we
> don’t touch it.
>
> This solution is of course based on the fact that there is a “Adapter
BIOS”
> fitted to the graphics card, which may or may not be true for other types
of
> hardware (Networking, SCSI controllers etc can have “option ROM”).
>
> –
> Mats
>
> > -----Original Message-----
> > From: Gary G. Little [mailto:xxxxx@sbcglobal.net]
> > Sent: Friday, January 09, 2004 3:52 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Cultural differences in developing software
> >
> >
> > Discretion prevents me from going into detail, but I really
> > do have to ask a
> > question.
> >
> > If you were tasked with developing a legacy device driver
> > that is to control
> > hardware for platforms running NT4, 2K, XP, or Server 2003,
> > how many of you
> > would configure and initialize the adapter even though the
> > BIOS has applied
> > a configuration during POST?
> >
> > How many of you would depend upon the platform BIOS to have
> > done the task
> > for you,
> > and not initialize and configure the adapter as a basic
> > component of your
> > driver? The BIOS may be any BIOS available,
> >
> > My feeling is this — My job, my driver, I control the
> > hardware so I am
> > going to stop, init, config and restart the adapter.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
> >
> >
> >
> > —
> > 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
>

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
>
> If you were tasked with developing a legacy device driver that is to
control
> hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
you
> would configure and initialize the adapter even though the BIOS has
applied
> a configuration during POST?
>

Assuming you’re talking about doing an initialization of the device, I’d say
it’s rather common for the driver to re-run device specific POST.

I assume you’re NOT talking about trying to manually determine assign the
device’s BARs – As somebody once said, “there are BIOSes and there are
BIOSes”…

But anything that has to do with resetting, configuring and defining the
device’s functionality (given its resources) is typically your
responsibility, not that of the BIOS.

There are, of course, ugly corner cases. I’m thinking of striping
configuraitons that, of necessity, need to be shared between the BIOS and a
storage adapter, for example. In such cases, you might not have any
alternative but to trust the BIOS. But, in that case, it’d be “your”
special BIOS I guess.

I’m rambling,

Peter
OSR

> If you were tasked with developing a legacy device driver that is to
control

hardware for platforms running NT4, 2K, XP, or Server 2003, how many of
you

Having done several of these…

My feeling is this — My job, my driver, I control the hardware so I am
going to stop, init, config and restart the adapter.

In general, yes, I do this. Especially since several of the beasts I’ve
done aren’t BIOS recognizable.

In a couple of cases though I can have the driver go away and come back
(loadable legacy driver) and it is important to not crash the card just
because this happens – the card has an onboard processor controlling
physical hardware. So in those cases I start by fairly carefully probing
the card to decide if it is alive and sane, and if so skip the init.

Loren

Gary,

Mats,

You point out a possible definition problem … is it BIOS or
is it option
ROM? What does that BIOS message that pops up on many
Scsi/ATA adapters
really mean?

VGA compatible graphics card (and I beleive almost all other graphics cards)
have a BIOS on the card itself. In other boards you may have some form of
option ROM. I beleive the difference between those two is the fact that the
VGA BIOS is defined as a standard (as to where it’s located, and what it’s
supposed to do: set up INT 10h, and it must support some calls to INT 10h),
while the option ROM is a “BIOS extension” that is not defined as a
standard. That’s how I understand it.

The standard PC BIOS will scan a certain address range for some magic
numbers (55/AA I think) and then calculate a checksum, which is the third
byte. A jump is then performed to the 5th byte of the address. This is what
prints the “BIOS message” for the device.

So the definition is:
An option ROM is a piece of code/data that is fitted to a board that goes in
the computer, and if the option ROM is on a graphics card, it becomes a VGA
BIOS.

Sometimes, on integrated motherboards with for instance built in RAID
controllers, this “option ROM” is actually inside the same device as the
motherboard BIOS, just lumped in above the BIOS itself.

The particular situation I originally referred to was HBAs
controlling hard
disks. Every ScsiMiniport driver I am aware of will
init/config that adapter
upon entry into the ScsiMiniports FindAdapter/Initialize
routines. The ATA
stack, which is no longer a ScsiMiniport, may no longer do
that init/config
but I do assume that it does.

In many cases with Scsi or ATA devices, I would think this has to do with
the fact that the BIOS does not (generally) support DMA from the davice.
That’s at least true for ATA devices. Even the (NT4) standard ATA controller
driver would just wait for the “data ready” interrupt and then read out word
for word the data from the requested sector.

Another factor is that often the initial setup of a device requires the
setup of memory buffers. To avoid problems, the initial setup may very well
use small buffers at below 640K to make sure that it works in DOS-mode too.
When writing BIOS code, you never know what horrible things the (ab)user
will try to run on the machine.

Doug,

BIOS to me is that which runs when I press the on/off button on a Dell
Optiplex.

That’s the motherboard BIOS, quickly followed by the VGA BIOS, which usually
prints the name/manufacturer/model of the graphics chip and board, sometimes
with a bit of fancy text-graphics, but often just plain white text on black
background. The VGA BIOS is called almost immediately after the initial “is
there memory in this thing” bit in the motherboard BIOS, because the VGA
screen is useful to output things like “I can’t find a hard disk” or “You
need to release the key on the keyboard that is stuck”. It’s also usefull to
show nice logos of the motherboard/system name (Dell logo fo’instance) while
the user is waiting for the windows logo to appear.

To me the cost is minimal since the driver is going to
initialize during
Boot/Scsi Miniport time. It can take as long as required, and
I would rather
do that than depend upon a BIOS written by Fly-by-Night
Software applying an
incorrect configuration, or doing a “generic” configuration
that could well
slow down my nifty lightspeed spin-dizzy holy-graphic storage device.>

Gary G. Little
Seagate Technologies, LLC

I guess I do not understand the problem. If your initialization takes very
little time, why does anyone notice or care? Why is this a problem? Does
your initialization differ from the BIOS initialization?

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> To me the cost is minimal since the driver is going to initialize during
> Boot/Scsi Miniport time. It can take as long as required, and I would
rather
> do that than depend upon a BIOS written by Fly-by-Night Software applying
an
> incorrect configuration, or doing a “generic” configuration that could
well
> slow down my nifty lightspeed spin-dizzy holy-graphic storage device.
>
> –
> Gary G. Little
> Seagate Technologies, LLC

You missed the point Doug. The question is if a driver developer should
depend upon an external functionality (system BIOS) to configure the
hardware for a device driver for Windows. While there may be some situations
where a driver loaded in Windows might NOT init and configure it’s hardware,
thus far the majority sides with the driver applying it’s own initialization
and configuration when Windows has loaded it. To me, initialization and
configuration is so basic a function that it is only included in a
specification if a special configuration should be used or if it should NOT
be applied.


Gary G. Little
Seagate Technologies, LLC

“Doug” wrote in message news:xxxxx@ntdev…
> I guess I do not understand the problem. If your initialization takes very
> little time, why does anyone notice or care? Why is this a problem? Does
> your initialization differ from the BIOS initialization?
>
> “Gary G. Little” wrote in message
> news:xxxxx@ntdev…
> > To me the cost is minimal since the driver is going to initialize during
> > Boot/Scsi Miniport time. It can take as long as required, and I would
> rather
> > do that than depend upon a BIOS written by Fly-by-Night Software
applying
> an
> > incorrect configuration, or doing a “generic” configuration that could
> well
> > slow down my nifty lightspeed spin-dizzy holy-graphic storage device.
> >
> > –
> > Gary G. Little
> > Seagate Technologies, LLC
>
>
>