linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>, Mark Lord <liml@rtr.ca>,
	LKML <linux-kernel@vger.kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	bzolnier@gmail.com, linux-ide@vger.kernel.org
Subject: Re: [RFC/BUG?] ide_cs's removable status
Date: Thu, 22 Sep 2005 15:21:16 +0100	[thread overview]
Message-ID: <1127398876.8242.74.camel@localhost.localdomain> (raw)
In-Reply-To: <1127396382.18840.79.camel@localhost.localdomain>

Lets try a different way of illustrating the problem. We'll hopefully
all agree that my ide CDROM drive is a removable device.

When my system boots, it creates a /dev/hdd entry for the cdrom. When I
insert a disk and mount it, udev doesn't touch the device node as its
already there and ready to go. If the media changes, this is detected
and the same device node is used to present the new data.

/dev/hdd *always* exists and may or may not have media present.

When I boot a system with an empty PCMCIA slot, no ide device exists.
ide-cs knows nothing about the PCMCIA slot and therefore no device nodes
exist. When you insert the CF card, PCMCIA realises its an ide device,
tells ide-cs which creates the appropriate devices through the ide
layer. When the card is removed, the devices and controller are removed.

The /dev/* entries only exist when the ide controller is present. There
is no state where the controller is present with no media.

Under Linux, removable is defined to mean the device can exist with no
media. That is clearly not the case for CF and therefore it shouldn't be
marked as such. 

If it were removable, ide-cs should be informed of every card slot in
the system and should create ide controllers for each of them whether
they have cards in or not. We could then correctly check for media
changes. Yes, this would be ridiculous but it illustrates that CF cards
should not have the removable flag set.


There are other bugs which this issue is getting confused with. In
summary, I see the following separate issues:

1. Are ide-cs devices removable or not. See above.
2. The following loop exists for removable devices:

Device node is created (by udev).
An attempt to mount the device results in a media change check.
The media change check defaults to media changed.
The device node is removed and recreated (by udev).

Technically, the device node you mounted is now invalid and has changed
so you should remount it. You then have a loop.

This can be solved by having the media change check look at serial
numbers as mentioned by Alan in a previous email.

3. ide-cs sometimes can't/doesn't detect the removal of an ide
controller.

Using media_change events to see if the controller has changed/been
unplugged is incorrect. 


Each of the above are separate bugs. I'm trying to fix one of them (and
might try and work on the others if I can).

Richard



  parent reply	other threads:[~2005-09-22 14:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 16:15 [RFC/BUG?] ide_cs's removable status Richard Purdie
2005-09-21 16:57 ` Alan Cox
2005-09-21 17:21   ` Mark Lord
2005-09-21 18:27     ` Alan Cox
2005-09-21 18:46       ` Richard Purdie
2005-09-22  0:18         ` Alan Cox
2002-01-01  5:18           ` Pavel Machek
2005-09-21 19:29       ` Russell King
2005-09-21 21:52         ` Richard Purdie
2005-09-22  0:06           ` Alan Cox
2005-09-22  0:10         ` Alan Cox
2005-09-22 10:22           ` Russell King
2005-09-22 13:39             ` Alan Cox
2005-09-22 13:29               ` Russell King
2005-09-22 14:41                 ` Alan Cox
2005-09-22 14:21               ` Richard Purdie [this message]
2005-09-22 14:36                 ` Russell King
2005-09-22 15:08                 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1127398876.8242.74.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bzolnier@gmail.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).