Page MenuHomeFreeBSD

jail: define well-known parameter names in sys/jail.h
ClosedPublic

Authored by seuros on Thu, Sep 10, 2:36 PM.
Tags
None
Referenced Files
F171620875: D59572.id186386.diff
Sat, Sep 12, 5:57 AM
F171589111: D59572.diff
Fri, Sep 11, 11:05 PM
F171588876: D59572.diff
Fri, Sep 11, 11:02 PM
F171578788: D59572.id.diff
Fri, Sep 11, 9:17 PM
F171555270: D59572.id186408.diff
Fri, Sep 11, 5:57 PM
F171523162: D59572.id186406.diff
Fri, Sep 11, 2:15 PM
F171494839: D59572.id186405.diff
Fri, Sep 11, 11:25 AM
Unknown Object (File)
Fri, Sep 11, 7:45 AM
Subscribers

Details

Summary

Userland jail managers hardcode jail parameter name strings; nothing
in the headers has ever named them, even when sys/jail.h already
has JAIL_META_PRIVATE/JAIL_META_SHARED for the metadata pair.

Added JAIL_PARAM_* string constants for the static parameters registered
by the base kernel.

No functional change.

MFC After: 1 week

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 76749
Build 73632: arc lint + arc unit

Event Timeline

i like this; it makes it much easier to write code that works by correctly using defines rather than hoping the strings match.

I'll approve it but let me first double check with phk or some other jails-y person before landing it.

This revision is now accepted and ready to land.Thu, Sep 10, 3:19 PM

(and subsequent commits should use these defines instead of hard-coded strings..)

It would make sense to broaden their use, with bare string literals also being used in vfs_copyopt and vfs_setopt calls.

Broaden constant use to vfs_copyopt/vfs_setopt call sites and the jail(2) compat iovecs, per jamie. Adds JAIL_PARAM_DESC/LASTJID/NODYING for the pseudo-params those paths use.

This revision now requires review to proceed.Thu, Sep 10, 6:28 PM
sys/sys/param.h
77 ↗(On Diff #186405)

Why do we need to bump version here?

Now that I think about it, jail(8) and jls(8) code is also rife with these strings.

Now that I think about it, jail(8) and jls(8) code is also rife with these strings.

Right; we can fix those but after this commit. This commit doesn't change their values, it just adds a level of indirection to them.

seuros marked an inline comment as done.

refactor userland

nooooo please do the userland refactor as a follow-up commit. The kernel refactor doesnt change the string contents at all.

Right; we can fix those but after this commit. This commit doesn't change their values, it just adds a level of indirection to them.

I was testing the world , that why i pushed the version bump. I reverted the version bump.

The headers only didn't need it, but now we have the full refactoring.

This change also can be backported to 15.

nooooo please do the userland refactor as a follow-up commit. The kernel refactor doesnt change the string contents at all.

Ok.

This revision is now accepted and ready to land.Thu, Sep 10, 6:59 PM

thanks! lets clean up userland after this.

(the only reason we'd bump version is if we started to write ports/external software that uses these..)

Right; we can fix those but after this commit. This commit doesn't change their values, it just adds a level of indirection to them.

I was testing the world , that why i pushed the version bump. I reverted the version bump.

Can you expand on this a little more? You shouldn't have needed a version bump for buildworld, for instance, because clang should have emitted the header as a dependency that bmake acknowledges would made the including object files out of date (even without metamode or anything fancy)?

Can you expand on this a little more? You shouldn't have needed a version bump for buildworld, for instance, because clang should have emitted the header as a dependency that bmake acknowledges would made the including object files out of date (even without metamode or anything fancy)?

right, but the bump for my workspace, i had other unrelated commit prior that needed invalidation.
So when i was asked to push a fix, i committed that extra local file by mistake.