Path: utzoo!attcan!uunet!husc6!rutgers!gatech!cadeta!dtscp1!scott
From: scott@dtscp1.UUCP (Scott Barman)
Newsgroups: comp.unix.questions
Subject: Re: fcntl() versus ioctl()
Keywords: FNDELAY
Message-ID: <345@dtscp1.UUCP>
Date: 16 Sep 88 21:34:39 GMT
References: <1380@solo7.cs.vu.nl> <7034@ki4pv.uucp> <68560@sun.uucp>
Reply-To: scott@dtscp1.UUCP (Scott Barman)
Organization: Digital Transmission Systems, Atlanta
Lines: 59

In article <68560@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>"fcntl()" acts either on the file descriptor or on the file table
>entry to which the descriptor refers (later UNIX releases also added other
>functions, such as record locking, which don't fit this model, but you can
>argue that they should have added a new call for those; 4.2BSD also
>misimplemented no-delay mode as an "ioctl()", and had the "fcntl()" basically
>do the "ioctl()" for you, but the original implementation of "fcntl()" in S3
>got this right).
Why is no-delay misimplemented in 4.2bsd ioctl, isn't turning on no-delay
an means of controlling i/o (which is where the i/o control system call
comes in)?

>"ioctl()" generally acts on the object (file, device) to which the file table
>entry referred to by the file descriptor refers (earlier UNIX releases stuck
>functions such as FIOCLEX that operate on the descriptor and leave everything
>below it alone, but you can argue that adding "fcntl()" for this function was
>the right idea).
Since when does ioctl act only on the object?  How much of the ioctl stuff
for terminal i/o do you think really some of that stuff gets to the actual
driver for manipulating the hardware?  The last I looked (which was not
that long ago), most of the ioctl's effect the tty software driver (input
or output canonization, etc.) and the only thing I had to worry about was
parity, baud rates, generating breaks (also catching them), and hangup
(setting baud rate to 0).  This has been the case since V7 (gee, am I
showing my age? :-).

>> I don't see any moral difference between fcntl(2) and ioctl(2), myself.
>See above.	(it was deleted here for brevity)
I do!  Why have a file control system call and an i/o control system call
when most i/o is on files anyway (a fundamental of Unix).  I can understand
different structures for the different types of ioctl's but not having
two systems calls and all the overhead involved--especially since the
call is written to know that the ioctl on a character device has to go to
the routine defined in the cdevsw table, etc.  Just more gunk and overhead
where it is not necessary.

>> Thus, if ioctl() might cause a parent to suffer, fcntl() may be expected
>> to have a similar hazard.
>In general, both "fcntl()" and "ioctl()" *can* act on objects that are shared
>by various file descriptors, so they *might* cause objects shared with a parent
>to be affected.
The only time that an ioctl or fcntl should effect a parent or other non-
related processes is when they have to effect shared resources.  The file
locking is a necessary shared resource that should go away when the child
processes ends.  Additionally, since terminals are shared resources (it
has only one tty structure leading to one piece of hardware, etc.), I can
see where changing it can effect all concerned.  However, anything else
should be considered a bug (feature? :-)

>However, while (with the exception of FIOCLEX, which could be argued shouldn't
>have been an "ioctl()") "ioctl()" acts *only* on shared objects, "fcntl()"
>*can* act on non-shared objects (the file descriptor itself).
It should not matter i/o control is i/o control no matter what the file
is since they are both accessed as files with the same system calls!  Any
distinction between them and you begin to lose that transparency that
is Unix.

-- 
scott barman		..!gatech!dtscp1!scott