On Sun, Oct 11, 1998 at 06:55:13PM -0400, Kenneth Albanowski wrote:
> This is the point I differ on, but I can't see how to prove it either way.
> What you say implies that some manufacturers will drop the real Linux
> drivers because they can get away with one poor UDI driver that runs
> everywhere.
No, I'm talking about the manufacturers who currently do _not_ produce
Linux drivers. I.e., the majority.
> I'll argue that any manufacturer that understands the need for
> native drivers -- and is capable of writing a decent Linux driver -- is
> clueful enough to understand the whole UDI issue, and will do The Right
> Thing.
Yes of course. I prefer the work of device manufacturers over the work
of volunteers when it's good -- it's their hardware and they know how to
work it. But I think those companies are in the minority.
>> With UDI, all those manufacturers who produce poor drivers for Windows
>> will be able to produce poor drivers for Linux as well. We don't want
>> that, because that gives those manufacturers the excuse to withhold
>> technical information that we need to write high quality drivers.
>
> Remember that their point of view is different. It's not an "excuse to
> withhold", but rather "a way to avoid the expense of documenting the
> hardware". (The companies that actually want to withhold information due
> to "trade secrets" are a completely separate matter: they're simply not
> going to freely release the information, unless their Weltanschauung
> changes.)
Of course. Their point of view is relevant to convincing them of the
merits of open source perhaps, but it's not relevant to the effect of
poor binary only drivers on the Linux community. If they withhold the
technical data _and_ give us poor drivers, we lose.
> Regardless, yes, I have to agree. UDI would indeed be a good "excuse" for
> writing a single driver that works everywhere, and not helping other folks
> write drivers. However, this doesn't mean that it is necessarily going to
> be a poor driver -- indeed, I'll argue that if UDI turns out to be useful
> in the real world, the standardization of the UDI interface will make it
> much easier to write a reliable UDI driver then, say, a Windows driver.
Note, I do think a good, portable driver interface is a good idea.
Linux interface is close, BSD interface is probably close (I've never
looked). The Windows DDK is difficult to work with judging from all
I've heard about it, but it's all second hand information.
It's the political consequences of UDI in particular that I'm concerned
about. If it were a case of the Open Source(TM) community developing
the UDI specs and sample implementations for various OSes, I'd likely be
a strong advocate of it.
Maybe it will turn out well; I'm simply going to watch and see what
happens. The politics will not deter me from writing actual UDI drivers
if it's any good :-) They'll still be GPL'd drivers if I have the choice.
> But again, this is only a mild prod against free drivers: if the company
> is clueful, they'll do what is right, _by definition_, given the
> assumption that our point of view is the right one, tautologies be damned.
> (We can't argue that some folks are just plain dumb, after all. If they
> are, we can't change that. Likewise if they are just plain evil. So it's
> best to assume that they simply don't know any better.) UDI or no UDI, we
> still just need to educate the manufacturers.
>
> (Buslogic/Mylex seems very clueful: their help of Leonard N. Zubkoff is
> directly responsible for me purchasing a Buslogic SCSI card, sight
> unseen, in replacement for an Adaptec card.)
Yes, when investigating SCSI a couple of times I was poised to buy
Buslogic for the same reason. But I decided SCSI was too expensive and
UDMA good enough for my needs.
> > > UDI is supposed to be universal, so by writing a _good_ UDI driver, the
> > > company instantly supports SCO, UNIX, Linux, and perhaps just about
> > > everything else (if UDI isn't Unix-centric).
> >
> > The company can "support" everything by writing a half-baked driver --
> > it does this already for Windows. (Not true of all companies, but many).
>
> And if they think they can get away with that, they eventually get blown
> away by a similar company that writes full-baked drivers (or someone like
> SciTech comes along, and writes drivers for them). UDI should simplify
> competition in the field of drivers, since the quality of the drivers
> should me more directly comparable.
I think an issue is that a lot of hardware is not sold on the quality of
its drivers. Having got the snazziest graphics card (according to the
specs, benchmarks on a machine that it worked fine on etc.), if there
are glitches or you have to turn down the acceleration, not run at some
refresh rate etc., you live with it. It was too expensive to replace it
now.
If there are occasional crashes due to a driver, often there's no clue
that it is the driver at fault. Unless these failures occur often and
obviously, diagnosing the cause of the fault is too hard. Even for
reviewers.
SciTech produce good replacement drivers; that doesn't exactly
discourage you from buying the hardware, does it?
> (And, in theory, a standard driver interface should allow much better
> driver diagnostic tools to be written, such as running a driver in a
> separate address space, as Kurt describes.)
I still maintain `printk' is one of the best diagnostic tools ever
invented! Every OS should have one.
> Which in turn means that this doesn't really change anything: we still
> need to convince manufacturers to make better drivers, convincing then in
> an economic manner, if necessary.
Show them how important stability with a broad user base is, and how
Open Source(TM) can help with this economically, perhaps?
> > Right now we have a reputation for stability and high quality drivers
> > because of peer review, coding by the actual users, good feedback from
> > testers in the field etc. That will go down the pan if manufacturers
> > find UDI an excuse to prevent this form of high quality coding.
>
> Again, you seem to be arguing that despite having so many smart people
> (who do the peer review, give and take feedback, etc.), that everybody
> will be too stupid to notice that a UDI driver is causing problems. You
> can't argue both ways at once.
No no, I'm arguing that UDI binary drivers remove incentive for
releasing hardware docs, so the quality of drivers for new hardware will
be lower than it is without UDI. If the hardware docs are still
available, the smart people will still write replacement drivers as
needed.
> > Indeed, many manufacturers simply _cannot_ create high quality drivers
> > because they don't have the infrastructure -- unless they choose to
> > participate in the open development process, that is.
>
> Agreed, and this is one of the ugliest aspects of the current industry.
> The trick is to make it widely understood that the economics favour open
> development. This has nothing to do with UDI.
I'm including the above quote because it is so important!
> What _does_ have to do with UDI, is that open source driver development
> could serve the _entire_ community. With UDI, a company could actually
> successfully sell a piece of hardware that uses an open source driver
> built, at least in part, by the developer community. This is infeasible
> with non-universal drivers, especially given the current DDKs. (I can and
> have written small Linux drivers on a lark. I haven't yet even _found_
> half the tools needed for developing Windows drivers, never mind
> understanding where the documentation is, or feeling up to writing the
> things on a whim.)
>
> This would appear to make open-source UDI an absolute panacea for
> companies with limited resources for developing drivers. Even if they need
> to develop an initial driver in-house (to debug the hardware), releasing
> the driver as open source would reduce the maintenance costs, and perhaps
> even provide better feedback to the hardware developers.
Ah, you may be on to a good point here. Smaller companies may produce
better drivers because UDI gives them some of the infrastructure that
Windows DDK does not. And they can develop on Linux, undoubtedly a
better development platform for drivers. :-)
Open Source(TM) may also help them in that people like me will give out
our knowledge and some time freely to Open Source(TM) projects. It's
not entirely political -- there's an element of "what's in it for me?".
Time is always limited of course.
> > I agree, there may be advantages in the open-source community using UDI
> > for portability. The issue is that we don't want to help closed-source
> > manufacturers, as most don't seem to be very good at writing drivers.
>
> I think I can argue that UDI at least doesn't make a qualitative
> difference: UDI drivers can be open and closed source just as native
> drivers can, and a native Linux driver can already be open or closed (by
> virtue of binary installable modules). UDI merely makes it easier to make
> a closed Linux driver, it doesn't add anything new to the game. Thus,
> we're back to education.
That ease you refer to seems to be the contentious issue. The fear is
that UDI will shift the balance from "not worth supporting Linux" to
"worth supporting Linux" (but not as well as the community).
Which is really hidden praise for UDI's technical goals. After all,
unless UDI is very, very good, it won't really make it easy to write
cross-platform drivers, will it?
> > I'm convinced that here, coding to _any_ fixed interface will slow down
> > the fastest network technology of the day. We learn new tricks all the
> > time, and for the leading edge, we put the effort into applying them.
> > Only open source has this flexibility.
>
> Agreed -- and it's amusing that this flexibility used to be called
> Research. Funny how vestigies of University still pervade the 'net. :-)
A lot of research is done outside universities. Building the latest,
fastest commodity hardware is surely in that category. And that's the
hardware we use these days.
-- Jamie
-
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/