On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote: > Hi Greg. > > Greg KH wrote: >> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote: >>> Hi. >>> >>> Greg KH wrote: >>>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote: >>>>> Hi. >>>>> >>>>> Matthew Garrett wrote: >>>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote: >>>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse >>>>>>> as a limitation of the freezer. To do that with kexec, you're still >>>>>>> going to have to bmap the ext3 fs and pass the block list (in which >>>>>>> case we can also do it without kexec) or umount all the ext3/fuse >>>>>>> part and remount in the kexec'd kernel. Sort of defeats the purpose, >>>>>>> doesn't it? >>>>>> No, with a freezer-based model you can basically *never* suspend to >>>>>> anything related to FUSE or a userspace USB device or anything >>>>>> involving userspace iSCSI initiators or whatever. Sure, there are >>>>>> cases where moving away from the current model doesn't buy you >>>>>> anything, but that doesn't mean that the current model is a good >>>>>> thing. It's not. The freezer is a fundamentally broken concept. >>>>> Putting drivers and filesystems in userspace is the fundamentally >>>>> broken concept. Not just when it comes to the freezer. The whole idea >>>>> is inherently racy. >>>> Racy with regards to other things becides trying to suspend a machine? >>>> If so, what? >>> That depends on what sort of tangled web you want to weave. >> Lots of them :) >> We have tanks running Linux using userspace USB drivers for vision >> control systems (scary, I know...) They seem to be successfully running >> for many years now, and I'm interested in making sure those kinds of >> things keep working. >> We also have laser welding robots with userspace PCI drivers in car >> manufacturing plants. And other laser cutting robots slicing wood in >> patterns moving at a rate of over 3 meters a second. Again, with >> userspace drivers and Linux. >> Those users would also love to know of any potential problems you know >> of for this situation. >>> Low memory situations is one other situation that occurs to me >>> quickly, especially (though not only) if your ability to swap were to >>> depend upon a userspace driver and/or filesystem. >> Sure, swap over a userspace filesystem or driver isn't a sane idea. And >> neither is swaping over NFS over a PPP connection attached to a USB to >> serial device. Yes, it's possible, and all in the kernel, but not a >> wise decision. >> Other than foolish configurations, if you come up with other issues >> surrounding userspace drivers that could cause problems, please let me >> know. > > A simple OOM condition isn't an issue? Surely a driver stalling because > some of its memory gets swapped out just before it goes to use it would be > a problem if it resulted in getting the length of a cut wrong or caused > some distorted vision or a late turn :> > > Am I missing something? Maybe these drivers mlock memory to avoid those > issues or something like that? I think the mlock their memory to prevent this from happening, it's not hard when you control all the applications on the box :) thanks, greg k-h - 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
