On 2012-04-26, at 6:51 PM, Dave Chinner wrote:
> On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
>> I wonder if there's a way to make this explicit - or is it something that if
>> the bit isn't set, you can't use the value in st_blksize.
>> I wonder if this value always has to be no
On 2012-04-26, at 10:52, David Howells wrote:
> Steve French wrote:
>>
>> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique
>> identifier, but in the case of CIFS some old servers don't support the calls
>> which return inode numbers (or don't return them for all file s
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
On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote:
> Andreas Dilger wrote:
> > st_blksize may be variable for a distributed filesystem,
It can be variable for local filesystems, too. XFS will vary the
block size based on the configuration of the inode. e.g. if there is
an extent alloc
On Thu, 2012-04-26 at 15:05 -0700, Roland McGrath wrote:
> > What if the xstat() and struct xstat eventually becomes what userspace
> > uses as stat() (as a wrapper) and struct stat (if such a thing is
> > possible with glibc versioning)?
>
> It's certainly possible with symbol versioning, thoug
On Thu, 2012-04-26 at 22:57 +0100, David Howells wrote:
> Myklebust, Trond wrote:
>
> > You are still not explaining why they need to know the values at all? If
> > the values are bogus, then don't return them, and don't set the flag
> > that says they are being returned.
> th
> What if the xstat
On 26 Apr 2012, Roland McGrath verbalised:
>> fileinfoat() perhaps? I think stat*at() is better, though, as people are
>> used to the stat function family.
>
> Names like that were all I had thought of when I said I hadn't thought of
> any good ones. ;-)
Quite. It's a garden-path function name.
> What if the xstat() and struct xstat eventually becomes what userspace
> uses as stat() (as a wrapper) and struct stat (if such a thing is
> possible with glibc versioning)?
It's certainly possible with symbol versioning, though it seems much more
likely that we'd stick with the existing struc
> fileinfoat() perhaps? I think stat*at() is better, though, as people are
> used to the stat function family.
Names like that were all I had thought of when I said I hadn't thought of
any good ones. ;-)
Myklebust, Trond wrote:
> You are still not explaining why they need to know the values at all? If
> the values are bogus, then don't return them, and don't set the flag
> that says they are being returned.
What if the xstat() and struct xstat eventually becomes what userspace uses as
stat() (as
Roland McGrath wrote:
> > I've no particular attachment to the name 'xstat'. If you'd prefer
> > 'statx' I could go for that.
>
> I prefer something other than xstat and statx(at) seems acceptable enough.
> What I'd really prefer is a name that is less meaninglessly arcane,
> but I haven't thou
> I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I
> could go for that.
I prefer something other than xstat and statx(at) seems acceptable enough.
What I'd really prefer is a name that is less meaninglessly arcane,
but I haven't thought of any good ones.
Thanks,
Rola
> Interesting. I wasn't intending to provide both statx() and statxat()
> variants, just the latter, in which case I'd've though that -at suffix is
> redundant.
It's certainly fine to provide only *at flavors for any new syscall, IMHO.
The * case is always just a simple degenerate case of *at, an
> Roland McGrath wrote:
>
> > statx seems like a better family of names. I also think it's worthwhile to
> > see if the interface can be made to more closely match the AIX precedent.
>
> I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very
> closely, at least from a sysca
On Thu, Apr 26, 2012 at 12:09 PM, Steve French wrote:
> On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
> wrote:
>> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
>>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
>>> wrote:
>>> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wr
On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
wrote:
> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
>> wrote:
>> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
>> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
>
On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
> wrote:
> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
> >> wrote:
> >> > On Thu, 2012-04-26 at 09:54 -0500, Steve Frenc
On Thu, Apr 26, 2012 at 9:28 AM, J. Bruce Fields wrote:
> On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
>> Steve French wrote:
>>
>> > I also would prefer that we simply treat the time granularity as part
>> > of the superblock (mounted volume) ie returned on fstat rather than on
On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
wrote:
> On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
>> wrote:
>> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells
>>
On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
> wrote:
> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells wrote:
> >> > Steve French wrote:
> >> >
> >> >> Would it be better
On Thu, Apr 26, 2012 at 8:47 AM, David Howells wrote:
> Steve French wrote:
>
>> This patch reminds me of a question on time stamps - how can an
>> application query the time granularity ie sb_s_time_gran for a mount
>> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
>> nan
On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
wrote:
> On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 9:25 AM, David Howells wrote:
>> > Steve French wrote:
>> >
>> >> Would it be better to make the stable vs volatile inode number an
>> >> attribute
>> >>
Steve French wrote:
> >> Would it be better to make the stable vs volatile inode number an attribute
> >> of the volume or something returned by the proposed xstat?
> >
> > I'm not sure what you mean by a stable vs a volatile inode number.
>
> Both NFS and CIFS (and SMB2) can return inode number
On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
> On Thu, Apr 26, 2012 at 9:25 AM, David Howells wrote:
> > Steve French wrote:
> >
> >> Would it be better to make the stable vs volatile inode number an attribute
> >> of the volume or something returned by the proposed xstat?
> >
> > I'm
Myklebust, Trond wrote:
> Hmm... As far as I can see you are still doing an nfs_revalidate_inode()
> in the non-forced case. That will cause expired attributes to be
> retrieved from the server.
Revalidation is only done when you force it or explicitly ask for a basic stat
or the data version nu
On Thu, Apr 26, 2012 at 9:25 AM, David Howells wrote:
> Steve French wrote:
>
>> Would it be better to make the stable vs volatile inode number an attribute
>> of the volume or something returned by the proposed xstat?
>
> I'm not sure what you mean by a stable vs a volatile inode number.
Both
On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote:
> Steve French wrote:
>
> > I also would prefer that we simply treat the time granularity as part
> > of the superblock (mounted volume) ie returned on fstat rather than on
> > every stat of the filesystem. For cifs mounts we could
Steve French wrote:
> Would it be better to make the stable vs volatile inode number an attribute
> of the volume or something returned by the proposed xstat?
I'm not sure what you mean by a stable vs a volatile inode number.
> > Should things like the Windows Archive, Hidden and System bits b
On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote:
> J. Bruce Fields wrote:
>
> > > (11) Include granularity fields in the time data to indicate the
> > > granularity of each of the times (NFSv4 time_delta) [Steve French].
> >
> > It looks like you're including this with *each*
Roland McGrath wrote:
> statx seems like a better family of names. I also think it's worthwhile to
> see if the interface can be made to more closely match the AIX precedent.
I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very
closely, at least from a syscall interface p
Paul Eggert wrote:
> On 04/19/2012 09:32 AM, Roland McGrath wrote:
> > I have no comment on the functionality. But "xstat" is probably a poor
> > choice of name.
>
> In AIX 7.1 the (similar) function is called statxat instead of xstat.
> The API isn't exactly the same, but it's the same basic
Roland McGrath wrote:
> I have no comment on the functionality. But "xstat" is probably a poor
> choice of name. There is precedent for that function name with different
> meaning in the userland APIs. (It's a moderately useless meaning inherited
> from SVR4, but regardless overloading a name
Steve French wrote:
> This patch reminds me of a question on time stamps - how can an
> application query the time granularity ie sb_s_time_gran for a mount
> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1
> nanosecond for others etc.)
Ummm... In what context? With the
Steve French wrote:
> I also would prefer that we simply treat the time granularity as part
> of the superblock (mounted volume) ie returned on fstat rather than on
> every stat of the filesystem. For cifs mounts we could conceivably
> have different time granularity (1 or 2 second) on mounts t
J. Bruce Fields wrote:
> > (11) Include granularity fields in the time data to indicate the
> > granularity of each of the times (NFSv4 time_delta) [Steve French].
>
> It looks like you're including this with *each* time? But surely
> there's no filesystem with different granularity (say)
Andreas Dilger wrote:
> > The idea was initially proposed as a set of xattrs that could be
> > retrieved with getxattr(), but the general preferance proved to be
> > for new syscalls with an extended stat structure.
>
> I would comment that it was the opposite. It was originally a
> stat()-like
On Thu, Apr 26, 2012 at 9:50 PM, Stefan Dösinger wrote:
> Am Donnerstag, 26. April 2012, 11:47:51 schrieb Józef Kucia:
>> + DWORD pitch_or_linear_size;
> Are you aware that lPitch is a (signed) LONG in the original DDSURFACEDESC
> structure? Honestly I have no idea why, and I have never seen an
Am Donnerstag, 26. April 2012, 11:47:51 schrieb Józef Kucia:
> +DWORD pitch_or_linear_size;
Are you aware that lPitch is a (signed) LONG in the original DDSURFACEDESC
structure? Honestly I have no idea why, and I have never seen an app that
passes a negative pitch, but it might lead to obscure
Il 26 aprile 2012 11:47, Józef Kucia ha scritto:
> static D3DFORMAT dds_pixel_format_to_d3dformat(const struct dds_pixel_format
> *pixel_format)
> {
> - FIXME("Pixel format conversion not implemented.\n");
> + if (pixel_format->flags & DDS_PF_FOURCC)
> + return dds_fourcc_to_d3dfor
On 26 April 2012 12:13, Józef Kucia wrote:
> On Thu, Apr 26, 2012 at 12:04 PM, Henri Verbeet wrote:
>> Is there no header that should define these?
>
> These structures and defines seem to be defined only in a D3D sample
> "DDS without D3DX".
>
I guess that's ok then.
On Thu, Apr 26, 2012 at 12:04 PM, Henri Verbeet wrote:
> Is there no header that should define these?
These structures and defines seem to be defined only in a D3D sample
"DDS without D3DX".
On 26 April 2012 11:47, Józef Kucia wrote:
> +static HRESULT get_image_info_from_dds(LPCVOID buffer, DWORD length,
> D3DXIMAGE_INFO *info)
Please avoid types like LPCVOID.
Is there no header that should define these?
43 matches
Mail list logo
