April 2012 - Wine-Devel - list.winehq.org

Re: Wine developer example sessions?

by Lucas Zawacki

When I first started to learn about wine development I stumbled across some examples exactly like these in the wine wiki. A quick search reveals them (the first 3) http://wiki.winehq.org/DeveloperExamples?action=fullsearch&context=180&valu… I myself like this aproach, it's a very useful form of documentation.

April 27, 2012

Wine developer example sessions?

by Dan Kegel

I'm bringing a new intern up to speed, and while I was showing him how to diagnose one particular wine bug, I recorded the session on a web page, http://kegel.com/wine/bug30486.html It occurred to me that recorded sessions like that might be useful to other beginners (above and beyond the more structured wine developer doc), so I created http://wiki.winehq.org/DeveloperExamples and linked to it from there. Does that seem useful, and are there other tutorials that could be linked to?

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-27, at 7:13 AM, Dave Chinner wrote: > Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined > at the bottom of the file. > > Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly > generic - they are for indicating that files are to be avoided for > defrag or backup purposes, the prealloc bit indicates that fallocate > has been used to reserve space on the inode (finding files that space > can be punched out of safely), and so on. There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl and I expect this to be in statxat() also. In ext4 there was also an EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF, but Eric thought it was a pain to maintain and it has been deprecated in ext4 and e2fsprogs recently. > Currently these things are queried and manipulated by ioctls > (XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project > quotas, etc. but I think there's some wider use for many of the > flags, which is why I was asking is there's any thought to this sort > of flag being exposed by the VFS. > > Historically the flags exposed by the VFS are those used by extN - I > see little reason why we should favour one filesystem's flags over > any others in an extended stat interface if they are generically > useful.... Sure, they started as ext4 flags because the "lsattr" and "chattr" tools were using this ioctl/flags, but have become more generic in recent years. FS_NOTAIL_FL was added for Reiserfs, and FS_NOCOW_FL was added for another filesystem (maybe Btrfs?). I'm not against adding more flags here that are generically useful, and recommended that statxat() have a 64-bit st_ioc_flags, since there are already 22 FS_*_FL flags defined today. >> Either you can add some of them to the ioc flags (which may be >> impractical, I grant you) or we'd have to add an arbitrary fs-type >> specific field and specify the host fs (the provision of which might >> not be a bad idea in and of itself) to tell userspace how to interpret them. > > Well, that's the complexity, isn't it. I have no good answer to > that... > >>> Along the same lines, filesytsems can have different allocation >>> constraints to IO the filesystem block size - ext4 with it's >>> bigalloc hack, XFS with it's per-inode extent size hints and the >>> realtime device, etc. Then there's optimal IO characteristics >>> (e.g. geometery hints like stripe unit/stripe width for the >>> allocation policy of that given file) that applications could >>> use if they were present rather than having to expose them >>> through ioctls that nobody even knows about... >> >> Yeah... Not representable by one number. You'd have to unset a >> flag to say you were providing this information. >> >> However, providing a whole bunch of hints about I/O characteristics >> is probably beyond this syscall - especially if it isn't constant >> over the length of a file. That's specialist knowledge that most >> applications don't need to know. >> Having a generic way to retrieve it, though, may be a good idea. > > We're continually talking about applications giving us usage hints > on what IO they are going to do so the storage can optimise the IO. > IO is still a GIGO problem, though, and the idea of geometry hints > is to enable us to tell the application to do well formed IO. i.e. > less garbage. > > XFS has ioctls to expose filesystem geometry, optimal IO sizes, the > alignment limits for direct IO, etc, and they are very useful to > applications that care about high performance IO. A lot of this can > be distilled down to a simple set of geometries, and generally > speaking they don't change mid way through a file.... > >> OTOH, there's plenty of uncommitted space, so if we can condense >> the hints down to something small, we could perhaps add it later - >> but from your paragraph above, it doesn't sound like it'll be small. > > Allocation block size, minimum sane IO size (to avoid page cache RMW > cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), > optimal IO size for bandwidth (e.g. stripe width). I don't think > there's much more than that which will be really usable by > applications. I think this is a minimal set that makes sense, and is manageable for both the interface and for users. Even if it isn't 100% correct for every file of every filesystem, it still makes sense for many systems. I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the minimum fragment or page size, st_iosize (BSD f_iosize) could be the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size. One could argue that "st_blksize" is used for the "optimal IO size" on Linux today, but this is an overloaded term. It _appears_ to represent the filesystem blocksize, which it usually is not, and on BSD st_bsize means the minimum blocksize and has a confusingly similar name. Since any application using this API needs to do some extra coding already, we may as well give the structure members good names that are not ambiguous. >>> Perhaps also exposing the project ID for quota purposes, like we >>> do UID and GID. That way we wouldn't need a filesystem specific >>> ioctl to read it.... >> >> Is this an XFS only thing? If so, can it be generalised? > > Right now it is, but there's been patches in the past to introduce > project quotas to ext4. That didn't go far because it was done in a > way that was semantically different to XFS (for no reason that I > could understand) and nobody wanted two different sets of semantics > for the "same" feature. The most common use of project quotas is to > implement sub-tree quotas, which is probably of more interest to > btrfs folks as it is an exact match for per-subvolume quotas. > > So, yes, I do see it as something generically useful - it's a > feature that a lot of people use XFS specifically for.... I'd agree. There was the tree quota project for ext4, and I've also heard this is available in other filesystems. Cheers, Andreas

April 27, 2012

Re: user32/tests: Update DlgDirList tests

by Bruno Jesus

On Sat, Apr 14, 2012 at 21:57, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Based on original patch from Christian Lupien from bug 8226. > > Tests required to later fix http://bugs.winehq.org/show_bug.cgi?id=8226 Is there anything else I could provide in helping to get this patch accepted? http://source.winehq.org/patches/data/85434 Regards, Bruno

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by J. Bruce Fields

On Fri, Apr 27, 2012 at 11:13:06PM +1000, Dave Chinner wrote: > Right now it is, but there's ben patches in the past to introduce > project quotas to ext4. That didn't go far because it was done in a > way that was semantically different to XFS (for no reason that I > could understand) and nobody wanted two different sets of semantics > for the "same" feature. The most common use of project quotas is to > implement sub-tree quotas, (Though it's also useful as a way to do safe subtree NFS exports). --b. > which is probably of more interest to > btrfs folks as it is an exact match for per-subvolume quotas. > > So, yes, I do see it as something generically useful - it's a > feature that a lot of people use XFS specifically for.... > > Cheers, > > Dave. > -- > Dave Chinner > david(a)fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Fri, Apr 27, 2012 at 10:39:05AM +0100, David Howells wrote: > Dave Chinner <david(a)fromorbit.com> wrote: > > > If we are adding per-inode flags, then what do we do with filesystem specific > > flags? e.g. XFS has quite a number of per-inode flags that don't align with > > any other filesystem (e.g. filestream allocator, real time file, behaviour > > inheritence flags, etc), but may be useful to retrieve in such a call. We > > currently have an ioctl to get that information from each inode. Have you > > thought about how to handle such flags? > > I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly > which flags you're talking about. The question, though, is what will actually > make use of these flags? Will it just be XFS tools or are they something that > a GUI might make use of? Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined at the bottom of the file. Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly generic - they are for indicating that files are to be avoided for defrag or backup purposes, the prealloc bit indicates that fallocate has been used to reserve space on the inode (finding files that space can be punched out of safely), and so on. Currently these things are queried and manipulated by ioctls (XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project quotas, etc. but I think there's some wider use for many of the flags, which is why I was asking is there's any thought to this sort of flag being exposed by the VFS. Historically the flags exposed by the VFS are those used by extN - I see little reason why we should favour one filesystem's flags over any others in an extended stat interface if they are generically useful.... > Either you can add some of them to the ioc flags (which may be impractical, I > grant you) or we'd have to add an arbitrary fs-type specific field and specify > the host fs (the provision of which might not be a bad idea in and of itself) > to tell userspace how to interpret them. Well, that's the complexity, isn't it. I have no good answer to that... > > Along the same lines, filesytsems can have different allocation constraints > > to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's > > per-inode extent size hints and the realtime device, etc. Then there's > > optimal IO characteristics (e.g. geometery hints like stripe unit/stripe > > width for the allocation policy of that given file) that applications could > > use if they were present rather than having to expose them through ioctls > > that nobody even knows about... > > Yeah... Not representable by one number. You'd have to unset a flag to say > you were providing this information. > > However, providing a whole bunch of hints about I/O characteristics is probably > beyond this syscall - especially if it isn't constant over the length of a > file. That's specialist knowledge that most applications don't need to know. > Having a generic way to retrieve it, though, may be a good idea. We're continually talking about applications giving us usage hints on what IO they are going to do so the storage can optimise the IO. IO is still a GIGO problem, though, and the idea of geometry hints is to enable us to tell the application to do well formed IO. i.e. less garbage. XFS has ioctls to expose filesystem geometry, optimal IO sizes, the alignment limits for direct IO, etc, and they are very useful to applications that care about high performance IO. A lot of this can be distilled down to a simple set of geometries, and generally speaking they don't change mid way through a file.... > OTOH, there's plenty of uncommitted space, so if we can condense the hints down > to something small, we could perhaps add it later - but from your paragraph > above, it doesn't sound like it'll be small. Allocation block size, minimum sane IO size (to avoid page cache RMW cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), optimal IO size for bandwidth (e.g. stripe width). I don't think there's much more than that which will be really usable by applications. > > Perhaps also exposing the project ID for quota purposes, like we do UID and > > GID. That way we wouldn't need a filesystem specific ioctl to read it.... > > Is this an XFS only thing? If so, can it be generalised? Right now it is, but there's ben patches in the past to introduce project quotas to ext4. That didn't go far because it was done in a way that was semantically different to XFS (for no reason that I could understand) and nobody wanted two different sets of semantics for the "same" feature. The most common use of project quotas is to implement sub-tree quotas, which is probably of more interest to btrfs folks as it is an exact match for per-subvolume quotas. So, yes, I do see it as something generically useful - it's a feature that a lot of people use XFS specifically for.... Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 27, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Stefan Dösinger

Am 26.04.2012 22:22 schrieb "Józef Kucia" <joseph.kucia(a)gmail.com>: > MSDN says that dwPitchOrLinearSize is DWORD in the DDS_HEADER. Also, > the same definition is used in a D3D sample. On the other hand, we can > define it as LONG to be safe. Nah, no need in that case. But I recommend to write tests for invalid pitches

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Dave Chinner <david(a)fromorbit.com> wrote: > If we are adding per-inode flags, then what do we do with filesystem specific > flags? e.g. XFS has quite a number of per-inode flags that don't align with > any other filesystem (e.g. filestream allocator, real time file, behaviour > inheritence flags, etc), but may be useful to retrieve in such a call. We > currently have an ioctl to get that information from each inode. Have you > thought about how to handle such flags? I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly which flags you're talking about. The question, though, is what will actually make use of these flags? Will it just be XFS tools or are they something that a GUI might make use of? Either you can add some of them to the ioc flags (which may be impractical, I grant you) or we'd have to add an arbitrary fs-type specific field and specify the host fs (the provision of which might not be a bad idea in and of itself) to tell userspace how to interpret them. > Along the same lines, filesytsems can have different allocation constraints > to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's > per-inode extent size hints and the realtime device, etc. Then there's > optimal IO characteristics (e.g. geometery hints like stripe unit/stripe > width for the allocation policy of that given file) that applications could > use if they were present rather than having to expose them through ioctls > that nobody even knows about... Yeah... Not representable by one number. You'd have to unset a flag to say you were providing this information. However, providing a whole bunch of hints about I/O characteristics is probably beyond this syscall - especially if it isn't constant over the length of a file. That's specialist knowledge that most applications don't need to know. Having a generic way to retrieve it, though, may be a good idea. OTOH, there's plenty of uncommitted space, so if we can condense the hints down to something small, we could perhaps add it later - but from your paragraph above, it doesn't sound like it'll be small. > Perhaps also exposing the project ID for quota purposes, like we do UID and > GID. That way we wouldn't need a filesystem specific ioctl to read it.... Is this an XFS only thing? If so, can it be generalised? David

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Andreas Dilger <adilger(a)dilger.ca> wrote: > > However, since there is a remote file ID, we could add an > > XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this. > > It is a bit strange that the kernel would return a flag that was not > requested, but not fatal. On the other hand, if it costs the kernel nothing to generate this indicator... For network filesystems, for instance, you might know that there is some other file ID because of the way the fs is specified. I was thinking that many of the fields will be given values, even if you don't ask for them, because the values (or approximations thereof) are present in memory already. David

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-26, at 7:06 PM, Dave Chinner wrote: > On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote: >> >> 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 (CIFS, NFS, AFS, Ext4 and BTRFS). > > If we are adding per-inode flags, then what do we do with filesystem > specific flags? e.g. XFS has quite a number of per-inode flags that > don't align with any other filesystem (e.g. filestream allocator, > real time file, behaviour inheritence flags, etc), but may be useful > to retrieve in such a call. We currently have an ioctl to get that > information from each inode. Have you thought about how to handle > such flags? I'm sympathetic to your cause, but I don't want this to degrade into the same morass that it did last time when every attribute under the sun was added to the call. The intent is to replace the stat() call with something that can avoid overhead on filesystems for which some attributes are expensive, and that applications may not need. Some common attributes were added that are used by multiple filesystems. If it is too filesystem-specific, and there is little possibility that these attributes will be usable on other filesystems, then it should remain a filesystem specific ioctl() call. If you can make a case that these attributes have value on a few other filesystems, and applications are reasonably likely to be able to use them, and their addition does not make the API overly complex, then suggest away. > Along the same lines, filesytsems can have different allocation > constraints to IO the filesystem block size - ext4 with it's > bigalloc hack, XFS with it's per-inode extent size hints and the > realtime device, etc. Then there's optimal IO characteristics > (e.g. geometery hints like stripe unit/stripe width for the > allocation policy of that given file) that applications could use > if they were present rather than having to expose them through > ioctls that nobody even knows about... There is already "optimal IO size" that the application can use, how do the geometry hints differ? Userspace is able to handle st_blksize of several MB in size without problems, and any sane application will do the IO sized + aligned on multiples of this. > Perhaps also exposing the project ID for quota purposes, like we do > UID and GID. That way we wouldn't need a filesystem specific ioctl > to read it.... This seems reasonable and generic and simple. This is similar to directory quotas in other filesystems. Cheers, Andreas

April 27, 2012