[lkml]   [2000]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Of removable devices
In <> David Balazic ( wrote:
DB> Khimenko Victor wrote :

>> In <> Alan Cox ( wrote:
>> >> Eh? If one wants to pull the mounted device in the middle of write and
>> >> expects his data alive and well after that - well, he _is_ idiot. If you
>> >> want political correctness - please: comprehension-challenged. Better?
>> > End users don't always get it. They often aren't computing people. If they
>> > turn off the TV or pull the plug out of the wall the TV doesnt break.
>> If will switch gear on full speed improperly (without pressing "unmount"
>> button by foot :-) you'll need to repair you car in no time. On most current
>> cars there are automatic gear. PC does not have automatic gear for floppies
>> yet. Is this explanation too complex for "non-computing people" ?
>> > You need to think outside the computing mindset - not even neccessarily
>> > into brightness either - someone can be very bright and utterly incapable of
>> > relating to computers.
>> Can he/she drive ?
>> > At the same time - the fix is hardware, the PC isnt fixable for this the
>> > CD-ROM drives are. The 2.2.x supermount stuff does that bit right
>> Exactly. As far as there are no automatic gear for floppies you can not
>> avoid manual unmount if you want reliable work.

DB> But you CAN ,as at least AmigaOS proves.

Of course you can. You'll need "just" DEEP rework of VFS as was discussed in
depth here. And still it's not a panacea: if you'll pull floppy EXACTLY when
write/read process going you can just mechanically break floppy drive (just
like plugging/unplugging SCSI or IDE device: probability is of the same order).

DB> If you didn't understand it at first, I'll repeat it :

I repeat as well: It should be done right or not at all.

>> P.S. BTW ZIP drive HAS needed knobs in place: when I press "Eject" button in
>> Windows I get message ON SCREEN "You are trying to eject disk while it's in
>> use. Ok, Cancel ?" (translation from Russian). If I press Ok disk is ejected,
>> if press Cancel disk will not be ejected. So at least for ZIP drive you can
>> implement proper supermount (with small change in kernel and autofs) --
>> hardware supports it.

DB> <teasing>
DB> But who gets the dialog ? Which user ? And if nobody is logged in ?
DB> </teasing>

Why I need dialog ? In case of linux pressing of eject button can iniciate
umount process and then eject. If umount failed I'll not get my zip drive
and will find and kill offending process.

DB> I answered ( in short ) these questions in my other post.
DB> Anyone using common-sense can answer them , so I will not repeat it
DB> here.

And you answer is bad. Here owner of /dev/fd0 is always "root,floppy".
Root is VERY rarely loggin in. All trusted users are in "floppy" group.
Now: who should get message about wrongly removed floppy ?

P.S. Do not answer: I know that right way is to say daemon somehow that
"messages about /dev/ide/host0/bus1/target1/lun0/* should go to /dev/console
while messages about /dev/scsi/host0/bus1/target7/lun0/* should go to
blah.blah.blah:0.0" or something. That is: you need LOTS of changes in
kernel AND you need ifrastructure in user-space. Is it reallyworth it ?
God knows. So far I'm see hackish solutions which will punish user when
user doing mistakes. Not a way to go IMNSHO. If someone REALLY want this
behaviour he should sit and code prototype of all infrastructure. Complete
with changes in kernel, daemon is userspace and so on.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.040 / U:0.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site