> Then again, for raw performance (where it matters), fixed specs have
> their downside because our knowledge and capabilities improve with time.
> Imagine if the Linux binary driver interface were still the same as in
> the 2.0.x days. We'd be missing a lot of the performance advantages we
> have with 2.1.x, most notably the exception handlers in copy_from_user et al.
Oh, unquestionably. I wouldn't even be suprised if UDI 1.0 turned out to
be something like the VESA video BIOS 1.0 -- a good idea, but not really
useful for much of anything, let alone a proper OS. Even if it's useful
for everything it was supposed to be, everybody involved will learn
things. (Is there anything decent in this industry that _hasn't_ been torn
down and rebuilt from scratch at least once?)
It will be a _very_ interesting experiment to see if we can support UDI
without compromising the efficiency of anything else. If we can keep that
up for (currently hypothetical) future UDI versions, then we're all set to
aim for a decent middle ground.
And, frankly, given that computer technology has increased at a remarkable
pace, I'm more then willing to give up a few cycles to use a "better" (in
the long run) driver. We've gone through that process several times, and
it usually ends up being a step forwards, not backwards. HLLs, MMUs, OO
principles, etc.
> > Another complaint I've seen made several places is that "the manufacturer
> > will just foist off some half-baked UDI driver on the Linux folks". First
> > of all, this is isn't any worse then the current situation for most
> > manufaturers.
>
> (IMO) Indeed most manufacturers produce poor drivers for _all_ their
> supported platforms, though they might do some half-baked testing on
> Win95.
I certainly can't argue with that. Poor drivers, and sometimes worse
hardware. (Anyone remember Orchid? <shudder>)
> > Secondly, _why does Linux have anything to do with this_?
>
> The complaint is that UDI makes it easy for manufacturers to produce a
> Linux driver, and despite the short term benefit, we'd be worse off.
>
> Right now, only the most dedicated and helpful manufacturers tend to
> produce Linux drivers, the rest are written, mostly to a high quality by
> Linux users.
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. 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. (By definition, more or less: if we trust their driver to be good,
we are already trusting them to a large degree.)
> 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.)
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.
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.)
> > 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.
(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.)
> > Remember what UDI is supposed to be, and consider whether "the
> > manufacturer will just foist off some half-baked UDI driver on the
> > entire consumer community, and then spend time writing native drivers
> > for the popular OSs" make any economic sense.
>
> This is where you've mistaken most of the criticism. We believe that
> most manufacturers write poor drivers for _all_ supported platforms,
> Windows included, and much of Windows reputed instability is due to
> this. We don't expect them to spend extra time writing native drivers
> for any OS, popular or not.
On the former, UDI should make it easier to write drivers, which should
increase, slightly, the general driver quality level. (Even if UDI is
harder to use, it's still a fixed target. Windows usually isn't.) But no,
I can't see UDI changing anything substantially, beyond the gains implicit
in UDI.
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.
On your latter point, I can only agree.
> If manufacturers who currently don't support Linux start supporting it
> _as badly_ as they support Win95 (most Win95 drivers do not work under
> NT), Linux will also acquire a reputation for instability, because of
> those drivers.
>
> 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.
This matter could be approached in the same manner we already deal with
generically supported hardware (like NE2000 clones, SCSI devices, etc.):
keep a list of which ones work and which ones don't, and try to convince
the manufacturers to make better ones. That it is a driver instead of a
piece of hardware won't make a difference.
The interesting difference is this list should apply to _all_ platforms
using the UDI drivers, so it could (and will, if one of the media groups
like ZD decided to help) have very high visibility.
> 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.
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.
> > The exact same issue that causes poor drivers to begin with should
> > be an _incentive_ to create good UDI drivers in the first place.
>
> I think you got this upside down. The same issues that cause poor
> Windows drivers to be written will cause poor universal drivers to be
> written.
Some of the issues, yes. And some other issues should work in the other
direction.
> > As for open-source vs. binary, UDI would actually help the dissemination
> > of open-source drivers. As far as can see, it _must_ do: any UDI GPL
> > driver that is coded will work on _all_ platforms, whereas currently it
> > will work only on one platform (Linux, BSD, whatever).
>
> 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.
> > (And no, I wouldn't want a gigabit ethernet board to be slowed down by
> > anything, if I could avoid 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. :-)
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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/