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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).