Linus Torvalds writes:
> 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.
...
> 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.
You want a well-defined interface, allowing over-network use?
Well, here you go, the CORBA ORB patch for Linux 2.4 kernels:
http://korbit.sourceforge.net/
Do you want that against 2.4.5-pre5 or what? Plain ASCII email?
:-)
The really sick thing is that I could actually use this too.
It handles the DSP problem well.
-
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/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:50 EST