From: Andreas Schwab <schwab@suse.de>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH] Fix statfs(64) syscall wrapper
Date: Mon, 02 Jul 2007 22:05:05 +0200 [thread overview]
Message-ID: <m3hcomk1vy.fsf@igel.home> (raw)
The kernel's idea of fsid_t has always been a structure with 2 ints,
identical to the user space definition.
Andreas.
--- linux-user/syscall.c.~1.111.~ 2007-06-25 19:08:05.000000000 +0200
+++ linux-user/syscall.c 2007-07-02 21:35:07.000000000 +0200
@@ -3346,7 +3346,8 @@ long do_syscall(void *cpu_env, int num,
put_user(stfs.f_bavail, &target_stfs->f_bavail);
put_user(stfs.f_files, &target_stfs->f_files);
put_user(stfs.f_ffree, &target_stfs->f_ffree);
- put_user(stfs.f_fsid.__val[0], &target_stfs->f_fsid);
+ put_user(stfs.f_fsid.__val[0], &target_stfs->f_fsid.val[0]);
+ put_user(stfs.f_fsid.__val[1], &target_stfs->f_fsid.val[1]);
put_user(stfs.f_namelen, &target_stfs->f_namelen);
unlock_user_struct(target_stfs, arg2, 1);
}
@@ -3372,7 +3373,8 @@ long do_syscall(void *cpu_env, int num,
put_user(stfs.f_bavail, &target_stfs->f_bavail);
put_user(stfs.f_files, &target_stfs->f_files);
put_user(stfs.f_ffree, &target_stfs->f_ffree);
- put_user(stfs.f_fsid.__val[0], &target_stfs->f_fsid);
+ put_user(stfs.f_fsid.__val[0], &target_stfs->f_fsid.val[0]);
+ put_user(stfs.f_fsid.__val[1], &target_stfs->f_fsid.val[1]);
put_user(stfs.f_namelen, &target_stfs->f_namelen);
unlock_user_struct(target_stfs, arg3, 0);
}
--- linux-user/syscall_defs.h.~1.35.~ 2007-06-25 19:08:05.000000000 +0200
+++ linux-user/syscall_defs.h 2007-07-02 21:34:18.000000000 +0200
@@ -1305,6 +1305,10 @@ struct target_stat64 {
#error unsupported CPU
#endif
+typedef struct {
+ int val[2];
+} target_fsid_t;
+
#ifdef TARGET_MIPS
struct target_statfs {
target_long f_type;
@@ -1317,7 +1321,7 @@ struct target_statfs {
target_long f_bavail;
/* Linux specials */
- int f_fsid;
+ target_fsid_t f_fsid;
target_long f_namelen;
target_long f_spare[6];
};
@@ -1332,7 +1336,7 @@ struct target_statfs64 {
uint64_t f_files;
uint64_t f_ffree;
uint64_t f_bavail;
- int f_fsid;
+ target_fsid_t f_fsid;
uint32_t f_namelen;
uint32_t f_spare[6];
};
@@ -1345,7 +1349,7 @@ struct target_statfs {
uint32_t f_bavail;
uint32_t f_files;
uint32_t f_ffree;
- int f_fsid;
+ target_fsid_t f_fsid;
uint32_t f_namelen;
uint32_t f_frsize;
uint32_t f_spare[5];
@@ -1359,7 +1363,7 @@ struct target_statfs64 {
uint64_t f_bavail;
uint64_t f_files;
uint64_t f_ffree;
- int f_fsid;
+ target_fsid_t f_fsid;
uint32_t f_namelen;
uint32_t f_frsize;
uint32_t f_spare[5];
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
reply other threads:[~2007-07-02 20:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=m3hcomk1vy.fsf@igel.home \
--to=schwab@suse.de \
--cc=qemu-devel@nongnu.org \
/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.