Re: [RFD w/info-PATCH] device arguments from lookup, partion code

[Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>]

On Sun, May 20, 2001 at 12:02:35PM -0700, Linus Torvalds wrote:
> The problem with ioctl's is, let me repeat, not technology.
> 
> It's people.
> 
> ioctl's are a way to do ugly things. That's what they have ALWAYS been.
> And because of that, people don't care about following the rules - if
> ioctl's followed the rules, they wouldn't _be_ ioctls in the first place,
> but instead have a good interface (say, read()/write()).
> 
> Basically, ioctl's will _never_ be done right, because of the way people
> think about them. They are a back door. They are by design typeless and
> without rules. They are, in fact, the Microsoft of UNIX.
 
Yes, they are. Why? Because we cannot fit all behavior of a
devices _cleanly_ into read/write/mmap/lseek.

If we do, we would need different device views (which implies
aliasing of devices, which HPA does not like) and it would
still be not that clean, because reading from readonly gives a
stream and writing gives a stream too, not particular order
required until now.

[good points]

> Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
> that make the ugliness explicit and possibly easier to try to manage and
> fix? Very probably. And it would mean that driver writers could not just
> say "fuck design, I'm going to do this my own really ugly way". 

Ok, then I give you an real world example where I idly fight with
design since nearly 2 years.

A free programmable DSP (or set of DSPs) with several kinds of
memory and additional optional devices (like DAC/ADC, ISDN frames
and sth. like that) on it. This DSP is attached via some glue
logic on Parallel port, PCI, ISA or (soon to come) USB.

This thingie can (once programmed) act as a data sink, data
source or data processing pipe.

OTOH it should be randomly accessable via debuggers and program
loaders. It is also resettable/rebootable, has discontinous
memory of certain kinds (possibly harvard architecture) and many
more funny stuff. And it needs to upload software.

I try to unify all these stuff into a "Generic Processing Device
Layer" for Linux.

Now I like to be shown how I should fit this into clean design
that:

   - uses NO ioctls (Linus)
   - has only one device per DSP (H.P.A)
   - Does not emulate ioctls via read/write transactions (which I
     consider bogus)

Theory is nice, but until someone can show me a clean design for
this (admittedly heavy ;-)) example, I just don't buy your
arguments. 

A *better* ioctl would be nice, but we still need an "catch all
exceptional accesses" interface, IMNSHO.


Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.