fcntl() versus ioctl()

[Guy Harris]

> 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)?

No-delay is misimplemented in 4.2BSD "fcntl", not 4.2BSD "ioctl".  There is no
reason to make no-delay mode a property of the object to which a file
descriptor refers; the only way in which it should affect the behavior of the
object is that it should alter the behavior of the "read" and "write" system
calls.  As such, the way it could and should have been implemented would have
been to pass the current state of the no-delay flag to the device driver
"read" and "write" routines.  This means that if you set no-delay mode on one
file descriptor, it doesn't mean that accesses through an unrelated file
descriptor become no-delay accesses.

In fact, it arguably should have been a per-descriptor flag, rather than a
per-file-table-entry flag, so that if you set no-delay mode on one file
descriptor, it wouldn't even make accesses through a *related* file descriptor
become no-delay accesses (the standard input of a shell and of a command it
invokes are often related, which is why the problem that first triggered this
discussion occurs).

> 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?

As someone who has worked a fair bit with both the BSD and S5 tty drivers, and
who has written much of the SunOS 4.0 tty driver, I not only think that it all
gets to the actual driver, I *know* that it all gets to the actual driver.  Not
all of it affects the hardware, and not all of it is necessarily used by the
hardware driver; however, "the object" refers not to the serial port hardware,
it refers to the state maintained for that port by the line discipline as well.

In that sense, "ioctl" most definitely does act on the object.  The tty
"ioctl"s don't act on the data structures that represent the file descriptor,
nor do they act on the data structures that represent the file table entry.

> 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).

Because file descriptors, file table entries, and the objects behind them are
distinct.  The "file control" system call is (or, at least, was) best called
the "file descriptor control" system call, since it only manipulated file
descriptors and file table entries.

> but not having two systems calls and all the overhead involved...

All *what* overhead?  Could you please quantify this "overhead"?

> 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.

"fcntl" most definitely wass not originally written to know any of this.  The
original S5 "fcntl" call never looked at the inode pointer in the file table
entry, so it knew nothing whatsoever about the object referred to by the file
descriptor.  "ioctl" does what you discuss, but I fail to see why the fact that
it does all that has any relevance whatsoever to any of the points you may be
trying to make.
device driver routines; it just 

> 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.

Which was exactly my point; "fcntl()" can certainly set flags that belong only
to the file descriptor on which it acts, so the behavior the original person
appeared to want - namely, that no-delay mode *not* be shared between file
descriptors - could be implemented.

> 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!

I/O control is I/O control, but file descriptor control is file descriptor
control, and they are different.  *That* was the point being made, which you
appear to have completely missed.  You appear to be confusing file descriptors
with the object to which they refer.  File descriptors and file table entries
have their own state, which is distinct from the state maintained by the object
to which they refer.