Messages in this thread |  | | Date | Sun, 20 May 2001 20:12:04 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [RFD w/info-PATCH] device arguments from lookup, partion code |
| |
On Mon, 21 May 2001, Ingo Molnar wrote: > > On Sun, 20 May 2001, Alexander Viro wrote: > > > Linus, as much as I'd like to agree with you, you are hopeless > > optimist. 90% of drivers contain code written by stupid gits. > > 90% of drivers contain code written by people who do driver development in > their spare time, with limited resources, most of the time serving as a > learning excercise. And they do this freely and for fun. Accusing them of > being 'stupid gits' is just micharacterising the situation.
I would disagree with both of you.
The problem is not whether people do it with limited resources or time, or whether they are stupid or not.
The problem is that if you expect to get nice code, you have to have nice interfaces and infratructure. And ioctl's aren't it.
The reason we _can_ write beautiful filesystems these days is that the VFS layer _supports_ it. In fact, the VFS layer has tons of infrastructure and structure that makes it _hard_ to write bad filesystem code (which is not to say that we don't have ugly code there - but much of it is due to historically not having had quite the same level of infrastructure).
If we had nice infrastructure to make ioctl's more palatable, we could probably make do even with the current binary-number interfaces, simply because people would use the infrastructure without ever even _seeing_ how lacking the user-level accesses are.
But that absolutely _requires_ that the driver writers should never see the silly "pass a random number and a random argument type" kind of interface with no structure or infrastructure in place.
Because right now even _good_ programmers make a mess of the fact that they get passed a bad interface.
Think of it this way: the user interface to opening a file is "open()" with pathnames and magic flags. But a filesystem never even _sees_ that interface, it sees a very nicely structured setup where all the argument parsing and locking has already been done for it, and the magic flags don't even exist any more as far as the low-level FS is concerned. Which is why filesystems _can_ be clean.
In contrast, ioctl's are passed through directly, with no help to make them clean.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |