On Sat, 10 Jun 2000, Richard Stallman wrote:
> The ability to handle removal of the floppy even when it is mounted
> and "in use" will be important for non-hackers, so I think it is worth
> some amount of effort. If the device is "in use" for an actual file
> descriptor, it would be fine to make all subsequent operations on that
> descriptor get errors. (One could replace all these descriptor with
> some internal magic "always get an error" descriptor.)
IOW, reimplement revoke(2), but that's harder than you think.
> As for the case of being "in use" as the working directory, it is
> probably not too hard to handle that case "correctly" by setting a
> flag that will be checked by file-name lookup routines.
LISP hackers know value of everything and cost of nothing...
> open on it. The program which has the open descriptor will have to
> lose, but the system as a whole should not stumble. What will
> supermount do in this case.
Kernel keeps its own (system-wide) caches. One word: metadata.
> Keep in mind that MSDOS didn't
> provide any caching, didn't have mmap() and even with all that it could be
> b0rken badly by inserting/removing disks at wrong times.
>
> If we want to make the system as good to use as Windows, for
We (tinw) don't. Think what you had written and you'll see why.
Windows is not good to use and if any UNIX drops to that level of
crappiness and instability - it's in bad need of SIGKILL.
> non-hackers, we have to give high priority to user convenience for
> non-hackers. We need to consider trading away features that are not
> terribly beneficial, such as caching and mmap on a floppy disk.
>
> Caching and mmap for files on the hard disk are useful features; for
> floppies, they are of little benefit. The main use of floppies is for
> file transfer and archiving. Caching and mmap are useful when you do
> substantial work on a file, and for temporary files. But if you want
> to make those operations efficient, the first thing you should do is
> keep the files on the hard disk rather than on a floppy.
And making fs and VM code dependent on the type of underlying device
is...? Sheesh. If you want to keep adding special cases - you have a
kernel of your own to kludge it into oblivion. Hurd, that is...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:21 EST