Messages in this thread | | | Date | Sun, 11 Oct 1998 18:55:13 -0400 (EDT) | From | Kenneth Albanowski <> | Subject | Re: [OT] RE: UDI and Free Software |
| |
On Sat, 10 Oct 1998, Jamie Lokier wrote:
> 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/
| |