Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: fcntl() versus ioctl() Keywords: FNDELAY Message-ID: <68800@sun.uucp> Date: 17 Sep 88 09:02:42 GMT References: <1380@solo7.cs.vu.nl> <7034@ki4pv.uucp> <68560@sun.uucp> <345@dtscp1.UUCP> Sender: news@sun.uucp Lines: 75 > 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.