Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!

[Damir Perisa]

Le Wednesday 09 November 2005 21:56, Bill Davidsen a écrit :
 | There are, at minimum, three possible hardware attach cases, each of
 | which may be on a distribution which uses udev or not. I'm assuming
 | that if this is a udev problem is would be fixed at the udev level,
 | but your comment on "userspace hacks" does sound like fixes to
 | userspace bugs.
 
udev+hotplug interaction causing loops is only a bug, because the CF 
(ide-cs) is detected as removable, but it is not. (at least that's how i 
understand it) of course, one can start arguing, that such looping should 
be somehow inhibited by udev or hotplug and i'm not very much used to the 
procedures there that may have possibilities for such an inhibition for 
looping, but it sounds to me like fighting symptoms. curing the patient 
(sorry for this analogy) is in almost all cases better and this means 
here --- as long i understand it --- to have a proper handling of CF in 
the kernel, so that the userspace tools do not get the chance to mess 
with procedures. :P

redhat and a lot of other distributions have udev workaround lines in 
their udev.rules to hinder it looping, but in the end, this are only 
workarounds and not solid solutions. (assigning "no_volume_id" to 
something is not a really nice way)

 | The three attach methods are pcmcia, direct plugin slots (laptops only
 | AFAIK), and USB devices.
 
on the macroscopic scale, you are right. but as far i know (i'm no kernel 
coder), a USB-CF reader is identified as usb-storage device and the 
controler in the CF itself is not used by the kernel but by the reader 
itself. the kernel does not communicate with the CF card but with the 
reader and thinks of it as a removable device (where the CF is the 
medium). firewire-CF readers work in the same way using sbp2 driver 
instead of usb-storage. the kernel thinks, it addresses just another 
usb-storage or sbp2 device. 

i think that's also the reason, why my girlfriend's fw-CF reader is 
echo'ing this lines, if connected to the computer:
	sda: asking for cache data failed
	sda: assuming drive cache: write through
but that's another story...

the pcmcia attach method is different to the usb/fw-reader one. the CF is 
directly accessed by the kernel and its controler directly communicating 
with ide-cs. how this happens in detail, i don't know in detail, but the 
difference is that the controler is directly addressed by the kernel and 
is therefore the device. the media is in fact just the chips in the CF 
inside in this case. (whereas in usb/fw-reader, the "media" is the whole 
CF card) so in this case, you cannot remove the media if the CF is 
plugged into your pcmcia slot. (except if you are very good at hardware 
surgery and have money for new CF's ;)

so as summary:
there are at least four methods (usb reader, fw reader, direct slot, 
pcmcia-cf) -- or 2 basically different ones (indirect (reader=device 
cf=media) and direct (cf=device with media inside))

now i hope that i didn't make a mistake here, because i'm no expert; only 
longterm linux user with experience from 2.0-2.6 kernels. i try to use as 
little workarounds as possible, because cure is always better than 
fighting symptoms. :D

greetings,
Damir

-- 
Youth is when you blame all your troubles on your parents; maturity is
when you learn that everything is the fault of the younger generation.

Attachment: pgp00000.pgp
Description: PGP signature