ETXTBSY

[Jean-Pierre A. Radley]

Ken Brody propounded (on Wed, Oct 26, 2005 at 09:14:52PM -0400):
| Quoting Jean-Pierre A. Radley (Wed, 26 Oct 2005 19:21:23 -0400):
| 
| > From a SCO engineer:
| [... the new VM architecture in SCO 6 ...]
| > | However, like all diamonds, it has flaws.  ETXTBSY is no longer
| > | supported.  This is pretty much a result of one of the key aspects
| > | of the VM design, which is that there is only one copy of a given
| > | file page in the system for all uses.  Thus, any attempt to put back
| > | ETXTBSY is going to be so expensive that it's not going to be worth
| > | it unless there is some huge revenue opportunity that is going to be
| > | lost simply because ETXTBSY is not supported.  This seems an unlikely
| > | scenario.
| [...]
| 
| First, let me admit that I have no access to SCO source, and this is
| all speculation, based on my somewhat limited experience with Unix
| kernel internals.
| 
| 
| Now, can we assume that each running process has a struct which
| contains, among other things, a pointer to an open inode struct?
| (It would need this inode pointer in order to keep track of where
| to load pages from disk to memory.)
| 
| Next, can we assume that each open inode struct does/can contain a
| member containing the number of times this inode is open for an
| active process?  (Note the "can contain" possibility.  Since it is
| the kernel which starts processes, and sets up the proc struct, it
| knows that the inode is open for execution.)
| 
| Finally, can we assume that each open instance of this inode at the
| file I/O level contain a pointer to a single open inode struct for
| this file?  (This is needed to know which inode is open, and to make
| sure that all open instances share the inode information, such as
| filesize and status, while the individual file structs contain
| information such as file offset and access modes.)
| 
| Given the above perfectly reasonable assumptions (and I believe that
| they are all true, based on what I remember while learing about Unix
| kernel internals years ago), why isn't it possible to simply have the
| kernel's file open code check the inode's "number of processes having
| this inode open for execution" value, and if not zero, fail any open
| requests for writing with an error code of ETXTBSY?
| 
| Is there something about the VM architecture that precludes a proc
| entry from pointing to the inode struct?
| 

Reply from SCO:

There a bunch of problems here.

Ken's description suggests that he is familiar with pre-SVR4 kernels.
There are some key differences between pre-SVR4 systems on the one hand,
and SVR4 and later systems on the other, that affect the design question
here.

For example, SVR4 and later systems use vnodes and virtual file systems
(vfs) rather than inodes.  They also use dynamic linking, so a single
process typically executes code from more than one file; for example,
on OSR6, a process executing /bin/ksh will execute code from /bin/ksh,
/usr/lib/libc.so.1, and /usr/lib/libsocket.so.2.  Another difference is
that SVR4 and later systems also provide mmap and related interfaces,
which means that processes may execute code from files through means
other than exec.

In SVR4, the proc structure doesn't contain a direct reference to the
vnode(s) whose code the process is executing; there are several levels
of indirection through the VM system.

The kernel is much more modular than it used to be.  Generally, this
is regarded as a positive.  One consequence of this is that one cannot
always reach across subsystems to achieve some desired effect.

Because of this, implementing ETXTBSY likely would require changes in
the proc subsystem; the VM subsystem; the generic VFS/vnode code; and
the filesystem specific code for a bunch of file system types.

In other words, no, it's not as easy as Ken suggests.

In any case, though, it seems to me the first question to be answered
is, "is there a strong case for restoring ETXTBSY behavior, and, if so,
what is it?".

-- 
JP