Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: fcntl
Message-ID: <3047@auspex.auspex.com>
Date: 15 Mar 90 19:53:49 GMT
References: <1990Mar13.125755.9720@granite.cr.bull.com> <12351@smoke.BRL.MIL>
Organization: Auspex Systems, Santa Clara
Lines: 27


 >>  I know what the entry point(s) to ioctl are (I've seen
 >>enough drivers but where are the fcntl entry points?
 >>There is sort of an overlap there. Will a fcntl cause
 >>a call to dev_ioctl?
 >
 >Well, it's not supposed to -- fcntl() was introduced specifically
 >to play with the file table entries, which is something the device
 >driver is not supposed to know (or care) about.

Unfortunately, both Berkeley and AT&T fairly quickly extended "fcntl()"
to do stuff other than monkey with file table entries.

In most cases, "fcntl()" will not call a device driver routine; there is
no "fcntl" entry point for a driver.

However, Berkeley saw fit to make no-delay I/O a property of the device,
rather than of the file table entry (it really should be a property of
the file descriptor, not the file table entry, but...), and the way they
do asynchronous I/O also makes it a property of the device.  This means
that in systems that support BSD-style no-delay and asynchronous I/O,
the "fcntl"s that turn on or off those modes cause FIONBIO and FIOASYNC
"ioctl"s, respectively, to be done. 

AT&T hasn't done anything like that in System V; "fcntl()" only reaches
its grubby paws down through the file system switch, not the device
driver switch....