ACPI docking stations are mildly complicated creatures that require the OS to handle part of the undocking process. We're currently doing this entirely within the kernel, but this has the significant downside that there's no way to handle cleanly unmounting any block devices that are contained within the dock - they'll simply vanish.
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
On 06/30/2009 07:26 PM, Matthew Garrett wrote:
ACPI docking stations are mildly complicated creatures that require the OS to handle part of the undocking process. We're currently doing this entirely within the kernel, but this has the significant downside that there's no way to handle cleanly unmounting any block devices that are contained within the dock - they'll simply vanish.
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
Where exactly in the desktop and can that be a library?
Rahul
On Tue, Jun 30, 2009 at 07:32:30PM +0530, Rahul Sundaram wrote:
On 06/30/2009 07:26 PM, Matthew Garrett wrote:
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
Where exactly in the desktop and can that be a library?
Policy is going to have to be desktop dependent, since it'll need to present appropriate UI to handle any drive removals. The backend will probably be a combination of DeviceKit-disks and either DeviceKit-power or a dock-specific daemon.
On Tue, 30 Jun 2009 14:56:44 +0100 Matthew Garrett mjg@redhat.com wrote:
ACPI docking stations are mildly complicated creatures that require the OS to handle part of the undocking process. We're currently doing this entirely within the kernel, but this has the significant downside that there's no way to handle cleanly unmounting any block devices that are contained within the dock - they'll simply vanish.
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
how common are docking stations in practice? (as opposed to port extenders)
On Tue, Jun 30, 2009 at 9:14 AM, Arjan van de Venarjan@infradead.org wrote:
how common are docking stations in practice? (as opposed to port extenders)
-- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Roughly half of the people where I work have docking stations for their laptops, they aren't all linux/Fedora users but docking stations are still somewhat commonplace around here.
-Adam
On Tue, Jun 30, 2009 at 07:14:52AM -0700, Arjan van de Ven wrote:
how common are docking stations in practice? (as opposed to port extenders)
I'm using the kernel definition here - that is, a dock is any ACPI device that may request a removal via ACPI notifications and requires ACPI methods to be called to complete that removal. Most of these do not include media bays, though ones containing media bays are common on 12" systems. The problem is that it's not trivial (and perhaps impossible) to tell from the kernel whether you have:
laptop -> media bay | dock
or
laptop -> dock -> media bay
since the dock and the bay devices aren't tightly associated in the ACPI device tree. So it's not possible to make the change in behaviour conditional on finding a dock with a media bay.
On 06/30/2009 08:14 AM, Arjan van de Ven wrote:
how common are docking stations in practice? (as opposed to port extenders)
Majority of our laptop users have them. Would be great to have them supported.
On Tue, 2009-06-30 at 14:56 +0100, Matthew Garrett wrote:
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
Can't the desktop inform the kernel if it can handle the interaction? If not, you can just fallback to the current behavior.
On Tue, Jun 30, 2009 at 11:28:24AM -0400, Dimi Paun wrote:
On Tue, 2009-06-30 at 14:56 +0100, Matthew Garrett wrote:
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
Can't the desktop inform the kernel if it can handle the interaction? If not, you can just fallback to the current behavior.
Somewhat, but you then hit issues like fast user switching potentially involving desktops that support this and desktops that don't.
On Tue, 2009-06-30 at 16:46 +0100, Matthew Garrett wrote:
Can't the desktop inform the kernel if it can handle the
interaction?
If not, you can just fallback to the current behavior.
Somewhat, but you then hit issues like fast user switching potentially involving desktops that support this and desktops that don't.
But this is more a theoretical concern than practical. It would seem to me that you would still end up doing the "right thing" in a lot more cases than otherwise.
And fast user switching could be instrumented to tell the kernel the right thing.
The current behavior is useful for cases when you don't want user interaction (either because some desktops do not have the manpower to do it, or the use case for the box is such where such interaction is not desired).
Matthew Garrett wrote:
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
What changes are needed to the desktop?
The big problem we've been facing integrating new features of core system services into KDE so far was lack of documentation. What do we need to change?
If this will be all handled within DeviceKit, then this will come by itself with the Solid DeviceKit backend ltinkl is working on, but if we need to add some desktop interaction for it, we have to know what it should be.
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change.
Kevin Kofler
On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
I've been working with David Zeuthen to flesh out proper desktop support for this, and we're now at the point where there's not a great deal of code to write to get this working cleanly. Unfortunately this requires a certain level of integration between the kernel and the desktop - something has to prompt the user about unmounting the device and then trigger the completion of the undock. The kernel still handles the actual ACPI execution, but policy now lives in the desktop.
What changes are needed to the desktop?
The big problem we've been facing integrating new features of core system services into KDE so far was lack of documentation. What do we need to change?
An event will be generated and a policy agent then needs to choose what to do in terms of unmounting any media. The precise interface doesn't exist yet, but will be documented.
If this will be all handled within DeviceKit, then this will come by itself with the Solid DeviceKit backend ltinkl is working on, but if we need to add some desktop interaction for it, we have to know what it should be.
So, what you'll get is a notification that a block device has requested removal along with a notification that a dock device is being undocked. What you do with the block device is up to you, but in general you'll want to unmount it. Whether you're willing to kill applications that have open files on it is a policy decision. After the unmount you'll then trigger the completion of the undock and tell the user that it's now safe to remove their hardware.
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change.
Hm. So, that bit about KDE not holding Gnome back wasn't entirely correct?
On Tue, Jun 30, 2009 at 11:19 AM, Matthew Garrettmjg@redhat.com wrote:
On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote:
You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change.
Hm. So, that bit about KDE not holding Gnome back wasn't entirely correct?
I think you mean "holding back Fedora." Obviously KDE is not holding back GNOME, or GNOME's development, or the GNOME Desktop Team from doing their work.
Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one "use at your own risk" desktop?
True question. I enjoy the new features in Fedora, like Bluetooth, PackageKit, and even Pulse occasionally. And I really like KDE, but I have cold shivers thinking that whether or not any of this stuff works under KDE is a crapshoot.
KDE may not hold back GNOME. But it is perfectly logical to expect that KDE will hold back a Fedora feature release, if indeed A) that feature is not yet implemented in the desktop, and B) Fedora wishes to support KDE and GNOME together. Assuming that KDE features are given the same respect as GNOME features.
If that doesn't hold, then no, KDE won't be holding back anybody. I suppose I'd be using KDE a little less under Fedora then.
On Tue, 2009-06-30 at 13:42 -0500, Jud Craft wrote:
Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one "use at your own risk" desktop?
Strictly, they're all "use at your own risk".
- ajax
Darn straight. I stand corrected.
On Tue, Jun 30, 2009 at 3:06 PM, Adam Jacksonajax@redhat.com wrote:
On Tue, 2009-06-30 at 13:42 -0500, Jud Craft wrote:
Fedora's deployment of that work, however, is another matter. Does Fedora offer a variety of environments with a set of common features and infrastructure, or is it one functional desktop and one "use at your own risk" desktop?
Strictly, they're all "use at your own risk".
- ajax
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Matthew Garrett wrote:
So, what you'll get is a notification that a block device has requested removal along with a notification that a dock device is being undocked. What you do with the block device is up to you, but in general you'll want to unmount it.
IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a "please unmount me" event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers?
An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me.
Kevin Kofler
On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote:
IMHO DeviceKit should just unmount it itself and notify the desktop that it has unmounted the device so the desktop can report it (or ignore it if it doesn't know about the event). I don't see why we need to add code to every desktop to listen for a "please unmount me" event and send an unmount request back when this could just be handled within DeviceKit. Or even within the kernel for that matter, do we really need a roundtrip through userspace for this? When and why would we ever want to do anything *other* than unmounting the device when this event triggers?
Because you might want to warn the user that they have unsaved work that will be lost if they continue?
An additional problem is: what if the unmount fails due to open files? Your suggestion to just kill the applications sounds really broken to me. A forced unmount at kernel level and failing any attempts to further access that file just like what happens when an NFS mount goes offline sounds like a better solution to me.
There are alternatives, like revoking the filehandles or prompting the user to close the application themselves. This is the same problem faced when unmounting any device.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matthew Garrett wrote:
On Wed, Jul 01, 2009 at 12:31:20AM +0200, Kevin Kofler wrote:
IMHO DeviceKit should just unmount it itself and notify the
desktop that it
has unmounted the device so the desktop can report it (or
ignore it if it
doesn't know about the event). I don't see why we need to
add code to every
desktop to listen for a "please unmount me" event and send
an unmount
request back when this could just be handled within
DeviceKit. Or even
within the kernel for that matter, do we really need a
roundtrip through
userspace for this? When and why would we ever want to do
anything *other*
than unmounting the device when this event triggers?
Because you might want to warn the user that they have
unsaved work that
will be lost if they continue?
Isn't there "Save As..." for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails.
An additional problem is: what if the unmount fails due to
open files? Your
suggestion to just kill the applications sounds really
broken to me. A
forced unmount at kernel level and failing any attempts to
further access
that file just like what happens when an NFS mount goes
offline sounds like
a better solution to me.
There are alternatives, like revoking the filehandles or
prompting the
user to close the application themselves. This is the same
problem faced
when unmounting any device.
Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this.
A similar problem is this:
mkdir foo touch foo/bar kwrite foo/bar & rm -rf foo
Should kwrite be killed because rm killed the directory?
- --Ben
On Tue, Jun 30, 2009 at 09:01:45PM -0400, Ben Boeckel wrote:
Isn't there "Save As..." for saving it? If not, I smell a bug report. When I'm working over sshfs and the network goes down, my editor still works with the file, the actual save is what fails.
It depends on what resources you have open on the hardware. If part of your application is on the disk that's about to be disconnected, then you have problems.
Umm, Windows locks files when they're opened. AFAIK, Linux doesn't enforce this.
A similar problem is this:
mkdir foo touch foo/bar kwrite foo/bar & rm -rf foo
Should kwrite be killed because rm killed the directory?
No, because it still has a reference to it. Unmount works differently to remove.
On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote:
Matthew Garrett wrote:
Once this code is ready I'd like to change the kernel defaults to allow this. The problem is that this will cause a reduction in functionality for desktops that don't have this integration. How should this kind of situation be handled?
You have to tell us what we need to change in KDE and give us the necessary time to adapt, even if it means you have to wait for Fedora 13 to push this change.
I think the words you have choosen here are too strong. There is no current policy or requirement that requires that.
I will certainly agree that it would be _better_ to coordinate among the DEs, and even possibly say it's preferred. But there is nothing that says they have to do that or wait for other DEs to catch up.
josh
Josh Boyer wrote:
I think the words you have choosen here are too strong. There is no current policy or requirement that requires that.
And that's a big problem which needs fixing. Though I'd argue that it's just common sense and shouldn't need a policy in the first place. Just breaking other packages with an incompatible change without giving them a chance to adapt is the quickest way to degrade Fedora's quality.
Kevin Kofler
On Wed, Jul 01, 2009 at 12:37:16AM +0200, Kevin Kofler wrote:
Josh Boyer wrote:
I think the words you have choosen here are too strong. There is no current policy or requirement that requires that.
And that's a big problem which needs fixing. Though I'd argue that it's just common sense and shouldn't need a policy in the first place. Just breaking
It is not always cut and dry.
other packages with an incompatible change without giving them a chance to adapt is the quickest way to degrade Fedora's quality.
Quite possibly. Though there are also cases where changes are made that will break a package and upstream has little or no intention of dealing with it in a timeframe that allows Fedora to progress. The whole zope/plone fiasco comes to mind there. I don't think KDE is the same in that regard, and both the KDE SIG and KDE upstream are very active and even proactive on a number of issues.
So I agree breaking things is bad, and in general we should all try and play nice and communicate about upcoming changes. Which is exactly what Matthew has done by starting this very thread. Good for him.
josh
Josh Boyer (jwboyer@gmail.com) said:
So I agree breaking things is bad, and in general we should all try and play nice and communicate about upcoming changes. Which is exactly what Matthew has done by starting this very thread. Good for him.
And, to be honest, I think a hack that just returns 'hey, do whatever' to the kernel (thereby preserving the old behavior) would be pretty darn simple.
Bill
-
Adam Jackson -
Adam Miller -
Arjan van de Ven -
Ben Boeckel -
Bill Nottingham -
Dimi Paun -
Josh Boyer -
Jud Craft -
Kevin Kofler -
Matthew Garrett -
Orion Poplawski -
Rahul Sundaram