do away with global ioctl()? (Was: fcntl() versus ioctl())

[Maarten Litmaath]

In article <8533 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
\In article <7039 at ki4pv.uucp> tanner at ki4pv.uucp (Dr. T. Andrews) writes:
\>In article <1407 at solo12.cs.vu.nl>, maart at cs.vu.nl (Maarten Litmaath) writes:
\>) Aha! And where's the expected next statement: why has fcntl() been
\>) invented in the first place?
\>My suspicion is that it seemed to someone like a good idea at the
\>time.
\
\It IS a good idea.  If you check out the internals of the kernel,
\you'll find that ioctl is really supposed to be a hook into I/O
\device drivers for things that don't fit the open/read/write/close
\model.  fnctl on the other hand is for manipulating file table
\entries and other similar actions that should not involve the
\device driver at all.  Since both of them enter the kernel, either
\COULD do anything at all, but a clean partitioning of function is
\desirable.

Exactly my idea of it.
But why are ioctl() effects global AT ALL? Isn't it possible e.g. to save the
tty state per process? That would imply that programs like 'vi' needn't worry
when they're suspended, because the kernel will take care of the tty settings.
A child will first inherit the tty mode from the parent, but if it wishes to
change it, the parent will not suffer from it. /bin/stty would be replaced by
a built-in function in the shell.
-- 
    Alles klar,                       |Maarten Litmaath @ Free U Amsterdam:
                   Herr Kommissar?    |maart at cs.vu.nl, mcvax!botter!maart