[lkml]   [2006]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: patch [0/2]: acpi: add generic removable drive bay support
On Fri, Sep 08, 2006 at 01:21:23PM -0700, Kristen Carlson Accardi wrote:
> On Fri, 8 Sep 2006 20:58:42 +0100
> Matthew Garrett <> wrote:
> > Do we really want it under /proc? It would seem to make more sense for
> > it to be under /sys.
> I agree - this is under proc because this is an acpi driver, and the acpi
> subsystem is still using the /proc fs for driver/user space interface. I
> thought I would just conform to their standard.

Yeah, that's the current situation. I think pretty much everyone would
like to see it die off, though :)

> > What gets generated if I rip a drive out without notifying the system
> > beforehand? Dell hardware doesn't appear to send any event when poking
> > the eject lever.
> I tested the Dell M65 with this patch, and you are right - it does not
> send an event when you press the eject button, but rather when you do the
> actual remove. I sent a mail to their BIOS people informing them that we
> would find it helpful to have the eject request as well as the removal event,
> but, I am not holding my breath. The remove event seems to be "good enough",
> although I can definitely forsee issues.

Right. My prime concern in this case is that userspace ends up seeing
the drive for a significant period of time despite it having been

> This is the way I was planning on doing it too - and I'd like to do that
> for SATA - unfortunately, a lot of the removable drives are actually
> PATA, and until hotplug support for this gets integrated into libata,
> as a workaround we have to tell userspace to try to unmount the filesystem
> first, otherwise the whole system locks up. Even new laptops such as the
> Lenovo X60 have IDE bays on them.

Really? Ouch. I did hack up some vague support for pata hotswap some
time ago, but dropped it when I realised that there wasn't a terribly
easy way to remove a single device in drivers/ide. Removing an entire
bus isn't helpful when your test machine has the hard drive and CD drive
on the same channel.

> So what are the firmware hooks that you speak of? I would love to have
> this represented under the appropriate scsi layer (assuming SATA) if
> possible - it seems more natural to me also.

The idea was to add something to init_scsi in drivers/scsi/scsi.c along
the lines of scsi_platform_register(). On most platforms this would be a
noop, but on ACPI systems it would do something like pci_acpi_init does
in drivers/pci/pci-acpi.c. That way when SCSI devices (including libata
ones) get registered, there's a callback into the scsi-acpi code which
can associate them with the appropriate ACPI address. When an event is
received that can then be handled by the scsi-acpi code, which has the
corresponding SCSI device structure and can call the relevant hotplug

The added advantage of this is that it would allow fairly clean
integration of the ACPI suspend/resume methods for PATA and SATA
devices, plus any further information that ever gets exposed via ACPI. is the relevant part of the
discussion, though the patch appears somewhere earlier in the thread. As
Jeff mentions the SCSI layer may not be the ideal place to do this,
though I haven't checked whether it's straightforward to do it in libata
itself yet. Even if not, it wouldn't be hard to swap the code over when

Matthew Garrett |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-08 22:49    [W:0.047 / U:5.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site