"Khimenko Victor" <khim@sch57.msk.ru>:
>P.S. And "ask user" approach is also not perfect: WHICH user ? If there are
>100 users logged in system and disk is used by dome deamon (like updatedb)
>which user should be asked to put CD/floppy back ? It's easyto put such feature
>in single-user OS like AmigaOS, WindowsNT and/or MacOS. It's MUCH more
>complicated to put it in mutliuser OS with remote login possibility...
This is now asking for a "resource allocation daemon" to keep track of
who requested access to a removable media unit and what is loaded into the
device. The user should not be able to make use of the device until allocated,
and if a file system mount required, another daemon (or the same) should mount
it by request. If the media is removed without dismount, then that user should
be notified. IF that user is no longer logged in, then the data should be
flushed from the system (tough, its a L user error). An alternative to
immediately flushing the data is to notify an operator (again, if logged
in) before flushing.
There are other advantages to a resource allocator too. One ability is to
detect deadlocks among jobs that need two or more separate resources. This
occurs when there is (for example) a tape and a CDRW. Two jobs want
to use the tape and CDRW. One job allocates the tape, the other the CDRW.
Neither job can complete. Resource allocation can also be used to enforce
some labling capability on the media, although that would require more
support from the kernel. I thing basic device allocation could be done
now, with very little interaction with the kernel. Access to the device
files (tapes/CDRW) could only be granted by changing ownership and modes.
Security (CDRW types) would have to be improved since most of these devices
are accessed via the generic SCSI interface (that apply to the IDE devices
too?).
BTW, if a user logs out without releasing the resources - the resource
should be dismounted/ejected on logout. I realize that floppy devices
do not normally have a locking mechanism, so it wouldn't work there.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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 : Wed Feb 23 2000 - 21:00:18 EST