On Wed, Feb 21, 2018 at 11:56:22AM +0200, Igor Stoppa wrote:

On 21/02/18 03:36, Dave Chinner wrote:

quoted

On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:

quoted

On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:

quoted

FWIW, I'm not wanting to use it to replace static variables. All the
structures are dynamically allocated right now, and get assigned to
other dynamically allocated pointers. I'd likely split the current
structures into a "ro after init" 

I would prefer to use a different terminology, because, if I have
understood the use case, this is not exactly the same as __ro_after_init

I want a dynamically allocated "write once" structure.

A "write once" structure is, conceptually, is exactly the same as
"ro after init". Implementation wise, it may be different to
"__ro_after_init", especially when compared to static/global
variables.

It seems lots of people get confused when discussing concepts vs
implementation... :)

quoted

quoted

quoted

	......

No, you'd do:

struct xfs_mount_ro {
	[...]
};

is this something that is readonly from the beginning and then shared
among mount points or is it specific to each mount point?

It's dynamically allocated for each mount point, made read-only
before the mount completes and lives for the length of the mount
point.

quoted

quoted

struct xfs_mount {
	const struct xfs_mount_ro *ro;
	[...]
};

.... so that's pretty much the same thing :P

The "const" modifier is a nice way to catch errors through the compiler,
iff the ro data will not be initialized through this handle, when it's
still writable.

That's kinda implied by the const, isn't it? If we don't do it that
way, then the compiler will throw errors....

Cheers,

Dave.
-- 
Dave Chinner
dchinner at redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html