In article <linux.kernel.m3itzmbbtb.fsf@toy.mandrakesoft.com>,
Francis GALIEGUE <francis@mandrakesoft.com> wrote:
>David Balazic <david.balazic@uni-mb.si> writes:
>
>> >
>> > And who gets the notice if no one is there? or no one is logged in?
>>
>[skipped sarcasm]
>>
>> The one that ejected the medium , obviously.
>> echo "Put that back in , son !" > /dev/console
>>
>> satisfied ?
>>
>
>No. The sole role of the kernel in case of broken hardware
>(hence, floppies) is to ensure data integrity, not to tell the user
>"please insert floppy #adead007". Easing removable media manipulation
>would sure be a great plus (for users), but not to the expense of
>unneeded and unnecessary tell-user-what-to-do stuff.
Only if it's done incorrectly. If there's glue to put a notifier
in, then all the kernel has to do when it attempts to write out data
to a device that's not there anymore is tickle the notifier, then
defer the writes 'til the next time sync rolls around. No notifier
== data is written to the afterlife with the traditional vomiting of
error messages to syslog, the console, or whereever.
>And even if user space notification and report were implemented and
>functional, a user in a hurry is a user in a hurry and would be far
>away from the culprit machine
That would be a badly implemented userland. I couldn't imagine
mounting anything async with a notifier, for then the machine that's
not running update won't notice that the floppy's gone for several
weeks.
A sick notifier could be a simple shellscript, called by mount:
#! /bin/sh
DEV=$1
MAJOR=$2
MINOR=$3
mknod /dev/$DEV.tickle $MAJOR $MINOR
trap 0 1 2 3 9 15 "rm -f /dev/$DEV.tickle"
while read tickle; do
dialog --msgbox --wait 5 "Please put $DEV back"
sync $DEV
done < /dev/$DEV.notify
exit 0
with fstab being something like
/dev/ide0/drive0 /zip removable,notifier,user,noauto 0 0
____
david parsons \bi/ A more sophisticated tickler is left as an exercise
\/ for the reader.
-
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:23 EST