ETXTBSY

[Kenneth Brody]

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?

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com