maart@cs.vu.nl (Maarten Litmaath) (09/22/88)
In article <8533@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: \In article <7039@ki4pv.uucp> tanner@ki4pv.uucp (Dr. T. Andrews) writes: \>In article <1407@solo12.cs.vu.nl>, maart@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@cs.vu.nl, mcvax!botter!maart