freebsd
from(1): Capsicumise
@kfv What's the status here? As far as I can tell, it's been requested that you use the capsicum_helper routines instead w/o a response for a long time.
Hi, apologies for the extended delay in addressing the requested changes. The past year has been personally and geopolitically challenging, and I appreciate your patience. I make sure to go through all the pending requests within the coming week at most. Thank you again for your understanding.
@bsdimp, @markjdb: Made the changes as Mark said — should be good to ship now, I reckon.
So a few comments. The code looks OK to my eye. But I'd drop:
- from(1): Remove braces from single-line conditional statements for consistency to meet style(9) compliance
And there needs to be a blank line before the Signed-off-by lines. And
Needs to have a little more of a description. Something like "Limit what we can do by calling ceph_xxxxx and ceph_yyy" after a blank line. And there should be a blank line before the SOB line.
from(1): Remove braces from single-line conditional statements for consistency to meet style(9) compliance
+1.
from(1): Add blank line after kernel include files to meet style(9) compliance from(1): Replace magic exit codes with standard macros
I would merge this two commits. I don't think blank line requires a special commit.
One more thing :)
Add missing include file
Why actually we need errno.h? It's unclear for me from the commit msg and from the code.
One more thing :)
Add missing include file
Why actually we need
errno.h? It's unclear for me from the commit msg and from the code.
jlduran@ previously suggested adding it back when I was using <sys/capsicum.h>. I’m fairly certain you're correct and it’s no longer necessary, therefore I remove it now.
But I'd drop: from(1): Remove braces from single-line conditional statements for consistency to meet style(9) compliance
This one was not dropped. But I guess I can omit while committing, if its ok with you.
But I'd drop: from(1): Remove braces from single-line conditional statements for consistency to meet style(9) compliance
This one was not dropped. But I guess I can omit while committing, if its ok with you.
I am fine with you omitting it, but I still believe updating non-compliant statements to meet style(9) would help maintain consistency and promote adherence to the standard, so my preference would be to keep it.
By the way, I have corrected the commit description for the first commit.
I am fine with you omitting it, but I still believe updating non-compliant statements to meet style(9) would help maintain consistency and promote adherence to the standard, so my preference would be to keep it.
Actually the style(9) allows both if I read it correctly.
In my private opinion the {} help with the readability. But its my private opinion.
Actually the style(9) allows both if I read it correctly. In my private opinion the
{}help with the readability. But its my private opinion.
I agree that style(9) permits both options, but it does specify:
Space after keywords (if, while, for, return, switch). Two styles of braces (
{and}) are allowed for single line statements. Either they are used for all single statements, or they are used only where needed for clarity. Usage within a function should be consistent.
The instances I have updated don't require braces for clarity, and since the code already includes several braceless statements, I believe maintaining consistency—either using braces or omitting them—would be preferable.
If you think my reasoning is valid, I can document it in the commit description. However, if I’ve misunderstood style(9), feel free to correct me.