From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PM <linux-pm@osdl.org>,
linux-kernel@vger.kernel.org, Ingo Oeser <ioe-lkml@rameria.de>
Subject: Re: [RFC/RFT][PATCH -mm] swsusp: userland interface
Date: Sat, 14 Jan 2006 11:29:51 +0000 [thread overview]
Message-ID: <20060114112950.GA2571@ucw.cz> (raw)
In-Reply-To: <200601141040.00088.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]
Hi!
> > > > > > It returns the number of pages. Well, it should be written explicitly,
> > > > > > so I'll fix that.
> > > > >
> > > > > Please always talk to the kernel in bytes. Pagesize is only a kernel
> > > > > internal unit. Sth. like off64_t is fine.
> > > >
> > > > These are values returned by the kernel, actually. Of course I can convert them
> > > > to bytes before sending to the user space, if that's preferrable.
> > > >
> > > > Pavel, what do you think?
> > >
> > > Bytes, I'd say. It would be nice if preffered image size was in bytes,
> > > too, for consistency.
> >
> > OK
>
> Having actually tried to do that I see two reasons for keeping the image size
> in megs.
>
> First, if that was in bytes, I'd have to pass it via a pointer, because
> unsigned long might overflow on i386. Then I'd have to use get_user()
Actually unsigned long is okay. We can't do images > 1.5GB, anyway,
on i386.
> to read the value. However, afterwards I'd have to rescale that value
> to megs for swsusp_shrink_memory(). It's just easier to pass the value
> in megs using the last argument of ioctl() directly (which is consistent
> with the /sys/power/image_size thing, BTW).
Well, I'd be inclined to make image_size in bytes, too. Having
each ioctl/sys file in different units seems wrong.
> Second, if that's in bytes, it would suggest that the memory-shrinking
> mechanism had byte granularity (ie. way off).
Yep, but it is not that bad.
> There also is a reason for which SNAPSHOT_AVAIL_SWAP should return
> the number of pages, IMO. Namely, if that's in pages, the number is directly
> comparable with the number of image pages which the suspending
> utility can read from the image header. Otherwise it would have to rescale
> one of these values using PAGE_SIZE, but that's exactly what we'd like
> to avoid.
I see.... We could put #bytes into image header (unsigned long) :-).
Its not too bad one way or another, because uswsusp tools are
intimately tied to kernel, anyway.
Pavel
--
Thanks, Sharp!
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Ingo Oeser <ioe-lkml@rameria.de>,
linux-kernel@vger.kernel.org, Linux PM <linux-pm@osdl.org>
Subject: Re: [RFC/RFT][PATCH -mm] swsusp: userland interface
Date: Sat, 14 Jan 2006 11:29:51 +0000 [thread overview]
Message-ID: <20060114112950.GA2571@ucw.cz> (raw)
In-Reply-To: <200601141040.00088.rjw@sisk.pl>
Hi!
> > > > > > It returns the number of pages. Well, it should be written explicitly,
> > > > > > so I'll fix that.
> > > > >
> > > > > Please always talk to the kernel in bytes. Pagesize is only a kernel
> > > > > internal unit. Sth. like off64_t is fine.
> > > >
> > > > These are values returned by the kernel, actually. Of course I can convert them
> > > > to bytes before sending to the user space, if that's preferrable.
> > > >
> > > > Pavel, what do you think?
> > >
> > > Bytes, I'd say. It would be nice if preffered image size was in bytes,
> > > too, for consistency.
> >
> > OK
>
> Having actually tried to do that I see two reasons for keeping the image size
> in megs.
>
> First, if that was in bytes, I'd have to pass it via a pointer, because
> unsigned long might overflow on i386. Then I'd have to use get_user()
Actually unsigned long is okay. We can't do images > 1.5GB, anyway,
on i386.
> to read the value. However, afterwards I'd have to rescale that value
> to megs for swsusp_shrink_memory(). It's just easier to pass the value
> in megs using the last argument of ioctl() directly (which is consistent
> with the /sys/power/image_size thing, BTW).
Well, I'd be inclined to make image_size in bytes, too. Having
each ioctl/sys file in different units seems wrong.
> Second, if that's in bytes, it would suggest that the memory-shrinking
> mechanism had byte granularity (ie. way off).
Yep, but it is not that bad.
> There also is a reason for which SNAPSHOT_AVAIL_SWAP should return
> the number of pages, IMO. Namely, if that's in pages, the number is directly
> comparable with the number of image pages which the suspending
> utility can read from the image header. Otherwise it would have to rescale
> one of these values using PAGE_SIZE, but that's exactly what we'd like
> to avoid.
I see.... We could put #bytes into image header (unsigned long) :-).
Its not too bad one way or another, because uswsusp tools are
intimately tied to kernel, anyway.
Pavel
--
Thanks, Sharp!
next prev parent reply other threads:[~2006-01-14 11:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-12 21:41 [RFC/RFT][PATCH -mm] swsusp: userland interface Rafael J. Wysocki
2006-01-12 22:09 ` Pavel Machek
2006-01-12 22:09 ` Pavel Machek
2006-01-12 22:47 ` Greg KH
2006-01-12 22:47 ` [linux-pm] " Greg KH
2006-01-12 23:31 ` Rafael J. Wysocki
2006-01-13 0:16 ` Pavel Machek
2006-01-13 0:16 ` Pavel Machek
2006-01-13 11:28 ` Rafael J. Wysocki
2006-01-13 19:53 ` Ingo Oeser
2006-01-13 19:53 ` Ingo Oeser
2006-01-13 20:49 ` Rafael J. Wysocki
2006-01-13 20:49 ` Rafael J. Wysocki
2006-01-13 20:59 ` Pavel Machek
2006-01-13 20:59 ` Pavel Machek
2006-01-13 21:24 ` Rafael J. Wysocki
2006-01-14 9:39 ` Rafael J. Wysocki
2006-01-14 11:29 ` Pavel Machek [this message]
2006-01-14 11:29 ` Pavel Machek
2006-01-14 12:19 ` Rafael J. Wysocki
2006-01-14 12:19 ` Rafael J. Wysocki
2006-01-14 17:43 ` 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=20060114112950.GA2571@ucw.cz \
--to=pavel@ucw.cz \
--cc=ioe-lkml@rameria.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
--cc=rjw@sisk.pl \
/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.