"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Friday, 21 September 2007 23:08, Jeremy Maitin-Shepard wrote:
>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>>
>> > On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wro
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
> On Friday, 21 September 2007 22:26, Jeremy Maitin-Shepard wrote:
>> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > The ACPI NVS area is explicitly marke
ugh, that ACPI is first
initialized by the boot kernel, before it is later initialized by
resuming kernel. This could well be the source of the problem.
In particular, isn't it the case that you also switch the devices to low
power mode before resuming?
--
Jeremy Maitin-Shepard
-
To u
for the kexec implementation there may be additional
issues. For swsusp, uswsusp, and tuxonice, though, I don't see why
there should be a problem. I think that, as was recognized before, all
of the issues are resolved by properly considering exactly what each
callback should do and when
opyright headers at the top of the source files, rather than try to use
the MODULE_LICENSE notes.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel
d useful)
semantics for a mount option that allows modifications to other layers
as well, it would be a useful additional feature to support. It seems
that it should be possible to add this feature at a later time in any
case.
Perhaps referring to the plan9 semantics could be helpful.
--
Jeremy Mai
Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the system
just booted up normally. Then battery status and such should be
correct, since they are correct after normal initialization.
It should be possible to make hibernate look just like a reboot to all
of the devices, including ACPI stuff.
--
Jeremy Maitin-Shepard
-
To unsubscribe from
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
>> >> when doing a suspend-to-ram you get to a point where you just don't use
>> >> any userspace.
>>
>> > What do you mean? How can you prevent user
> run the scheduler, which means that user tasks can be scheduled, which
> means that they can run.
Does it really (fundamentally) require scheduling tasks, particularly in
the case that the devices have already been put in the "quiesced" state?
--
Jeremy Maitin-Shepard
-
followed by (3), at least for many drivers.
(1) is required by the kexec hibernate approach even ignoring suspend to
both or S4. (2) is required for suspend to ram without the freezer,
which seems to be desired anyway.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line
ly makes guarantees about such data (and I
don't believe any of the existing ones do).
It isn't necessary to be able to access such filesystems: everything can
be done from an initramfs/initrd.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscr
another OS shouldn't be a
problem, except that if you do it without powering off the system first,
some devices might not work under the other OS if the other OS doesn't
initialize them properly.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe
correctly you are still risking the loss of data, the
> user
> just doesn't know it.
It should be possible on any system to do a hibernate followed by a
shutdown (and then resume properly, without any problems). Thus, for
handling suspend to both, you resume as if the system had been s
image-saving kernel if that kernel doesn't know
> about
> the device.
The image-saving kernel can be made to know about all of the "wake up"
devices; all other devices should have already been powered off by the
"hibernated" kernel.
--
Jeremy Maitin-Shepard
-
To u
he question of what state the devices will be in when
switching back from the "save image" kernel to the "hibernated" kernel.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
bernate" ACPI by initializing it normally,
issue the special hibernate-related methods.
Thus, it seems that supporting ACPI S4 will have a very minimal affect
on the hibernate implementation.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe li
> That's why I think that for the suspend-to-both the image-saving kernel will
> need to support the same set of devices as the hibernated kernel.
If all of the devices that the image writing kernel doesn't know about
have already been shut down/powered off by the hibernat
nate is done,
this hook won't be used, and instead the resumed kernel will call the
ACPI hibernate resume stuff if S4 state was used; otherwise, the resumed
kernel will just re-initialize ACPI as normal. Also, if the in-kernel
code for checking if a resume can be done does not find a hibernat
can merely exist as a special shutdown mode.
Note that it seems a bit odd if ACPI can't be initialized normally after
resume from S4 (and still work), since the "load image" kernel
initializes everything normally before attempting to resume the
hibernated system.
--
Jeremy Maitin-S
t either the
metadata or the file contents are consistent. It isn't necessary for
hibernation to be able to access mounted partitions anyway.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
jump to the
> hibernated kernel
This would again avoid the need for a separate userspace-kernelspace
interface for the purpose, so I agree it could be a useful thing to do
initially.
> - in the restore code patch replace device_resume() with the reprobing of all
> devices.
See my
t may indeed be
important to support "cooperation" with the old kernel on saving the
image sooner, rather than later.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
inux (and
maybe also Windows?))
use LVM, thus allowing you to have as many volumes as you like in the
partition
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
Al Boldi <[EMAIL PROTECTED]> writes:
> Mark Lord wrote:
>> Jeremy Maitin-Shepard wrote:
>> > I'll certainly admit the kexec idea is vaporware currently,
> Your idea is starting to become a reality with this thread:
> "[PATCH 0/2] Kexec jump: The first
stripped down kernel may only take a
second or two to initialize.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
n.
>>
>> he's trying to get fancy again, the best way to speed up the boot of the
>> kexec kernel is make it smaller and avoid probing for devices (hotplug
>> should NOT be used for normal suspend situations)
> Still, I believe that we should do our best to use
hen you
>> remove freezer.
> I can produce them, but haven't managed to do that in any way that lets
> me get them off the system yet.
If you can see them, then perhaps you could use a digital camera or just
copy the text manually.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubsc
e for
suspend to ram, which will need to be solved anyway. Unlike the
existing hibernate approaches, however, it will not be necessary to use
any of the driver infrastructure once switched to the "save image"
kernel, and thus it will not matter what locks are held, for instance.
used to do it,
> which is known to work flawlessly with minimal OS involvement.
Now all that is needed is someone with enough time and interest to
implement it. :)
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> I don't know a whole lot about xen, but it seems that one issue with
>> this approach is that it requires you run your system under a hypervisor
>> at all times, which may introduce s
requires you run your system under a hypervisor
at all times, which may introduce some overhead.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Alan Stern <[EMAIL PROTECTED]> writes:
> On Mon, 9 Jul 2007, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > I don't know how to do that mechanism... but if we knew where to trap
>> > f
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Montag, 9. Juli 2007 schrieb Jeremy Maitin-Shepard:
>> Oliver Neukum <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > Hm, once the new kernel is booted, this decision is irrevocable, isn't it?
made available. This will not take very long, because copying
even 64MB of memory is extremely fast. Then the new kernel is free to
use the first X bytes of contiguous physical memory. Problem solved.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe
appropriate state, then copying the backed up memory
back to the beginning of physical memory, and finally jumping to the old
kernel. It would be much like what is done to resume from hibernation.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Nick Piggin <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>> This is the Morton method, isn't it? :) I remember it sounding like a
>>> very good idea when he brought it up, but I can't r
Nick Piggin <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> Al Boldi <[EMAIL PROTECTED]> writes:
>>
>>
>>> Pavel Machek wrote:
>>>
>>>> We are stuck with refrigerator for now, and at least for hibernation,
ke a printer must be prevented after the
snapshot. It seems, though, that in general the kernel will have no way
to know which operations are safe, and which are not safe.
(This is why the whole "proper filesystem snapshot support is the
solution" argument is bogus.)
--
Jeremy Maitin-Shep
ed), as the hibernate
operation itself would be completely atomic from the perspective of the
"old" kernel. That is not to say, of course, that any code paths would
actually be shared, or that the drivers would do the same things
(because they probably would not).
[snip]
--
Jeremy Ma
ately, even
leaving kernel threads and certain drivers running after the snapshot is
taken means that the saved image isn't completely correct, and the
freezer cannot help with these issues.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe li
but I need to find some more time to flesh it out.
>>
>> You can just describe it, as far as I'm concerned. :-)
[snip: new hibernate idea]
I think my kexec-based hibernate idea is simpler and more feasible than
this approach, and also avoids the freezer.
--
Jeremy Maitin-Shep
bad towards it's authors (taking all and every right you might
> have). If John Doe wants to re-release the whole kernel under
> GPLv3, then all he needs is a website and some bandwidth.
Well, he also needs one tiny little extra thing: the permission of every
copyright holder in Linux.
rather will,
> after GPLv3 is published).
You can do that, but you won't be able to distribute those changes along
with the rest of the kernel.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PRO
ifi
-over-pigeon-carrier-protocol-over-printer-and-scanner.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
>&
64MB
(or however much is desired for the "save" kernel to have) of memory
into free pages just before copying the "save" kernel into the desired
position and jumping to it.
Due to the speed of memory copying, this should not add any significant
overhead.
[snip]
--
Jeremy M
serve memory,
which I'm about to write. ;)
Please don't take my comments in this thread too harshly. I'm not
trying to undermine that work that you and the other hibernate
developers have done. I just think this kexec approach is an
interesting idea, and I brought it up so that it might get explored. I
still don't know if it actually makes sense (although I've managed to
mostly convince myself), and discussing it with you and the other
hibernate developers helps in figuring that out. If I didn't strongly
advocate it, it wouldn't get any thought.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
he explanations I gave in the other e-mail I
sent a few minutes ago in reply to Nigel) I think the kexec appraoch can be
viewed as a cleaner variant of userspace hibernate.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
g on a fuse filesystem, because essentially any code that is
run while writing the image needs to live in an special box that is totally
isolated from the rest of the system in order to avoid problems; thus, it seems
like it makes sense to implement this box by simply using a separate kernel,
rath
the same
procedure would be used to set up the necessary devices for both the
save and restore case, and the GUI that is used might also be the same.
>> > Still, I don't think we could implement it quickly and easily.
>>
>> It is hard to say how hard it would be. I thin
"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
"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.
>
relatively insignificant compared to the time required
to actually write the image, and the delay could be reduced by stripping
out unnecessary drivers from the image-writing kernel.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Jeremy Maitin-Shepard <[EMAIL PROTECTED]> writes:
> [snip]
> Well, my point was exactly that App Armor doesn't (as far as I know) do
> anything to enforce the argv[0] convention, nor would it in general
> prevent a confined program from making a symlink or hard link. E
Casey Schaufler <[EMAIL PROTECTED]> writes:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
>> Casey Schaufler <[EMAIL PROTECTED]> writes:
>>
>> > On Fedora zcat, gzip and gunzip are all links to the same file.
>> > I can imagine (althou
here is one.
This doesn't work. The behavior depends on argv[0], which is not
necessarily the same as the name of the file.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
It seems that this might introduce serious denial of service
possibilities due to the fact that many of the file systems are not
robust to invalid on-block-device data.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
n page description
included above), when neither the description of sa_mask nor the
description of SA_NODEFER specifies such an exception.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
FUSE already provides the
unprivileged mounting support mentioned in the proposal.
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
David Masover <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> David Masover <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>>
>>>> I have. And have seen /no/ benefit to you. Except, of course, the benefit
>>>> accr
ew tool, I can
> just browse around in /meta.
What is the relationship between file-as-dir or special meta-data and
transparent encryption+compression? I do not see why file-as-dir would
require such a special interface.
[snip]
--
Jeremy Maitin-Shepard
-
To unsubscribe from this list:
62 matches
Mail list logo
