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
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
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...@lists.01
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;
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:
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,
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,
+
,
+ 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, p...@amd48-systeme.lip6.fr wrote
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
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
11 matches
Mail list logo
