Eric W. Biederman wrote:
> Oh, and don't forget that the hardware specification that drivers are
> written to, many times are not generally available greatly reducing
> the pool of capable people who have the opportunity to review the and
> debug the drivers. I would make it a requirement for a hardened
> driver that both the code and the hardware documentation be publicly
> available so the code can easily be reviewed by as many people as wish
> to.
This is a good point that bears highlighting. Donald Becker's [and thus
the kernel's] eepro100.c had certain bugs for years, simply because
access to Intel E100 hardware docs was damn near impossible to obtain.
I don't see driver hardening being very feasible on such drivers, where
the vendor refuses to allow kernel engineers access needed to get their
hardware working and stable. [why vendors want crappy Linux support,
I'll never know]
Jeff
P.S. In all fairness, Intel is doing a really good job maintaining the
e100 and e1000 drivers nowadays, and e100 docs should be public very
soon. [e1000 docs? who knows...]
On Tue, 24 Sep 2002, Jeff Garzik wrote:
> Eric W. Biederman wrote:
> > Oh, and don't forget that the hardware specification that drivers are
> > written to, many times are not generally available greatly reducing
> > the pool of capable people who have the opportunity to review the and
> > debug the drivers. I would make it a requirement for a hardened
> > driver that both the code and the hardware documentation be publicly
> > available so the code can easily be reviewed by as many people as wish
> > to.
>
>
> This is a good point that bears highlighting. Donald Becker's [and thus
> the kernel's] eepro100.c had certain bugs for years, simply because
> access to Intel E100 hardware docs was damn near impossible to obtain.
Jeff,
You know that every hardware vendor will clam it works well under
MicroSoft, so why does it fail under Linux. This is the classic one-liner
we all have gotten. The reality is closed software is used to hide all
the flaws and failures of made by the ASIC people. I would love to shove
the brain dead asic designer of the original PIIX4 AB/EB off a cliff on
fire for being absolutely "stupid". Sorry this is as nice an clean as I
can say this and not dust off the flame thrower.
> I don't see driver hardening being very feasible on such drivers, where
> the vendor refuses to allow kernel engineers access needed to get their
> hardware working and stable. [why vendors want crappy Linux support,
> I'll never know]
Worse is getting a spec that says, "no work around".
When the reality is the OEM hardware vendor will not take ownership of
their errors and disclose a good proper work-around.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Andre Hedrick <[email protected]> writes:
> Jeff,
>
> You know that every hardware vendor will clam it works well under
> MicroSoft, so why does it fail under Linux. This is the classic one-liner
> we all have gotten. The reality is closed software is used to hide all
> the flaws and failures of made by the ASIC people. I would love to shove
> the brain dead asic designer of the original PIIX4 AB/EB off a cliff on
> fire for being absolutely "stupid". Sorry this is as nice an clean as I
> can say this and not dust off the flame thrower.
Right. So we need to get to a situation where ASIC designers are not afraid
to admit they messed up. I have seen this from all vendors. More than
anything this is the reason we have a documentation shortage. Just when
we really need more documentation, and more code review to make certain
that the drivers are solid in the face of hardware bugs the vendors
stop talking.
As for ``It works well under windows so why does it fail under
Linux?'' line of arguing that is just a first reflex from people that
aren't used to dealing with Linux. Putting it in a business case and
saying noting that the vendors can ship X million more in volume, or
become part of Y prestigious system. People stop knee jerking and
start helping.
Getting those channels open through the business side takes time. And
the more independent software developers don't always have access to
those kinds of arguments. So we really need a way to shame a vendor
on a driver by driver basis that makes it worse to hide their
documentation than to admit to their bugs.
Being able to say we could not ``harden'' the vendors driver because
the vendor did not give us the real specification, and errata
information, might be enough to shame change that. If not we can try
other methods.
> > I don't see driver hardening being very feasible on such drivers, where
> > the vendor refuses to allow kernel engineers access needed to get their
> > hardware working and stable. [why vendors want crappy Linux support,
> > I'll never know]
>
> Worse is getting a spec that says, "no work around".
> When the reality is the OEM hardware vendor will not take ownership of
> their errors and disclose a good proper work-around.
If the vendor has not figured out a work around this is understandable
if undesirable.
As for what can be done about it to get good Linux drivers, it is best
to remember that businesses do not have clear and consistent
policies. Instead businesses are susceptible to the attack of many
pokes, and enticements by people waving cash. So by pure persistence
and repetition we should be able to get the word out.
We just need to come up with arguments that are just as persistent as
the ip lawyers who say you need secret ``ip''. And some
embarrassement that is stronger than the embarrassement at the quality
of their work.
Eric