Re: Patrick's Test9 suspend code.

• Previous message: Geert Uytterhoeven: "Re: PATCH: bugfix für RadeonFB (against 2.4.22-ac4, bug in 2.6.0-test9, too)"
• In reply to: Pavel Machek: "Re: Patrick's Test9 suspend code."
• Next in thread: Pavel Machek: "Re: Patrick's Test9 suspend code."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: Pavel Machek <pavel@suse.cz>
Date:	Wed, 19 Nov 2003 03:41:02 -0600

On Wednesday 19 November 2003 03:18, Pavel Machek wrote:
> Hi!
>
> > > :-), Okay, we could make grub read /etc/fstab... But again user can do
> > >
> > > swapoff and swapon manually etc.
> >
> > During resume?
>
> No, imagine /dev/hda3 being set as swap in /etc/fstab, but user doing
> swapoff /dev/hda3, swapon /dev/usb_zip_drive, then suspend.

A) Any scheme we come up with there will be a way the user can do something
stupid enough to break it. (Put the swap partition on a ramdisk living on
the video card, or on a device require an initrd to load the driver to
access...)

B) A heuristic that looks at the mounted block devices for things that smell
like a resume partition would actually be more robust in that case.

> /etc/mtab would be better choice, but swap does not appear there.

Okay, so why is /etc/mtab not supposed to be a link to /proc/mounts again?
(Especially since we're migrating to a per-process view of the mount tree...)

> > > Having sto stop userspace processes and bring hardware back to some
> > > sane state would complicate swsusp (and its testing!) a lot. Maybe in
> > > 2.8 when it works perfectly in other cases....
> >
> > If there's only one "init" style task running from initramfs, which
> > simply looks at the partitions and gets the info it needs from disk
> > labels or something without actually mounting a filesystem (or mounts it
> > read only, no journal playback, and then unmounts it again afterwards...)
> > And then the system call/whatever it does is sematically "exit and
> > resume from swap"...
>
> Well, I'd hate to write docs for that system call.
>
> "It is exit and resume from specified swap, you must not write any
> disk before you call it, must not access (list) devices, must not
> access any network."

The alternative is putting a heuristic in either the kernel or grub that
identifies your resume partition. The grub hack might not be so bad if
there's a symlink somewhere that points to the resume partition.
/etc/resume, /dev/resume, /boot/resume... Dunno. Read only root partitions
don't make this easy...

The objection's largely to having it hardwired into the kernel, but I suppose
if you now have to specify the root on the kernel command line, having to
specify resume isn't noticeably worse...

> > > ....but swsusp with modular kernels... I'm not sure if it can even
> > > work. .. yes it can but you really should get it working monolithic,
> > > first.
> >
> > Okay. Tell me how to get hotplug devices (cardbus, usb) working
> > monolithically, and I'm all for it.
>
> Well, just compile all the drivers you need in, and it just
> works.... I'm using both cardbus and usb and no, I'm not using
> modules.

It was unhappy last time I tried it, but that was several months back. Worth
a shot...

> Pavel

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Previous message: Geert Uytterhoeven: "Re: PATCH: bugfix für RadeonFB (against 2.4.22-ac4, bug in 2.6.0-test9, too)"
• In reply to: Pavel Machek: "Re: Patrick's Test9 suspend code."
• Next in thread: Pavel Machek: "Re: Patrick's Test9 suspend code."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]