James,
No. You've got it backwards. 0 is false, any non-zero value is true.
if(desc) would be equal to if (desc != 0).
- Patrick
On 05/16/2016 01:16 PM, James Simmons wrote:
This looks wrong - You return -EINVAL from sptlrpc_pack_user_desc, but then
the caller checks "!desc". Desc will no
Greg just recently replied to a similar patch rejecting it. I don't have his
response handy, but I bet you can find it in the archives. Briefly, this hides
possible errors rather than fixing them.
From: lustre-devel [lustre-devel-boun...@lists.lustre.org
Actually, commit message looks malformatted. Signed-off-by line is not
the last line. Not sure if that's a problem for Greg or not.
On 07/13/2015 07:50 AM, Patrick Farrell wrote:
Looks good, thanks!
From: HPDD-discuss [hpdd-discuss-boun...@lis
Looks good, thanks!
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 9:22 PM
To: oleg.dro...@intel.com; andreas.dil...@intel.com;
gre...@linuxfoundation.org; de...@driverd
This changes the logic here; the assignment is done conditionally based on the
precheck.
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Perry
Hooker [perry.hoo...@gmail.com]
Sent: Sunday, July 12, 2015 4:27 PM
To: oleg.dro...@intel.co
Since it is not actually doing a printk - at least, not necessarily - I like
lustre_logmsg. lustre_output seems too vague.
- Patrick
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Joe Perches
[j...@perches.com]
Sent: Friday, May 22,
path.dentry,
+ NULL, 0, it);
On 03/18/2015 02:31 PM, Patrick Farrell wrote:
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM,
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+ rc = ll_intent_file_open(file->f_path.dentry,
+
Ashley,
I sort of understand your larger point, but in this case, I think the purpose
of the assert is much better served by the move Rickard is suggesting.
Otherwise only one of its conditions will ever trigger. It's not that
different to die on the assertion or from a null dereference, but
Strongly agreed that execution speed is not critical here. It's the update of
a proc variable, not a tight loop or critical section.
Normally I'd leave it alone, but since you're writing a patch anyway, I'd do
'tolower' myself. I dislike the stacked case statements on a single line like
that.
Dan,
I disagree about the change suggested here. In this particular code,
'object_attr' is distinct from 'attr', as in a 'setattr' call on an inode.
'cl_object' is a distinct thing from an inode/file on disk, and specifying it
is the objects attr is helpful in understanding there is not a dir
11 matches
Mail list logo
