A minor problem w/ access to my flash drive

[David Zeuthen]

On Mon, 2005-01-24 at 22:48 +0600, Alexey Morozov wrote:
> >It shouldn't blink when it's mounted.
>
> No, it keeps /shining/ even after mount. Another flash I've tried 
> recently (probably a bit more modern?) blinks every two seconds or about 
> (haven't tried to mount it).

Well, the first law states that all hardware is fundamentally
broken; some are more broken than other - does it work, btw?

> >>but I never heard that a devices could be unplugged w/o proper 
> >>notification...
> >>    
> >>
> >USB device removal != media removal;
> >
> For my good old flash drive? I guess you're kidding ;-)

I too have a CF reader that disconnects when you remove the media;
that's just an oddity of the hardware; I guess it's even allowed.
I have other readers that doesn't. So we have to poll.

<snip>

> But the problem he discusse(d,s) is a bit different from my one. I don't 
> speak about every hotpluggable 'seen-as-SCSI' device on Earth. My need 
> is rather humble and small ;-). And this need doesn't require media 
> poll, just because media == device (for which we do have exact 
> notifications).

Sure, in that case it's not necessary to poll the device at all
so I guess an .fdi file like the one Pozsar wrote could be shipped
with HAL - do you have one handy for your device? We need such
.fdi files because we cannot infer this directly from the hardware
AFAIK.

> BTW the current kernel behaviour for devices like those being discussed 
> in that thread is far from ideal. I was reported a bug (initially on 
> udev, but later it was moved to hotplug bugs) about ide-cs deficiency: 
> every access to the device working via ide-cs causes immediate remove 
> and add hotplug events what effectively causes computer freeze when 
> using [advanced] hotplug or udev scripts to determine device properties.
> 

Oh yeah; the inifinite loops of hotplug events; note that HAL does
handle those devices somewhat nicely - it will get even better with
the new code I'm refactoring on HEAD.

<snip>

> >You have to unmount, sorry, it's unsafe to just removing the device
> >backing a mounted file system. While HAL can cope this with (as far  
>
> Well, you know, I'm familiar w/ all these 'magic unix spells' for a 
> well, long enough time ;-). I even remember those broken FreeBSD kernel 
> releases which paniced (not sure I spelled it correctly ;-)) after one 
> pulled out a mounted diskette. But actually last, well, ~3-4 years linux 
> removable devices 'do things right' for me, and this is quite handy :-).
> 

Sure, but there is still potential data loss. The UI interaction
designers at Red Hat I've spoken with also suggests not to pester
the user with modal dialogs - some day we can use the notification
bubbles for this; maybe..

> >Help fix the programs keeping open fd's on a file system instead.  
>
> Sure? I guess it will be the fight against windmills. Some of them (like 
> Midnight Commander or other file managers) simply keep open handles on 
> directories being accessed or files being viewed. I doubt I should 'fix' 
> them :-). What would be more useful is wide FAM adoption but actually 
> it's a too long and boring road to run on :-)

Well, FAM itself is pretty evil from a security point of view. Gamin
(which btw is a drop-in replacement for libfam) almost gets it right
with it's hybrid use of techniques to discover file changes (polling,
DNOTIFY) - it really requires stuff like inotify to do it perfectly
though. And some programs are just broken beyond repair, but, hey,
no one is forcing you to use broken programs :-)

David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal