Re: CONFIG_IBM_BAY

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Thu, 15 Mar 2007 16:31:24 -0300
Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
> > I think we should focus our efforts on a generic (non platform specific) 
> > solution that can work across many laptops (i.e. ACPI_BAY).  Let's make
> 
> Agreed, as long as that doesn't mean we have to pollute ACPI_BAY with a
> truckload of crap required to deal with vendor/model-specific idioticities.
> I hope ThinkPads are not like that, but I am not sure, and I'd feel bad
> about adding a lot of quirks to ACPI_BAY because of ThinkPad weirdness :p

So for the dock driver I supplied an interface to allow interested subsystems
to register handlers to be called by the dock driver during dock events.
This allowed me to let individual subsystems do whatever unique things they
needed to do when the dock was either inserted or removed.  For the bay
driver, we could actually provide a mechanism to allow platform specific
drivers to take advantage of the generic stuff, but then have the bay driver
call a registered handler to do some weird specific thing - this way at
least we are sharing the bulk of our code and weird stuff can be contained
somewhere else.

> 
> Otherwise, it would be best to allow model-specific modules to provide extra
> functionality for ACPI_BAY, that way we have generic code, and we can
> contain the braindamage to where it belongs (e.g. in ibm-acpi).
> 
> > so if you do have time to work on this, that would be great.  I am happy 
> > to test on the set of laptops I've got.
> 
> I will see what I can do.  My "first approach" at a requirements list for a
> proper bay module are as follows:
> 
> 1. It will handle all device types (ATAPI, PATA, SATA, batteries);
> 
> 2. It will do the right thing on plug and unplug.  This means telling the
> rest of the kernel to disable the device in the bay, for example.  Right now
> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and
> leave libata to scream blood murder until it disables its end due to too
> many retries, for example;

Personally - I think tighter integration to libata here would be beneficial.
Once libata acpi support is straightened out, if we can store acpi handles
associated with libata devices, we can perhaps have a mechanism of obtaining
ata_device structs so that we can have a nice way of telling libata to 
delete devices etc.  I am hoping libata-acpi will be straightened out for
2.6.22.

Re: CONFIG_IBM_BAY

[Tejun Heo]

Hello,

Kristen Carlson Accardi wrote:
>> 1. It will handle all device types (ATAPI, PATA, SATA, batteries);
>>
>> 2. It will do the right thing on plug and unplug.  This means telling the
>> rest of the kernel to disable the device in the bay, for example.  Right now
>> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and
>> leave libata to scream blood murder until it disables its end due to too
>> many retries, for example;

:-)

> Personally - I think tighter integration to libata here would be beneficial.
> Once libata acpi support is straightened out, if we can store acpi handles
> associated with libata devices, we can perhaps have a mechanism of obtaining
> ata_device structs so that we can have a nice way of telling libata to 
> delete devices etc.  I am hoping libata-acpi will be straightened out for
> 2.6.22.

I dunno what the thread is really about but can't this be dealt within
acpid?  Finding out the correct scsi host node can be tricky but I think
it can be done reliably by jumping through some sysfs whoops.  Once
you're there, telling libata to kill or probe is really easy.

  http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices

Thanks.

-- 
tejun

Re: CONFIG_IBM_BAY

[Holger Macht]

On Sun 18. Mar - 14:38:42, Tejun Heo wrote:
> Hello,
> 
> Kristen Carlson Accardi wrote:
> >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries);
> >>
> >> 2. It will do the right thing on plug and unplug.  This means telling the
> >> rest of the kernel to disable the device in the bay, for example.  Right now
> >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and
> >> leave libata to scream blood murder until it disables its end due to too
> >> many retries, for example;
> 
> :-)
> 
> > Personally - I think tighter integration to libata here would be beneficial.
> > Once libata acpi support is straightened out, if we can store acpi handles
> > associated with libata devices, we can perhaps have a mechanism of obtaining
> > ata_device structs so that we can have a nice way of telling libata to 
> > delete devices etc.  I am hoping libata-acpi will be straightened out for
> > 2.6.22.
> 
> I dunno what the thread is really about but can't this be dealt within
> acpid?  Finding out the correct scsi host node can be tricky but I think
> it can be done reliably by jumping through some sysfs whoops.  Once
> you're there, telling libata to kill or probe is really easy.

That's actually what I've created dockutils [1] for. What it basically
does is 'echo 1 > /sys/devices/.../delete' on undock, and 'echo "- - -" >
/sys/class/scsi_host/*/scan' on dock to get the bay device back to life on
those ThinkPads where it is needed. Afterwards it does the corresponding
dock/undock request on ibm_acpi. And this works reliably good what I can
see from the feedback I already got. But for this to work, userspace would
actually need an event on docking and preferably would need to do the ACPI
undock itself. Both things are not possible with the generic dock driver
currently. And I don't think it matters much if libata's hotplug
capabilities are improved in this case, userspace just needs some time to
interact with the user in case there is more to do like unmounting
filesystems inside the bay etc...

I don't prefer any solution, whether doing it inside the kernel, or doing
it in userspace. What would be good would be to know what's the 'right'
way to go, or at least what both kernel people and userspace people can
agree on so that we can find a solution across distributions, whatever.
I'm currently just looking how to integrate the generic dock and bay
driver into the openSUSE distribution, and this seems to be quite hard,
especially because of the above mentioned already working solution ;-)

Just my 2 cents,
     Holger

[1] http://en.opensuse.org/Dockutils

Re: CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Sun, 18 Mar 2007, Holger Macht wrote:
> those ThinkPads where it is needed. Afterwards it does the corresponding
> dock/undock request on ibm_acpi. And this works reliably good what I can
> see from the feedback I already got. But for this to work, userspace would

It should work with the generic bay device too, but I have no ideas about
dock.  But you'll need to deal with udev with the new bay device, something
I am not too happy about.  These things are ACPI events, they should remain
so unless all other ACPI events are going to become uevents.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Holger Macht]

On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> On Sun, 18 Mar 2007, Holger Macht wrote:
> > those ThinkPads where it is needed. Afterwards it does the corresponding
> > dock/undock request on ibm_acpi. And this works reliably good what I can
> > see from the feedback I already got. But for this to work, userspace would
> 
> It should work with the generic bay device too, but I have no ideas about
> dock.  But you'll need to deal with udev with the new bay device, something
> I am not too happy about.  These things are ACPI events, they should remain
> so unless all other ACPI events are going to become uevents.

It doesn't work, I've already tried. The bay driver only emits an event if
you really try to remove the bay, but not on docking/undocking.

Regards,
	Holger

Re: CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Sun, 18 Mar 2007, Holger Macht wrote:
> It doesn't work, I've already tried. The bay driver only emits an event if
> you really try to remove the bay, but not on docking/undocking.

Ah, now I understand what you mean.

Looks like we really need the dock driver to sort of like act as a bus.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Sun, 18 Mar 2007 19:55:30 +0100
Holger Macht <hmacht@suse.de> wrote:

> On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > see from the feedback I already got. But for this to work, userspace would
> > 
> > It should work with the generic bay device too, but I have no ideas about
> > dock.  But you'll need to deal with udev with the new bay device, something
> > I am not too happy about.  These things are ACPI events, they should remain
> > so unless all other ACPI events are going to become uevents.
> 
> It doesn't work, I've already tried. The bay driver only emits an event if
> you really try to remove the bay, but not on docking/undocking.
> 
> Regards,
> 	Holger
> 

this *should* work.  The Bay driver registers with the dock driver to get
dock events:

        /* if we are on a dock station, we should register for dock
         * notifications.
         */
        if (bay_is_dock_device(handle)) {
                bay_dprintk(handle, "Is dependent on dock\n");
                register_hotplug_dock_device(handle, bay_notify, new_bay);
        }
 

then, on undock the dock driver calls the bay_notify function and passes
it the EJECT request event.  This causes the bay driver to emit an event to
userspace.

        case ACPI_NOTIFY_EJECT_REQUEST:
                kobject_uevent(&dev->kobj, KOBJ_CHANGE);
                break;
        default:
 

an event to userspace.

Re: CONFIG_IBM_BAY

[Holger Macht]

On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> On Sun, 18 Mar 2007 19:55:30 +0100
> Holger Macht <hmacht@suse.de> wrote:
> 
> > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > > see from the feedback I already got. But for this to work, userspace would
> > > 
> > > It should work with the generic bay device too, but I have no ideas about
> > > dock.  But you'll need to deal with udev with the new bay device, something
> > > I am not too happy about.  These things are ACPI events, they should remain
> > > so unless all other ACPI events are going to become uevents.
> > 
> > It doesn't work, I've already tried. The bay driver only emits an event if
> > you really try to remove the bay, but not on docking/undocking.
> > 
> > Regards,
> > 	Holger
> > 
> 
> this *should* work.  The Bay driver registers with the dock driver to get
> dock events:
> 
>         /* if we are on a dock station, we should register for dock
>          * notifications.
>          */
>         if (bay_is_dock_device(handle)) {
>                 bay_dprintk(handle, "Is dependent on dock\n");
>                 register_hotplug_dock_device(handle, bay_notify, new_bay);
>         }
>  

But is_dock_device(...) for both the bay and for the parent handle return
false. I'm using an X60 here, so bay_notify is never registered. I
couldn't find the reason in the short time I was looking at it, though.

Regards,
	Holger

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Tue, 20 Mar 2007 16:53:21 +0100
Holger Macht <hmacht@suse.de> wrote:

> On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> > On Sun, 18 Mar 2007 19:55:30 +0100
> > Holger Macht <hmacht@suse.de> wrote:
> > 
> > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > > > see from the feedback I already got. But for this to work, userspace would
> > > > 
> > > > It should work with the generic bay device too, but I have no ideas about
> > > > dock.  But you'll need to deal with udev with the new bay device, something
> > > > I am not too happy about.  These things are ACPI events, they should remain
> > > > so unless all other ACPI events are going to become uevents.
> > > 
> > > It doesn't work, I've already tried. The bay driver only emits an event if
> > > you really try to remove the bay, but not on docking/undocking.
> > > 
> > > Regards,
> > > 	Holger
> > > 
> > 
> > this *should* work.  The Bay driver registers with the dock driver to get
> > dock events:
> > 
> >         /* if we are on a dock station, we should register for dock
> >          * notifications.
> >          */
> >         if (bay_is_dock_device(handle)) {
> >                 bay_dprintk(handle, "Is dependent on dock\n");
> >                 register_hotplug_dock_device(handle, bay_notify, new_bay);
> >         }
> >  
> 
> But is_dock_device(...) for both the bay and for the parent handle return
> false. I'm using an X60 here, so bay_notify is never registered. I
> couldn't find the reason in the short time I was looking at it, though.
> 
> Regards,
> 	Holger
> 

Works for me on my X60 - have you tested on the latest rc kernel?  Also,
let me know what your BIOS sets your SATA controller to.  I can try to 
duplicate your issue and get it to work.

Re: CONFIG_IBM_BAY

[Holger Macht]

On Tue 20. Mar - 09:19:32, Kristen Carlson Accardi wrote:
> On Tue, 20 Mar 2007 16:53:21 +0100
> Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote:
> 
> > On Mon 19. Mar - 11:04:12, Kristen Carlson Accardi wrote:
> > > On Sun, 18 Mar 2007 19:55:30 +0100
> > > Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote:
> > > 
> > > > On Sun 18. Mar - 15:36:52, Henrique de Moraes Holschuh wrote:
> > > > > On Sun, 18 Mar 2007, Holger Macht wrote:
> > > > > > those ThinkPads where it is needed. Afterwards it does the corresponding
> > > > > > dock/undock request on ibm_acpi. And this works reliably good what I can
> > > > > > see from the feedback I already got. But for this to work, userspace would
> > > > > 
> > > > > It should work with the generic bay device too, but I have no ideas about
> > > > > dock.  But you'll need to deal with udev with the new bay device, something
> > > > > I am not too happy about.  These things are ACPI events, they should remain
> > > > > so unless all other ACPI events are going to become uevents.
> > > > 
> > > > It doesn't work, I've already tried. The bay driver only emits an event if
> > > > you really try to remove the bay, but not on docking/undocking.
> > > > 
> > > > Regards,
> > > > 	Holger
> > > > 
> > > 
> > > this *should* work.  The Bay driver registers with the dock driver to get
> > > dock events:
> > > 
> > >         /* if we are on a dock station, we should register for dock
> > >          * notifications.
> > >          */
> > >         if (bay_is_dock_device(handle)) {
> > >                 bay_dprintk(handle, "Is dependent on dock\n");
> > >                 register_hotplug_dock_device(handle, bay_notify, new_bay);
> > >         }
> > >  
> > 
> > But is_dock_device(...) for both the bay and for the parent handle return
> > false. I'm using an X60 here, so bay_notify is never registered. I
> > couldn't find the reason in the short time I was looking at it, though.
> > 
> > Regards,
> > 	Holger
> > 
> 
> Works for me on my X60 - have you tested on the latest rc kernel?  Also,
> let me know what your BIOS sets your SATA controller to.  I can try to 
> duplicate your issue and get it to work.

Tried with Linus' git tree from today. SATA is set to AHCI if that's the
information you're asking for.

Thanks,
  Holger

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Sun, 18 Mar 2007 15:36:52 -0300
Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> On Sun, 18 Mar 2007, Holger Macht wrote:
> > those ThinkPads where it is needed. Afterwards it does the corresponding
> > dock/undock request on ibm_acpi. And this works reliably good what I can
> > see from the feedback I already got. But for this to work, userspace would
> 
> It should work with the generic bay device too, but I have no ideas about
> dock.  But you'll need to deal with udev with the new bay device, something
> I am not too happy about.  These things are ACPI events, they should remain
> so unless all other ACPI events are going to become uevents.

So ACPI is just a mechanism - an implementation detail in the kernel.  I
don't think we should have special ACPI events to deal with bay/dock activity.
If for whatever reason we ever dock something without using ACPI, we can
make this transparent to userspace.  

Re: CONFIG_IBM_BAY

[Matthew Garrett]

On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote:

> I don't prefer any solution, whether doing it inside the kernel, or doing
> it in userspace. What would be good would be to know what's the 'right'
> way to go, or at least what both kernel people and userspace people can
> agree on so that we can find a solution across distributions, whatever.
> I'm currently just looking how to integrate the generic dock and bay
> driver into the openSUSE distribution, and this seems to be quite hard,
> especially because of the above mentioned already working solution ;-)

If the kernel knows that a bay device has just been added or removed, it 
makes sense for the device removal to take place in the kernel rather 
than bouncing it out to userspace and then back into the kernel. Pulling 
out a cardbus card doesn't require us to run a userspace helper to 
detach the hardware.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: CONFIG_IBM_BAY

[Holger Macht]

On Mon 19. Mar - 13:22:43, Matthew Garrett wrote:
> On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote:
> 
> > I don't prefer any solution, whether doing it inside the kernel, or doing
> > it in userspace. What would be good would be to know what's the 'right'
> > way to go, or at least what both kernel people and userspace people can
> > agree on so that we can find a solution across distributions, whatever.
> > I'm currently just looking how to integrate the generic dock and bay
> > driver into the openSUSE distribution, and this seems to be quite hard,
> > especially because of the above mentioned already working solution ;-)
> 
> If the kernel knows that a bay device has just been added or removed, it 
> makes sense for the device removal to take place in the kernel rather 
> than bouncing it out to userspace and then back into the kernel. Pulling 
> out a cardbus card doesn't require us to run a userspace helper to 
> detach the hardware.

Yes, makes sense to me. So if this is the way to go, we would need two
things:

  1. libata integration into the bay driver
  2. The dock station driver has to inform the bay driver that an undock
     event took place, right?

But you still have to deal with mounted filesystems, no matter if it a
cardbus or a cdrom. Wouldn't we need something like 'save removal'
triggered from userspace like you maybe know from 'the other' operating
system?

Regards,
	Holger

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Matthew Garrett]

On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote:

>   1. libata integration into the bay driver

It actually makes sense to tie all PATA/SATA devices to their ACPI 
handles where appropriate - there's already code to do that in 
libata-acpi.c, but it would be nicer if it was integrated in the same 
way that PCI devices are.

>   2. The dock station driver has to inform the bay driver that an undock
>      event took place, right?

Yeah.

> But you still have to deal with mounted filesystems, no matter if it a
> cardbus or a cdrom. Wouldn't we need something like 'save removal'
> triggered from userspace like you maybe know from 'the other' operating
> system?

Yes, there's a need for a mechanism to deal with all of this safely, but 
the same is true of any storage device that can be hotplugged (USB, 
firewire, anything in a hotplug bay...)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: CONFIG_IBM_BAY

[Holger Macht]

On Mon 19. Mar - 14:04:03, Matthew Garrett wrote:
> On Mon, Mar 19, 2007 at 02:48:22PM +0100, Holger Macht wrote:
> 
> >   1. libata integration into the bay driver
> 
> It actually makes sense to tie all PATA/SATA devices to their ACPI 
> handles where appropriate - there's already code to do that in 
> libata-acpi.c, but it would be nicer if it was integrated in the same 
> way that PCI devices are.
> 
> >   2. The dock station driver has to inform the bay driver that an undock
> >      event took place, right?
> 
> Yeah.
> 
> > But you still have to deal with mounted filesystems, no matter if it a
> > cardbus or a cdrom. Wouldn't we need something like 'save removal'
> > triggered from userspace like you maybe know from 'the other' operating
> > system?
> 
> Yes, there's a need for a mechanism to deal with all of this safely, but 
> the same is true of any storage device that can be hotplugged (USB, 
> firewire, anything in a hotplug bay...)

Sure. What actually bothers me is that in its current state, the dock
station driver signals 'green' on the dock station as soon as the user
presses the hardware undock button, but regardlessly of anything else. I
think it would be ok to let the ACPI undock event up to userspace because
in many situations it knows best when it is save to undock.

Regards,
	Holger

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Mon, 19 Mar 2007 15:37:46 +0100
Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote:

> Sure. What actually bothers me is that in its current state, the dock
> station driver signals 'green' on the dock station as soon as the user
> presses the hardware undock button, but regardlessly of anything else. I
> think it would be ok to let the ACPI undock event up to userspace because
> in many situations it knows best when it is save to undock.

I disagree - as I mentioned, not all laptops actually let you (userspace)
control the undock process because they don't lock.  The dock driver
does notify user space of an undock, before it actually undocks:

        /*
         * here we need to generate the undock
         * event prior to actually doing the undock
         * so that the device struct still exists.
         */
        dock_event(ds, event, UNDOCK_EVENT);
        hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST);
        undock(ds);
        eject_dock(ds);
 

We even notify other subsystems of our intent to undock prior to actually
doing it.  

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Holger Macht]

On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote:
> On Mon, 19 Mar 2007 15:37:46 +0100
> Holger Macht <hmacht@suse.de> wrote:
> 
> > Sure. What actually bothers me is that in its current state, the dock
> > station driver signals 'green' on the dock station as soon as the user
> > presses the hardware undock button, but regardlessly of anything else. I
> > think it would be ok to let the ACPI undock event up to userspace because
> > in many situations it knows best when it is save to undock.
> 
> I disagree - as I mentioned, not all laptops actually let you (userspace)
> control the undock process because they don't lock.  The dock driver
> does notify user space of an undock, before it actually undocks:

Yes, I know that, but userspace won't have enough time to interact with
the user in this case. I just imagine having an external disk connected to
the usb port of the docking station. In the moment the user undocks, his
unsynced or unwritten data is lost because the usb port gets
disconnected. The user needs the knowledge to actually "save remove" the
external disk before he undocks. You are right, this won't help in case
the dock station has no indication when it is "safe" to undock. 

> 
>         /*
>          * here we need to generate the undock
>          * event prior to actually doing the undock
>          * so that the device struct still exists.
>          */
>         dock_event(ds, event, UNDOCK_EVENT);
>         hotplug_dock_devices(ds, ACPI_NOTIFY_EJECT_REQUEST);
>         undock(ds);
>         eject_dock(ds);
>  
> 
> We even notify other subsystems of our intent to undock prior to actually
> doing it.  

Re: CONFIG_IBM_BAY

[Holger Macht]

On Tue 20. Mar - 17:07:07, Holger Macht wrote:
> On Mon 19. Mar - 11:11:09, Kristen Carlson Accardi wrote:
> > On Mon, 19 Mar 2007 15:37:46 +0100
> > Holger Macht <hmacht-l3A5Bk7waGM@public.gmane.org> wrote:
> > 
> > > Sure. What actually bothers me is that in its current state, the dock
> > > station driver signals 'green' on the dock station as soon as the user
> > > presses the hardware undock button, but regardlessly of anything else. I
> > > think it would be ok to let the ACPI undock event up to userspace because
> > > in many situations it knows best when it is save to undock.
> > 
> > I disagree - as I mentioned, not all laptops actually let you (userspace)
> > control the undock process because they don't lock.  The dock driver
> > does notify user space of an undock, before it actually undocks:
> 
> Yes, I know that, but userspace won't have enough time to interact with
> the user in this case. I just imagine having an external disk connected to
> the usb port of the docking station. In the moment the user undocks, his
> unsynced or unwritten data is lost because the usb port gets
> disconnected. The user needs the knowledge to actually "save remove" the
> external disk before he undocks. You are right, this won't help in case
> the dock station has no indication when it is "safe" to undock. 

This mail was accidentially sent a little bit too early ;-)

What I wanted to add is just that with letting it up to userspace, it
would also work in all cases, with or without lock, it would just give
userspace more possibilities and might be more convenient for those
systems where the dock station locks the machine. But I clearly see the
advantage of not needing a userspace helper and for getting this docking
thing to work in 99% of all cases ;-)

Regards,
	Holger

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Mon, 19 Mar 2007, Matthew Garrett wrote:
> > But you still have to deal with mounted filesystems, no matter if it a
> > cardbus or a cdrom. Wouldn't we need something like 'save removal'
> > triggered from userspace like you maybe know from 'the other' operating
> > system?
> 
> Yes, there's a need for a mechanism to deal with all of this safely, but 
> the same is true of any storage device that can be hotplugged (USB, 
> firewire, anything in a hotplug bay...)

True.  The best available procedure to do this for ACPI bay/dock currently
is, AFAIK:

1. Send event when bay/dock "please release" button/lever is pressed. Do
*nothing* else.  I know bay does this right, maybe dock doesn't.

2. Wait for something to echo 1 >eject or to call the appropriate routine
directly, or (if this exists) for an notification from firmware that the
user IS disconnecting the device for real.

3. delete the device.  This means force-umount, force-close, etc.

4. Tell the hardware to eject.


Note that currently (2) and (3) are swapped, as (3) is being done by
userspace request, instead of by the kernel.  This is something I *don't*
like.  IMO should do as PCMCIA and hotplug PCI does, and do that in kernel
space.

The time window where one can ask the user something or notify it is not a
good idea to eject is between (1) and (2).  If the eject command is issued,
delete devices (includes sync, of course) and eject.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Holger Macht]

On Mon 19. Mar - 12:36:59, Henrique de Moraes Holschuh wrote:
> On Mon, 19 Mar 2007, Matthew Garrett wrote:
> > > But you still have to deal with mounted filesystems, no matter if it a
> > > cardbus or a cdrom. Wouldn't we need something like 'save removal'
> > > triggered from userspace like you maybe know from 'the other' operating
> > > system?
> > 
> > Yes, there's a need for a mechanism to deal with all of this safely, but 
> > the same is true of any storage device that can be hotplugged (USB, 
> > firewire, anything in a hotplug bay...)
> 
> True.  The best available procedure to do this for ACPI bay/dock currently
> is, AFAIK:
> 
> 1. Send event when bay/dock "please release" button/lever is pressed. Do
> *nothing* else.  I know bay does this right, maybe dock doesn't.

Yes, the dock driver just does the undock, without any event.

As you know, the "please release" mechanism is how it works with
ibm_acpi. ACPI event comes through proc and userspace does echo undock >
....That would also be my favourite because it already works quite
well. Just without generic docking.

> 2. Wait for something to echo 1 >eject or to call the appropriate routine
> directly, or (if this exists) for an notification from firmware that the
> user IS disconnecting the device for real.
> 
> 3. delete the device.  This means force-umount, force-close, etc.
> 
> 4. Tell the hardware to eject.
> 
> 
> Note that currently (2) and (3) are swapped, as (3) is being done by
> userspace request, instead of by the kernel.  This is something I *don't*
> like.  IMO should do as PCMCIA and hotplug PCI does, and do that in kernel
> space.

Right.

> The time window where one can ask the user something or notify it is not a
> good idea to eject is between (1) and (2).  If the eject command is issued,
> delete devices (includes sync, of course) and eject.

Yes, at this point in time, userspace is required to have finished the
tasks it is responsible for.

Regards,
	Holger

Re: CONFIG_IBM_BAY

[Shem Multinymous]

On 3/19/07, Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@public.gmane.org> wrote:
> True.  The best available procedure to do this for ACPI bay/dock currently
> is, AFAIK:
>
> 1. Send event when bay/dock "please release" button/lever is pressed. Do
> *nothing* else.  I know bay does this right, maybe dock doesn't.
>
> 2. Wait for something to echo 1 >eject or to call the appropriate routine
> directly, or (if this exists) for an notification from firmware that the
> user IS disconnecting the device for real.
>
> 3. delete the device.  This means force-umount, force-close, etc.
>
> 4. Tell the hardware to eject.
>
>
> Note that currently (2) and (3) are swapped, as (3) is being done by
> userspace request, instead of by the kernel.  This is something I *don't*
> like.

Userspace wants to (non-force-)-unmount by itself after (1), so it can
stop  the eject process if the filesystems cannot be cleanly
unmounted. So the force-unmount at (3) ends up being a redundant
safety measure at best.

  Shem

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Mon, 19 Mar 2007, Shem Multinymous wrote:
> Userspace wants to (non-force-)-unmount by itself after (1), so it can
> stop  the eject process if the filesystems cannot be cleanly
> unmounted. So the force-unmount at (3) ends up being a redundant
> safety measure at best.

More like it is a "make sure we can actually eject, as we have been told
to".  We might return an error instead, but if we do, we need a way to
force-eject (e.g. echo 2 >eject).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [ibm-acpi-devel] CONFIG_IBM_BAY

[Shem Multinymous]

On 3/19/07, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> On Mon, 19 Mar 2007, Shem Multinymous wrote:
> > Userspace wants to (non-force-)-unmount by itself after (1), so it can
> > stop  the eject process if the filesystems cannot be cleanly
> > unmounted. So the force-unmount at (3) ends up being a redundant
> > safety measure at best.
>
> More like it is a "make sure we can actually eject, as we have been told
> to".  We might return an error instead, but if we do, we need a way to
> force-eject (e.g. echo 2 >eject).

Which stage are you referring to?

Note that the only way to check if you can unmount is to actually do
so. Otherwise, you're very likely to run into race conditions with
someone accessing the filesystem between  the check and the actual
unmount.

  Shem

Re: [ibm-acpi-devel] CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Tue, 20 Mar 2007, Shem Multinymous wrote:
> >More like it is a "make sure we can actually eject, as we have been told
> >to".  We might return an error instead, but if we do, we need a way to
> >force-eject (e.g. echo 2 >eject).
> 
> Which stage are you referring to?

Stage 2, of course.  It is useful to have a force_eject functionality that
**will** eject and not error out because of anything other than the eject
command itself failing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: CONFIG_IBM_BAY

[Kristen Carlson Accardi]

On Mon, 19 Mar 2007 13:22:43 +0000
Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> On Sun, Mar 18, 2007 at 09:27:51AM +0100, Holger Macht wrote:
> 
> > I don't prefer any solution, whether doing it inside the kernel, or doing
> > it in userspace. What would be good would be to know what's the 'right'
> > way to go, or at least what both kernel people and userspace people can
> > agree on so that we can find a solution across distributions, whatever.
> > I'm currently just looking how to integrate the generic dock and bay
> > driver into the openSUSE distribution, and this seems to be quite hard,
> > especially because of the above mentioned already working solution ;-)
> 
> If the kernel knows that a bay device has just been added or removed, it 
> makes sense for the device removal to take place in the kernel rather 
> than bouncing it out to userspace and then back into the kernel. Pulling 
> out a cardbus card doesn't require us to run a userspace helper to 
> detach the hardware.
> 
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org
> 

Not to mention, with dock stations some laptops don't actually lock the
laptop into the dock station, so when the user decides to press the button
and undock, it just does it instantly.  And same with some bay devices - 
they don't actually give you an event until the bay is physically removed.
Because of this, I think we should handle things in kernel space.

Re: CONFIG_IBM_BAY

[Henrique de Moraes Holschuh]

On Sun, 18 Mar 2007, Tejun Heo wrote:
> Kristen Carlson Accardi wrote:
> >> 1. It will handle all device types (ATAPI, PATA, SATA, batteries);
> >>
> >> 2. It will do the right thing on plug and unplug.  This means telling the
> >> rest of the kernel to disable the device in the bay, for example.  Right now
> >> we shutdown one end of the PATA/SATA link on ThinkPads eletrically, and
> >> leave libata to scream blood murder until it disables its end due to too
> >> many retries, for example;
> 
> :-)

Yeah :)  Try it with old ide, and the results are not... pretty.  libata new
EH *rules*.

> > Personally - I think tighter integration to libata here would be beneficial.
> > Once libata acpi support is straightened out, if we can store acpi handles
> > associated with libata devices, we can perhaps have a mechanism of obtaining
> > ata_device structs so that we can have a nice way of telling libata to 
> > delete devices etc.  I am hoping libata-acpi will be straightened out for
> > 2.6.22.
> 
> I dunno what the thread is really about but can't this be dealt within
> acpid?  Finding out the correct scsi host node can be tricky but I think

It could, yes.

But to me the kernel looks like the proper place for this one.  Not to
mention that we *really* should know the ACPI namespace -> kernel device
mapping in kernel, instead of doing half-assed things in userspace to call
back into kernel land later... it may come in handy for other things (proper
ACPI/driver exclusion of access to devices, for one), not just libata
matters and dock/bay ejects.

It is not like it is a policy thing.  The only possible correct path to
follow when doing an eject is to disable the devices and buses in the "it
will be powered off" side of the ejection hardware.  And depending on
userspace for this is just (IMHO) ugly and error-prone.  The kernel really
should know how to do it, and doing it is *easy* as long as you know the
mapping (which you should know for other reasons).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV