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 <mjg59@xxxxxxxxxxxxx> 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 removed. > 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 code. 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. http://lkml.org/lkml/2005/12/8/152 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 necessary. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
