Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 9:14 AM, Arjan van de Venar...@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 -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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. -- Dimi Paun d...@lattica.com Lattica, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
On Tue, Jun 30, 2009 at 11:19 AM, Matthew Garrettm...@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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Darn straight. I stand corrected. On Tue, Jun 30, 2009 at 3:06 PM, Adam Jacksona...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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). -- Dimi Paun d...@lattica.com Lattica, Inc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpKtXkACgkQiPi+MRHG3qTVrgCfXM3ItQpUBYzK1JT91RoJ4rjy fNEAoKEkgrII4JNkaundDYMv76fTAD69 =qUfz -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
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. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
- Matthew Garrett m...@redhat.com wrote: On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: Matthew Garrett wrote: 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. IMHO, it is pretty much similar to the way that we handle USB hubs and devices. In terms of UI, it may have a nice dock status icon to show status and to be pressed if users want to un-dock safely. Yet we still need to handle the force-undock event, just like we handle the forced unplug USB devices. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Kernel changes that may affect desktops
Josh Boyer (jwbo...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
