My proposal doesn't prevent anyone from doing anything and it doesn't take away
any freedom from the writer, that's the beauty of it. It only ensures that one
is able to build a UDI driver for a UDI conformant device if one wants to, and
nothing else.
Try to imagine the following situation. You're out to buy some hardware for
your new server, for example a new SCSI controller. And because you're aware
that in order to be useful this new shining SCSI controller is going to need a
driver, you'll naturally try to make sure there is one for the operating system
you use. You want to go with the safe bet and because you know you have a UDI
conformant OS in the office, you decide to buy a card that has a label on it,
saying "UDI CONFORMANT".
Cool, you go, and you buy the thing, plug it into the system and install the
drivers. Whoooooops! No driver version for this particular processor that
everyone in our company (you can replace 'company' with 'customer' if you
like) uses??? Ouch!
So now you're stuck with a card that you can't plug anywhere (ok, you can plug
it 'somewhere' but that's not what you wanted originally). And you bought
exactly this particular card merely because you thought it would work in your
environment - you had every reason to believe so because you saw the
certificate on the box. It's a lousy feeling to spend a lot of money on
something that then doesn't work for you. Sounds too much like the Microsoft
way with all the mental torture and stuff.
Now, in order to understand the hardware driver situation, we have to
understand that hardware and software are complementary goods. Like cars and
fuel. Would you buy a car that you couldn't drive because you couldn't get the
fuel? I wouldn't because its of no use to me if I can't buy the fuel.
But software is a different type of commodity than fuel, because unlike fuel
and other very physical stuff you don't need very special and costly equipment
to produce it. All you need is a compiler and some knowledge. So while you
can't produce fuel by yourself to make your new car go, you CAN write a driver
for your new SCSI card by yourself - all you need is a compiler (which comes
with the system) and some documentation where you can look up how to interface
the damn thing on a low level. Please, DO notice that I left out 'open source'
on purpose, meaning that a vendor is absolutely NOT forced to give out an open
source driver - it suffices to give out just enough documentation to be able to
produce a driver, ie it suffices to publish the interface that the software
uses to make the hardware operate.
But let's get back to UDI.
Correct me if I'm wrong, but UDI's primary goal is to bring drivers to vendors
that participate in the effort (and possibly others). So it makes sense that UDI
does everything it can to actually bring drivers.
UDI is supposed to be a 'technical specification'. But because UDI environments
are very likely to differ A LOT, being merely a technical specification isn't
enough to ensure working drivers for all UDI conformant environments. A driver
can be certified yet this certificate is worthless because it CAN'T ensure what
it is supposed to ensure. So it becomes a marketing stunt, not a driver
functionality certificate. There are tons of drivers that were written for ONE
'most popular' operating system only (instead of a number, such as what is the
case with UDI), a lot of which were certified directly by the manufacturer
itself, yet MANY of those drivers simply don't work. What is the point in a
standard when what is done by the standard (and certified by those who wrote the
standard) doesn't work? I think computer industry, and its customers even more,
had enough experience with such 'standards' that it should know better by now
than producing just another one.
The solution to the problem is not to certify a driver, but to certify a
device. A device is UDI conformant, when:
a) there is a source driver for a reference platform, or
b) there is enough documentation available to write a driver
Any one of these two satisfies the requirement.
This doesn't stop anyone from producing a UDI certified binary only driver
for a UDI certified device, and it doesn't stop anyone from licensing it any way
they want. It only ensures that a customer CAN get a WORKING driver for his
particular UDI environment - if not otherwise then by writing one himself using
the provided documentation.
As you've already noticed, preferably a vendor will give out both - a source
driver for a reference platform and the accompanying documentation. A source
driver will ensure easy review, fixes, adoptations and so on. Because it's for
a reference platform, everyone who implements the same interface as the
reference platform will be able to directly use the driver. And documentation
will make it possible to verify the implementation.
> > > If, instead, you have a published interface vendors can write to the
> > > interface _once_ and, over time, see that their competition is not
> > > toppling over the edge into bankruptcy, but is actually benefitting
> > > from having source available drivers, they will eventually realize
> > > that source available drivers is a competitive advantage (and may
> > > realize before then that's it's a lot cheaper to release the sources
> > > and let third parties write and maintain the drivers.)
> >
> > They may, in which case everything is fine since everybody wins. Then again
> > they may for some reason not care about this particular competitive advantage
> > and just do a binary driver. In order to be sure you get to benefit too, you
> > make sure you are at least _able_ to produce your own driver if the hardware
> > vendor doesn't feel like doing it - for whatever reason. And you need a
> > reference source or hardware specs for that, unless you'd like to resort to
> > practices like reverse engineering.
>
>You are arguing that companies must provide information to you, even
>if there's no competitive advantage to them, even if they don't want
>to, even if it *hurts* them or even drives them out of business... all
Of course not. But what is the competetive advantage to them if I'm not able to
use their hardware? And why would they not want me to use their hardware?
And how am I going to hurt them by reading the source for the driver (or the
documentation) if I can disassemble a binary driver as well and find out by
myself? There is no marginal security lost by providing this information.
>because it's inconvenient to you.
I bought a card and I want to USE it. Of course it's inconvenient to me if I CAN'T.
>An extrapolation of this argument is that if this were to happen we
>would end up in one of two distinctly unpleasant situations:
>
>1) hardware vendors would not see any competitive advantage to
> producing the hardware in the first place, therefore the hardware
> never gets created, therefore growth in the computer industry
> stagnates and we all suffer, or
>
>2) the big hardware vendor can copy all of the innovation made by the
> "little guys" as soon as they make it available and use it's
> marketing capabilities to insure that consumers are only aware of
> or use the big vendor's products. The result is that all the
> little guys can't compete and we end up with a monopoly.
Finding out what 'little guys' did in a product is hardly a nuisance to the
'big guys'. Publishing the interface that the software uses to make the
hardware work will hardly make any difference.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si- 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/