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:
pgpmetaofSdXS.pgp
Description: PGP signature
- References:
- Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!
- From: Richard Purdie <[email protected]>
- Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!
- From: Bill Davidsen <[email protected]>
- Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!
- Prev by Date: Need test: 2.6.14: Fix IRQ race in USB sleep/wakeup code]
- Next by Date: [PATCH 3/4] relayfs: make exported relay fileops useful
- Previous by thread: Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!
- Next by thread: Re: [patch] Re: 2.6.14-rc5-mm1 - ide-cs broken!
- Index(es):