public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox