Hi Gerald,
On 03/07/12 23:35, Gerald Pfeifer wrote:
> I noticed we return in this case, without initializing this variable.
> Visual inspection indicates we do not seem to access the variable in
> this error case, but a) better safe than sorry, and b) GCC 4.8 currently
> warns about it.
>
> Not sure URLPOLICY_DISALLOW is the best return value, open for better
> alternatives.
I generally don't think this patch makes things any better (or worse).
If we return an error, the caller should not expect this value to be
sane. What's the GCC 4.8 warning?
Jacek
Implement a pair of new system calls to provide extended and further extensible
stat functions.
The second of the associated patches is the main patch that provides these new
system calls:
ssize_t ret = xstat(int dfd,
const char *filename,
unsigned atflag,
unsigned mask,
struct xstat *buffer);
ssize_t ret = fxstat(int fd,
unsigned atflag,
unsigned mask,
struct xstat *buffer);
which are more fully documented in the first patch's description.
These new stat functions provide a number of useful features, in summary:
(1) More information: creation time, inode generation number, data version
number, flags/attributes. A subset of these is available through a number
of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS).
(2) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server.
(3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its
cached attributes are up to date.
(4) Allow the filesystem to indicate what it can/cannot provide: A filesystem
can now say it doesn't support a standard stat feature if that isn't
available.
(5) Make the fields a consistent size on all arches, and make them large.
(6) Can be extended by using more request flags and appending further data
after the end of the standard return data.
Note that no lstat() equivalent is required as that can be implemented through
xstat() with atflag == 0.
=======
PATCHES
=======
Patch 1 defines the xstat() and fxstat() system calls.
Patches 2-6 implement extended stat facilities for Ext4, AFS, NFS and CIFS, and
make eCryptFS go to the lower filesystem for such details.
==============
CONSIDERATIONS
==============
Should fxstat() be implemented as xstat() with a NULL filename, using dfd as
fd?
Should the default for a network fs be to do an unconditional (heavyweight)
stat with a flag to suppress going to the server to update the locally held
attributes and flushing pending writebacks?
Should things like the Windows Archive, Hidden and System bits be handled
through IOC flags, perhaps expanded to 64-bits?
Are these things useful to userspace other than Samba and userspace NFS
servers?
Is it useful to pass the volume ID out? Or is statfs() sufficient for this?
Should I add a sixth argument to xstat(), mark it reserved and require that
must be supplied as 0 to hedge against future use?
Is there anything else I can usefully add at the moment?
==========
TO BE DONE
==========
Autofs, ntfs, btrfs, ...
I should perhaps use u8/u32/u64 rather than uint8/32/64_t.
Handle remote filesystems being offline and indicate this with
XSTAT_INFO_OFFLINE.
=======
TESTING
=======
There's a test program attached to the description for the main patch. It can
be run as follows:
[root@andromeda tmp]# ./xstat -R /mnt/foo
xstat(/mnt/foo) = 0
0000: 000081a40000ffef 0000000000000001 0000020000000000 0000100000080000
0020: 0000000000000000 0000000600000008 000000004f88499a 0000000136fd9208
0040: 000000004f88499a 0000000136fd9208 000000004f8849b9 0000000106daf187
0060: 000000004f8849b9 0000000106daf187 000000000000000c 000000000000000f
0080: 0000000000000008 00000000484ebbef 0000000000000025 5949ebd4711efd82
00a0: d3250b5c15d5e380 0000000000000000 0000000000000000 0000000000000000
00c0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
00e0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
results=ffef
Size: 15 Blocks: 8 IO Block: 4096 regular file
Device: 08:06 Inode: 12 Links: 1
Access: (0644/-rw-r--r--) Uid: 0
Gid: 0
Access: 2012-04-13 16:43:22.922587656+0100
Modify: 2012-04-13 16:43:53.115011975+0100
Change: 2012-04-13 16:43:53.115011975+0100
Create: 2012-04-13 16:43:22.922587656+0100
Inode version: 484ebbefh
Data version: 25h
Inode flags: 00080000 (-------- ----e--- -------- --------)
Information: 00000200 (-------- -------- ------a- --------)
Volume ID: 82fd1e71d4eb4959-80e3d5155c0b25d3
David
---
David Howells (6):
xstat: eCryptFS: Return extended attributes
xstat: CIFS: Return extended attributes
xstat: NFS: Return extended attributes
xstat: AFS: Return extended attributes
xstat: Ext4: Return extended attributes
xstat: Add a pair of system calls to make extended file stats available
arch/x86/syscalls/syscall_32.tbl | 2
arch/x86/syscalls/syscall_64.tbl | 2
fs/afs/inode.c | 29 ++-
fs/afs/super.c | 7 +
fs/cifs/cifsfs.h | 4
fs/cifs/cifsglob.h | 16 +-
fs/cifs/dir.c | 2
fs/cifs/inode.c | 120 +++++++++++--
fs/ecryptfs/inode.c | 14 +-
fs/ext4/ext4.h | 2
fs/ext4/file.c | 2
fs/ext4/inode.c | 32 +++
fs/ext4/namei.c | 2
fs/ext4/super.c | 1
fs/ext4/symlink.c | 2
fs/nfs/inode.c | 49 ++++-
fs/nfs/super.c | 1
fs/stat.c | 350 +++++++++++++++++++++++++++++++++++---
include/linux/fcntl.h | 1
include/linux/fs.h | 4
include/linux/stat.h | 126 +++++++++++++-
include/linux/syscalls.h | 7 +
22 files changed, 694 insertions(+), 81 deletions(-)
> This is because you _cannot_ install the 32-bit -dev packages onto
> 12.04. It's not just symlinks that are missing, many of the header
> files are different between the arches.
I'm not sure this is a generic rule, and if it were, then exclusion
between i386 and x86_64 should be defined on most dev packages, and
it's not the case
also note, that in some cases, arch specific headers are moved to arch
dependent directories (e.g. jpeg, glib...), which should also parallel
install of multi-arch libs
in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least
> Just do the chroot. You will save yourself so much grief and it will
> actually work.
if the ubuntu folks keep this state of mind, then they'll continue to sink
the best solution is then to pick up another distro
A+
--
--
Eric Pouech
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good day to all.
Henri, Stefan, I address this message to you at the first place as to a main
developers of wined3d/opengl stuff. Nevertheless, hints and help are welcome
from anyone, cause ATM I'm totally confused and don't know what else to try to
investigate a case.
What I've got here is an app (localized version of "Perfect World" MMORPG game
client from "Mail.Ru Games Corp") that seems to suffer huge FPS regression
which I believe to be a bug in nVIDIA drivers rather than a regression in Wine.
Details are following.
When I configure an app to run in a windowed mode I've got around 40 FPS on
game login screen with nVIDIA drivers 275.09.07, but switching into using more
recent versions causes FPS to drop to around ~10. Configuring the game to use
fullscreen more fixes the issue - I've got ~30-40 FPS at game login screen no
matter the driver version I use.
I've been suspecting that this issue might be related to vsync control (and a
recent change in nVIDIA linux drivers for vsync to be on by default) that
causes the issue, so I had exported __GL_SYNC_TO_VBLANK="0" into the
environment and used nvidia-settings to set vsync to be off by default. Using
a small native opengl demo program I had specifically written to test for
vsync state I can prove that vsync defaults to be off on my system. Also I had
modified Wine's winex11.drv opengl.c in a way that a call to
wglSwapIntervalEXT always sets swap_interval to be zero, no matter what was
originally requested. Nevertheless, I still got this strange FPS drop when I
run the game in a windowed more with a recent nVIDIA drivers.
What could be a cause for it? What I want is to track down the problem to it's
roots and check if it's really a bug in nVIDIA drivers. In the end I would
like to implement a small opengl demo that would trigger the bug so nVIDIA
wouldn't be able to reject my bug report on a matter that "it's a Wine bug,
prove us that it's not".
- --
Best regards,
Alexey Loukianov mailto:[email protected]
System Engineer, Mob.:+7(926)218-1320
*nix Specialist
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPij76AAoJEPB9BOdTkBULjz4H/1B/Nw6qOQUlEmDb64SmabvQ
LQmzIHcnH38Ftz3KyWQxlYZ5EtLDYAIOQeP4pAHfzxKhGUJ1mCumv4ByaSs4YDhI
juWJ/u/88vKwZYXJ9nZLQVqJY+dkr9MbxP3q0eGNaAFLNRDIqodzJJWB5EPucMrX
Yid/zMjl5uGd9QDCO3Db4gwJKYpvHCbAfzADddqBwPoak9jXdlq53H9a2mImTbCB
JR1MXQq6gFakOgtxXPxzFSU2Ge0n8RBGGN7UeZEubsLiktnmvTbKAJmmgWgPG80Y
mlud7LrM4wLRPtpwTwS+M1n8TuVtUZzzCTagRyj3XSRL8Pqf2d5S3H+MpxBT1JQ=
=TkMD
-----END PGP SIGNATURE-----
for the devels having upgraded their boxes to ubuntu 12.04, here's a
couple of stuff I had to do, especially to get 32bit wine compile
This could be useful if you want to have a dual x86_64 : i386 setup
this is an updated version to what I already sent to scott ritchie
of course this is not a step by step installation, just hints if you
want to take that road
(version #3)
(I'm using a multiarch x86_64/i386)
now wine compiles and runs in 32bit while compiled on 64bit machine
here's the summary of the pain getting it right after upgrade
in response to https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321
I was able to compile 32bit-wine on 64bit as I always, and without a
chroot or anything similar
Problem #1
----------
an old (11.10 according to the dates) directory was left over after
migration, whereas it should have been removed
/usr/include/i386-linux-gnu
Problem #2
----------
a ton of symlinks are missing in /usr/lib/i386-linux-gnu
for example
[root:/usr/lib/i386-linux-gnu]# ls -l /usr/lib/i386-linux-gnu/libfree*
lrwxrwxrwx 1 root root 20 avril 3 10:54
/usr/lib/i386-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.8.0
-rw-r--r-- 1 root root 624084 avril 3 10:54
/usr/lib/i386-linux-gnu/libfreetype.so.6.8.0
and it misses
lrwxrwxrwx 1 root root 16 avril 28 21:30
/usr/lib/i386-linux-gnu/libfreetype.so -> libfreetype.so.6
the same applies for a lot libraries
libXcursor.so
libXi.so
libXxf86vm.so
libxrandr.so
libxinerama.so
libxcomposite.so
libGLU.so
libdbus-1.so (libdbus-1.so lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu)
libgnutls.so
libsane.so
libv4l1.so
libgphoto2.so
libgphoto2_port.so
libgstreamer-0.10.so (***)
libcapi20.so
libcups.so
libfontconfig.so
libtiff.so
libmpg123.so
libopenal.so
libxrender.so
libGL.so (libGL.so is in mesa subdir!!!)
libxml2.so
libxslt.so
libssl.so
libcrypto.so
libjpeg.so (***)
libpng.so.0 (libpng12.so.0 lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu)
libXext.so
the ones marked (***) means that the symlink is missing but it doesn't
solve fully the issue from a wine perspective (see below)
Problem #3 (jpeg)
-----------------
Fails to open<jconfig.h>. which only lies in /usr/include/x86_64-linux-gnu/jconfig.h,
and couldn't be accessed from 32bit build
Creating the /usr/include/i386-linux-gnu/ directory and creating a symlink for
jconfig.h to /usr/include/x86_64-linux-gnu/jconfig.h just works
(I checked the contents of jconfig.h and it looks reasonable to do so)
Problem #4 (gstreamer)
----------------------
it doesn't work as only /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h
is installed (/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h doesn't
exist, dpkg -S doesn't find it)
and /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h
defines gint64 as long, which is correct on 64bit targets
one wrong on 32 bit ones...
one should craft a decent /usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h, or
grab one out of pure i386 install
(I haven't had time to look further into those, my main interest was to
have a 32bit setup up& running)
List of potentially installed i386 packages
-------------------------------------------
fixed by installing i386 packages (not exhaustive, unfortunately, as I
didn't note all the :i386 packages I've manually installed)
libldap2.so
alternatively, if I do a
[eric:~]$ dpkg -l | grep i386 | grep -- -dev
ii libc6-dev-i386 2.15-0ubuntu10 Embedded GNU C Library: 32-bit development libraries for AMD64
ii libldap2-dev:i386 2.4.28-1.1ubuntu4 OpenLDAP development libraries
ii libpthread-stubs0-dev:i386 0.3-3 pthread stubs not provided by native libc, development files
ii libx11-dev:i386 2.1.4.99.1-0ubuntu2 X11 client-side library (development headers)
ii libxau-dev:i386 1:1.0.6-4 X11 authorisation library (development headers)
ii libxcb1-dev:i386 1.8.1-1 X C Binding, development files
ii libxdmcp-dev:i386 1:1.1.0-4 X11 authorisation library (development headers)
tends to ask for libc6-dev:i386, libldap2-dev:i386, libx11-dev:i386,
libxau-dev:i386, libxcb1-dev:i386, libxdmcp-dev:i386
as dedicated installations of dev:i386 packages
but strangely enough, when looking at details, libx11-dev (for example)
cannot be installed with libx11-dev:i386 according
to manifest, but I have both installed (and both install the same files
in /usr/include for example)
this looks very strange indeed
List of stuff that won't work
-----------------------------
won't be supported (just to note them, as those are the left overs from
the configure failing list)
compiled without multiarch support: libhal, libgsm
Warning at compilation
----------------------
when compiling, some warnings still have to be worked upon
/home/eric/work/wine/dlls/winex11.drv/keyboard.c:1109:5: warning:
'XKeycodeToKeysym' is deprecated (declared at
/usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
this one can be forgotten for now (it's just being marked deprecated in
precise, so warning doesn't come from misconfiguration)
debugging (32bit and 64bit) is broken
-------------------------------------
the debugging is broken
it turns out that ptrace and prctl (which had to be added in 11.10) work fine
when tracing, only the first started process get correct pid out of wineserver in socket
SCM_CREDENTIALS info. the later get 0
I tried to force the pid without requiring the recvmsg stuff and it works just fine
I've not found yet the change that broke this
more to come if get any futher on the remaining topics
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Am Samstag, 28. April 2012, 10:16:13 schrieb Thomas Faber:
> Apparently NAN and INFINITE are C99 as well (I should really get a
> version of the old standard instead of mostly reading C99 :|).
>
> How about a simple const variable that will trick MSVC, while not
> changing semantics.
How about a function in libs/port or a macro in one of its headers? I believe
the NAN/INFINITE issue is not specific to wined3d.
With the const variable, msvc compiles the code, but still produces a warning.