On Mon, 24 Jul 2000, Steve VanDevender wrote:
> > >Oh please. The point of a standard protocol is to make it possible to
> > >interchange devices from any number of manufacturers on the same
> > >interface. That way the kernel need have only a SCSI driver, not a
> > >Brand X SCSI driver, a Brand Y SCSI driver, a Brand Z SCSI driver, ad
> > >infinitum. We should have standard drivers to support standard
> > >protocols, not a huge mess of drivers for all sorts of nonstandard
> > >hardware.
> >
> > Thats right. I agree with that completely. You put a layer of
> > abstraction in so FEATURE_1 maps to vendor 1's proprietary
> > command for feature 1, and FEATURE_1 maps to vendor 2's
> > proprietary and different command, etc..
> >
> > 1 driver that supports multiple hardware. NOT multiple drivers.
>
>You're still missing the point. One driver supports a whole lot of
>hardware because the hardware conforms to a standard interface, and NOT
>because the driver contains a whole lot of special-casing to deal with
>quirks of different hardware.
Huh? Have a look through drivers/net some time. ne.c is a good
example. Or how about drivers/ide, which is more in tune with
the discussion. Look at the code. If there isn't special casing
in there, then you must have different source than I. Lots of
hardware have special quirks. Look at ide-cd.c for example.
#if ! STANDARD_ATAPI
if (CDROM_CONFIG_FLAGS (drive)->toctracks_as_bcd) {
toc->hdr.first_track = bcd2bin (toc->hdr.first_track);
toc->hdr.last_track = bcd2bin (toc->hdr.last_track);
}
#endif /* not STANDARD_ATAPI */
Just a simple example of _SPECIAL_CASING_ hardware that is
_NON_STANDARD_. AND, we do NOT have separate drivers for each
one, instead, we combine all the similarities into a common
driver, and special case the differences. This is nothing new in
Linux by far. Not for IDE, network drivers and other drivers as
well. If something is VASTLY different and there is no common
code, then a separate driver makes more sense, and exists. The
oddball cdroms that were abound back in 1992-1993 are an example
of this.
So special casing things in the IDE command interface for
particular drive extensions that are not part of the standard,
but are nice feature to add, would be a logical next step
IMHO. A "update firmware" command for example, and
others. Extract a common functionality, write a transparent
interface. ONE userland program can then talk to the hardware
even including ATAPI extensions, etc.. ONE driver.
>You don't need a stupid mapping of proprietary methods of doing
>the same thing; that's the point of having a standard.
I agree with the importance of standards, however the hardware
that is in existance is not 100% identical. Sure, they follow a
SPEC more or less, but they extend it as well. Why not have a
common interface to get rid of the differences? VESA VBE for
example? Every video card is different, the standard was VGA,
and vendors extended it. VESA brought things back together.
We can't control hardware vendors choices of implementing
stuff. The quick answer is "buy from vendors that do follow
standards". That is nice spoken aloud, but meaningless in the
real world of competition where standards bodies take 5 years to
formalize a spec, but the hardware vendor cant wait that long or
he will die because his competition puts out proprietary
extensions and the public could care less, and buys what is
fastest/best wether or not it bypasses standards or not. Look at
the modem standard wars, video, etc... How do we deal with
them? By making a common video API that software can
use. Libraries provide a common interface to provide hardware
abstraction. Modems? We have the AT command set. Devices that
don't use it - many emulate it, including ISDN. This is
abstraction to make it easy to have a common interface without
50000 drivers as you suggest.
>We just don't need to have multiple instances of the SCSI
>driver for different brands of disks; if it's a SCSI disk, then
>it should conform to the SCSI standard, and the standard SCSI
>driver will be able to use it without any special-casing.
Correct, however if brand X disk includes some whizbang new
feature to the drive and cant wait 4 years for SCSI MCLXIII to
come out, because their technology exists NOW, and provides a
great benefit to customers, you bet they'll provide proprietary
extensions. Other vendors will follow with similar features,
most likely implemented in an incompatible way. That can't be
controlled. What can be controlled is a common view of the
hardware to userland by hiding the differences, and that is done
with either special casing, when the devices are very similar,
with minor differences, or with separate drivers if they are
completely different. In the case of IDE or SCSI, we have the
benefit that those are standard protocols, and so they are the
common denominator. Extensions to this logically should be
implemented in a standard fashion with special casing, if the
extensions are widely used and common, or with some other oddball
way if it is a 1 in 1000 special thing.
That is my opinion based on following the kernel source code
anyways as that is how most things seem to be implemented, by
sharing a common codebase and special casing stuff that isn't, or
using a secondary file (in the case of the ne drivers where there
is a 8390 driver of common code for example).
>If the hardware tries to pervert the standard by adding a lot
>of proprietary features to its interface, or in particular
>tries to require the proprietary features for basic access to
>the hardware, then it's not standard hardware.
EXACTLY. That doesn't mean that we should deny a user the right
to use his hardware that has extra goodies. If those goodies are
useful and are things that other vendors also do too, but in a
different way, then we need to provide a common interface so that
the user can use hardware with similar features in a common way.
Forcing someone to use /dev/kmem to enable special things is IMHO
just stupid if they are common enhancements. As much as I hate
proprietary features being proprietary and oddball, I also want
to use my hardware to its fullest, including its proprietary
features, and I'd like to do it in a common way so that an app
that works with proprietary feature "zoomba" on widget X works
also with proprietary feature "zoomba" on widget Y despite them
being implemented differently internally.
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:15 EST