Demand paged executables.

[John Woods]

In article <134 at fts1.UUCP>, michael at fts1.UUCP (Michael Richardson) writes:
>   I've found, what I would consider to be a silly design decision on either
> AT&T (or possibly ICS). (One of many.)
> 	fts1-(~/filedep ) 16 =>: rm uniqserv
> 	uniqserv: 755 mode ? y
> 	rm: uniqserv not removed.
> 	Text file busy
> 	fts1-(~/filedep ) 17 =>: 
>Why should this happen? What is wrong with simply locking the inode internally,
>(so that the file doesn't disappear), but drop the link count to zero.

The answer is:  history.  It's always been done that way.  There's no
particular reason it needs to be that way, and UNOS (for instance) gets by
quite happily allowing the removal of active program files.

It also happens to be easy to allow writing to active program files IF it
isn't a demand paged executable.
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu