Auto-Mount/Dismount optional drivers development???
Thru...@worldnet.att.net
Pleas do not confuse this with that Supermount (supermount) used in
ManDrake Linux as this is different entirely...
The ability for storage devices to auto-Mount/DisMount their media in
the event that the eject button is pushed on the drive itself without
executing the dismount command from terminal or by script..
This would help in the following ways :
1. Security :
Drives can be linked to ones Login to allow access to only
prescribed drives (Media) due to the drive that is not mounted
cannot be accessed (drives units are ghost, assigned their
ID's but not allowed to mount when the logged on user is not
allowed access to it). The drive will appear on a manager
to be hazed out to indicate that it is dismounted...
This would be more secure than the current use of scripts or
manual commands as the code would be securely in the in the
driver code. The drive, if possible can also be set to
prevent the insertion of media or the removal of said media
(some drives can - at least in their Win doze version - when
trying to eject and active disk prompt the user and the user
select the ignore option thus preventing the ejection from
taking place) if possible. Will have to contact drive
suppliers to find out if possible...
2. Integrity :
This prevents the mistaken removal of media without
dismounting first in the event the manual eject is pressed.
=09
This also allows for quick change of media for tape or
cd jukeboxes with just a click of the drive icon or cd prompt
change...
3. Access (see security)
The driver would detect the eject command (from the button being
pressed - much like current adaptec DirectCD does on my CD-RW drive)
and triggers a detection to check it the media is active
Active - either of the following
a: cancels dismount
b: waits for activity to end - dismounts
c: halts activity - dismounts
d: prompts for action
non Active - dismounts media
This is for media that does not use a mechanical ejection (Floppy
(1.44) but uses and articulated ejection (electrical as in CD's, Zip,
Jazz). Including hot-swapable HD's using swap trays (caddies).
There is more ways this could be used, but my brain is falling off and
I cannot think anymore so I will leave it with the above in hopes
another can add their own..
I most likely will not be able to contribute much as I have trouble
even spelling the word programming much less doing it (still learning
at beginning level)..
Any constructive comments??????
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
rwa...@freebsd.org
You can imagine the decisions and resulting activities, in the case of
removable media, being made in a userland daemon listening for device
events. I guess the pertinent question then is, what is the best way in
which to deliver this sort of event information to userland processes? To
what extent can this event stream be abstracted so as to not represent
driver-specific events ("cdrom device (whatever) was ejected" in a cdrom
schema as opposed to something acd-specific), and should it be extensible
to allow the representing of driver-specific events. Polling for
device availability in userland seems like a less pretty solution.
Right now, devices in /devfs appear based on whether or not the drive is
available, not media. I wonder if there would be an appropriate way for
events to be notified via a combination of kqueue() and devfs nodes?
Robert N M Watson
rob...@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services