Gregory,
just a question: How do you make sure everything is stable? Working on
real-time and process stuff normally makes it easier for you. There’s
probably only specialized hardware in the system and not much of software
you would see on a mainstream system. You have full control of the system.
On a enduser OS you don’t have those benefits. You must take into account
that half of the system doesn’t work well together anyway. While most
software doesn’t crash the system right away a driver will as it potentially
can access anythings and needs to control its associated hardware. How can
there possibly be a connection to your “act like a good engineer” thesis?
Car designers have full control of the system architecture, mainstream OS
driver writers don’t. We depend on all others behaving nicely. And I mean
there’s an awful lot of others running concurrently with you at the same
time. Mainboard buggy, soundcard buggy, graphics boards locks up the system.
Is there anything in the PC world that’s not buggy. I have not seen one
graphics chip that isn’t and I’ve seen every single one in the last 5 years,
S3, Number nine, C&T, 3DLabs, E’n’S, IBM, none is fine, released with
Pandoras box inside. 50 million transistors on a chip. NVIDIA have problems,
ATi do, memory makers do, can you finish that list for me. I have not seen a
single piece of hard- and software that is not buggy. Remember the crash of
the European ARIANE 5 rocket. There’s your real-time and process control.
Luckily noone died (just a cow that was struck by a piece of metal), it just
cost zillions of dollars. HOW CAN WE EVER IMPROVE?
Sound like a prayer and maybe this is one. No offense meant.
Klaus P.
ATi
-----Urspr?ngliche Nachricht-----
Von: Gregory G. Dyess [SMTP:xxxxx@pdq.net]
Gesendet am: Dienstag, 7. August 2001 22:26
An: NT Developers Interest List
Betreff: [ntdev] RE: Mapping scattered pages into process address
sp aceYour description describes my point exactly. A short-cut in the driver
causes unnecessary support calls. I’m not comparing your expertise
against
the people who wrote the OS. I am saying they are in a superior position
to
understand the interactions between the various drivers. This is simply
because you couldn’t possibly have as much contact with all the other
devices as they do. They don’t arbitrarily make edicts and restrictions
just for the hell of it. It’s also not a matter of them not being bright
enough to figure out how to give you free reign. There is a reason for
the
restriction or it wouldn’t be there. It’s usually there to prevent your
device from negatively impacting the overall system. Your device is not
the
entire computer and it must play well with all the other devices in the
system. Otherwise the entire system, including your device is useless.
It’s a bit presumptuous of you to assume that your device is absolutely
the
most important thing in the world and ignore all rules of system
etiquette.
Again, I point to the Matrox lockup problem.Now, try working in my field of real-time and process control for a while.
The system cannot go down, period. It also cannot be randomly hit with
unknown latencies. It has to be there and running correctly. NT/W2K is
laughed at by control engineers for this very reason. I would love to
still
be using VMS because it didn’t go down, unless it had a 3rd party device
with a buggy driver. That’s just not an option in today’s climate.Also, if you get to 99% complete 5 times faster and always crash at 99%
complete, you’ve gained nothing over the slower solution that always
completes. All I’m saying is play well and don’t crash the system or you
should face stiff consequences. This is the way all of engineering works.Greg
You are currently subscribed to ntdev as: xxxxx@ATi.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com