Hi.
On Sun, 2007-06-10 at 19:02 -0700, H. Peter Anvin wrote:
> Matthew Garrett wrote:
> > No, it only supports ext2 (and reading ext3 as if it's ext2). Right now,
> > the assumption that syncing during suspend will cause data to hit
> > something grub can read isn't a safe one.
>
> I brought th
Xavier Bestel <[EMAIL PROTECTED]> writes:
[snip]
> If I were helping you coding I'd suggest to only concentrate on having
> your project work on standard filesystems, and then when it works maybe
> think about suspending on crypto-over-loop-over-fuse-over-vpn-over-wifi.
> But talk is cheap so I'm
On Mon, 2007-06-11 at 11:51 -0400, Jeremy Maitin-Shepard wrote:
> Xavier Bestel <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote:
> >> >> You might claim then that the solution is to simply keep the network
> >> >> driver quiesced or stopped. But th
Xavier Bestel <[EMAIL PROTECTED]> writes:
> On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote:
>> >> You might claim then that the solution is to simply keep the network
>> >> driver quiesced or stopped. But then it is impossible to write the
>> >> image over the network. The way to
On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote:
> >> You might claim then that the solution is to simply keep the network
> >> driver quiesced or stopped. But then it is impossible to write the
> >> image over the network. The way to get around this problem is to write
> >> the im
Pavel Machek <[EMAIL PROTECTED]> writes:
[snip]
>> > If _I_ were willing to add some runtime overhead to make hibernation
>> > simpler, I'd just use some virtualization to do that... with added
>> > advantage of "hibernate here, resume on different hw".
>>
>> I don't believe there is going to be
Nigel Cunningham <[EMAIL PROTECTED]> writes:
[snip]
> Trying to image a system to a fuse filesystem is indeed fundamentally
> broken. The problem is really that we have to make choices about what we
> will and won't support.
> We can have suspending to fuse filesystems, but only if we have
> run
Hi.
On Fri, 2007-06-01 at 21:54 -0400, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> >> But kernel threads also rely on userspace, due to e.g. fuse and usermode
> >> helpers.
>
> > Yes, I know that and I think these issues are solvable within the current
> >
Matthew Garrett wrote:
> No, it only supports ext2 (and reading ext3 as if it's ext2). Right now,
> the assumption that syncing during suspend will cause data to hit
> something grub can read isn't a safe one.
I brought this issue up quite a few years ago at an OLS BOF. We pretty
much need a "s
On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote:
> On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
> > FWIW, on my old laptop apm beats any kernel solution hands down in terms
> > of speed
>
> This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
> RA
On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
> FWIW, on my old laptop apm beats any kernel solution hands down in terms
> of speed
This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
RAM setups. At least not if you actually use that memory for anything
in
On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote:
> I spent some time, last I think, seriously considering this approach.
> The more I thought about the details, the more I realised that it wasn't
> a viable approach. As I said before, it does indeed sound like a dream
> at first, but once
Hi!
> > > To me, it seems a lot easier to get right than the current approaches.
> >
> > Well, you are certainly welcome to create the patch. "suspend3" name
> > is still free, AFAICT.
>
> I could be sneaky and call it "hibernate". Probably nicer though to use the
> name "kexec hibernate" to b
Hi.
On Mon, 2007-06-04 at 18:09 -0400, Jeremy Maitin-Shepard wrote:
> I was hoping that everyone would like the idea so much that they would
> rush to
> implement it, so that I wouldn't have to try. (I haven't written much kernel
> code before, and I have a number of other time-requiring projec
On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote:
> [snip]
> > You might claim then that the solution is to simply keep the network
> > driver quiesced or stopped. But then it is impossible to write the
> > image over the network. The way to get around this problem is to write
> > t
On Mon, Jun 04, 2007 at 03:22:20PM +1000, Nigel Cunningham wrote:
> Hi.
>
> I can see that the idea of writing a kernel image from using another
> kernel sounds nice and clean initially, but the more we get into the
> details (yes, I am listening, even though I said nothing before now),
> the more
On Mon, Jun 04, 2007 at 03:10:00PM +0200, Pavel Machek wrote:
> On Mon 2007-06-04 13:20:54, Matthew Garrett wrote:
> > On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote:
> >
> > > sync is perfectly safe way of telling the fs to store data on disk.
> >
> > On disk, yes. On the filesyste
On Mon 2007-06-04 13:20:54, Matthew Garrett wrote:
> On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote:
>
> > sync is perfectly safe way of telling the fs to store data on disk.
>
> On disk, yes. On the filesystem, no. It's valid for the data to be left
> in the journal, for instance.
On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote:
> sync is perfectly safe way of telling the fs to store data on disk.
On disk, yes. On the filesystem, no. It's valid for the data to be left
in the journal, for instance.
--
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from
Hi!
> >> But kernel threads also rely on userspace, due to e.g. fuse and usermode
> >> helpers.
>
> > Yes, I know that and I think these issues are solvable within the current
> > approach.
>
> It seems like it would be very hard to get writing of an image to a
> fuse filesystem working under th
Hi again.
On Mon, 2007-06-04 at 10:05 +0200, Rafael J. Wysocki wrote:
> On Monday, 4 June 2007 07:22, Nigel Cunningham wrote:
> > Hi.
> >
> > I can see that the idea of writing a kernel image from using another
> > kernel sounds nice and clean initially, but the more we get into the
> > details (
Hi,
On Monday, 4 June 2007 07:22, Nigel Cunningham wrote:
> Hi.
>
> I can see that the idea of writing a kernel image from using another
> kernel sounds nice and clean initially, but the more we get into the
> details (yes, I am listening, even though I said nothing before now),
> the more it's s
Hi.
I can see that the idea of writing a kernel image from using another
kernel sounds nice and clean initially, but the more we get into the
details (yes, I am listening, even though I said nothing before now),
the more it's sounding like the cure is worse than the disease.
To get rid of process
On Fri, Jun 01, 2007 at 07:54:30PM -0400, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
>
> [snip]
>
> >> Just before jumping into the new kernel, with interrupts disabled, the
> >> old kernel cou
On Saturday, 2 June 2007 03:54, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> >> But kernel threads also rely on userspace, due to e.g. fuse and usermode
> >> helpers.
>
> > Yes, I know that and I think these issues are solvable within the current
> > approach
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>> But kernel threads also rely on userspace, due to e.g. fuse and usermode
>> helpers.
> Yes, I know that and I think these issues are solvable within the current
> approach.
It seems like it would be very hard to get writing of an image to a
fuse
On Saturday, 2 June 2007 01:54, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
>
> [snip]
>
> >> Just before jumping into the new kernel, with interrupts disabled, the
> >> old kernel could either
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
[snip]
>> Just before jumping into the new kernel, with interrupts disabled, the
>> old kernel could either prepare a data structure that specifies what
>> pages are allocated, or alter
On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > On Friday, 1 June 2007 22:39, Jeremy Maitin-Shepard wrote:
> >> I figured I'd throw this idea out, since although it is not perfect, it
> >> has the potential to elegantly solve a l
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Friday, 1 June 2007 22:39, Jeremy Maitin-Shepard wrote:
>> I figured I'd throw this idea out, since although it is not perfect, it
>> has the potential to elegantly solve a lot of issues with hibernate.
>>
>> Just as kexec can now be used to wr
On Friday, 1 June 2007 22:39, Jeremy Maitin-Shepard wrote:
> I figured I'd throw this idea out, since although it is not perfect, it
> has the potential to elegantly solve a lot of issues with hibernate.
>
> Just as kexec can now be used to write a crashdump after a kernel panic,
> a fresh kexec-l
I figured I'd throw this idea out, since although it is not perfect, it
has the potential to elegantly solve a lot of issues with hibernate.
Just as kexec can now be used to write a crashdump after a kernel panic,
a fresh kexec-loaded kernel (loaded into unused memory) could be used to
write the h
32 matches
Mail list logo
