All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Pavel Machek <pavel@suse.cz>
Cc: Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: Patrick's Test9 suspend code.
Date: Wed, 19 Nov 2003 03:41:02 -0600	[thread overview]
Message-ID: <200311190341.02031.rob@landley.net> (raw)
In-Reply-To: <20031119091833.GE197@elf.ucw.cz>

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

  reply	other threads:[~2003-11-19  9:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-09 10:04 Patrick's Test9 suspend code Rob Landley
2003-11-13 13:08 ` Pavel Machek
2003-11-16  0:30   ` Rob Landley
2003-11-16 13:13     ` Pavel Machek
2003-11-17  2:38       ` Rob Landley
2003-11-17  8:42         ` Pavel Machek
2003-11-17 16:45         ` Patrick Mochel
2003-11-17 21:11           ` Rob Landley
2003-11-18 12:02           ` Rob Landley
2003-11-18 18:22             ` Pavel Machek
2003-11-18 22:12               ` Rob Landley
2003-11-18 23:21                 ` Pavel Machek
2003-11-19  5:26                   ` Rob Landley
2003-11-19  9:18                     ` Pavel Machek
2003-11-19  9:41                       ` Rob Landley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-11-19 13:15 Samium Gromoff
2003-11-19 19:06 ` Pavel Machek
2003-11-20 17:26 Shaheed
2003-11-20 19:39 ` Rob Landley
2003-11-20 22:33   ` Shaheed
2003-11-20 22:41     ` Nigel Cunningham
2003-11-20 23:02       ` Shaheed
2003-11-21  6:46       ` Rob Landley
2003-11-21 20:09         ` Nigel Cunningham
2003-11-21  0:06 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200311190341.02031.rob@landley.net \
    --to=rob@landley.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=pavel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.