Linux ATA/IDE development
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Cc: Suresh Grandhi <Sureshg@ami.com>,
	"'linux-ide@vger.kernel.org'" <linux-ide@vger.kernel.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: IDE Hotswap
Date: Wed, 29 Sep 2004 15:35:17 +0100	[thread overview]
Message-ID: <1096468515.15905.43.camel@localhost.localdomain> (raw)
In-Reply-To: <200409291408.55211.bzolnier@elka.pw.edu.pl>

On Mer, 2004-09-29 at 13:08, Bartlomiej Zolnierkiewicz wrote:
> > Even in 2.4 ide drive hotplug was easy. The drive hotplug comes out
> > trivially because your controllers are fairly constant. As we all know
> > driver level hotplug is a bit trickier although the block layer has
> > really made this vastly easier in 2.6
> > 
> > For drive level hotplug you don't actually need refcounting at all
> > providing you've got a couple of locking issues dealt with.
> 
> These issues can't be solved without refcounting.

So you keep saying, but you refcount objects that are going away, you
don't need to refcount objects that are staying put.

> Feel free to probe me wrong, you can start with fixing
> ->open vs unregister race (drive->usage involved). :)

Doesn't occur in the 2.4 situation or the 2.6 stuff with the locking in
the 2.6.8.1-ac patch.

> > Firstly the drive never goes away as a high level object (in fact you
> > don't want it to as then you can't ioctl it to make it come back!). That
> > means the upper layers don't know anything about it.
> 
> ioctls on not present devices are layering VIOLATION

Oh dear then I guess most of Linux is misdesigned. You aren't thinking
about the semantics at all. 

If /dev/hda is a CD-ROM drive I can issue commands to it with no CD 
present. Thats not a layering violation, and its how the IDE code works.
So whats the difference between hotplugging a drive and removing
a CD. Both are removing the media but leaving the controller behind.

On that item I think you are talking out of your backside.

> > At the IDE layer the 2.4 code simply enforced the rule that you must be
> > the only opener of the device in order to hot unplug it. That means we
> 
> "enforced" - there are a couple of races, sorry but ROTFL
> 
> > know its quiescent and not mounted. The only 2.4 race I know about is
> 
> - double unlock obvious mistake
Details ?
> - ->open() vs unregister
unregister is hot plug controller not drive and thats unfixable in 2.4
> - /proc races (the same you fixed in your 2.6 patch)
yeah that lot postdates the 2.4 work. hotplug drives is not the cause
however.
> - ioctl races
Details ?

> gendisk layer and block layer enforces you to make /dev/hda disappear.

No it does not. The block layer couldn't give a flying **** whether
/dev/hda disappears or not. SCSI devices that are offlined don't need to
disappear either you just hand back commands with an error. You know -
like every CD-ROM does...

> Does sysfs ring any bells?  Ask viro about static objects vs sysfs.
> And yes not only gendisk and block enforces this, Patrick added basic,
> premature sysfs support to IDE driver in the middle of 2.5 series.
> 
> We can get back to discussion when you get familiar with issues involved.

Ditto...

Alan


  reply	other threads:[~2004-09-29 15:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8CCBDD5583C50E4196F012E79439B45C069657DB@atl-ms1.megatrends.com>
2004-09-28 21:38 ` IDE Hotswap Bartlomiej Zolnierkiewicz
2004-09-28 21:45   ` Alan Cox
2004-09-29  1:54     ` Bartlomiej Zolnierkiewicz
2004-09-29  1:50       ` Alan Cox
2004-09-29 12:08         ` Bartlomiej Zolnierkiewicz
2004-09-29 14:35           ` Alan Cox [this message]
2004-09-29 18:20             ` Bartlomiej Zolnierkiewicz
2004-09-29 17:46               ` 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=1096468515.15905.43.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=Sureshg@ami.com \
    --cc=bzolnier@elka.pw.edu.pl \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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