On Fri, Apr 26, 2019 at 09:14:43PM +0200, Johannes Berg wrote:
> On Fri, 2019-04-26 at 20:04 +0200, Pablo Neira Ayuso wrote:
> > On Fri, Apr 26, 2019 at 07:28:15PM +0200, Johannes Berg wrote:
> > > On Fri, 2019-04-26 at 19:17 +0200, Johannes Berg wrote:
> > > >
> > > > Ideally, we'd add this as
> > > >
> > > > {
> > > > .cmd = XYZ,
> > > > .doit = do_xyz,
> > > > .dumpit = dump_xyz,
> > > > .attrs = { ATTR_A, ATTR_B, ATTR_C, ATTR_D },
> > > > }
> > > >
> > > > but of course there's no good way to express this in C, you'd have to
> > > > build an out-of-line array and point to it.
> > >
> > > Actually, it's possibly even more complicated. After all, it is possible
> > > that you have an ATTR_N, that is nested, and that contains certain sub-
> > > attributes (ATTR_N_A, ATTR_N_B, ...) of which only some are valid for
> > > the operation X, but a different subset is valid for operation Y.
> >
> > I solved this in my patchset through the object ID. So each command
> > points to an object ID, then such object ID comes with a list of
> > attributes.
>
> Yeah, ok. Each object you had is basically its own policy.
Hm, not necessarily.
The object id is matching to the "root policy". Several commands may
have the same "root policy" (or as I call it "object id"). For
example, in netfilter we have commands to add and to delete rules,
both would have the same "root policy".
> I just *removed* having a separate policy for each command in
> generic netlink, as ;-)
>
> What really I think we should have is a common policy, but only some
> attributes are valid in some commands.
>
> I guess you can slice this in different ways. From a "how much space
> does this consume" and "can I reuse some code across different commands"
> I think having the same policy is a good idea though.
>
> > If we use the list policies that you propose, then it's just an extra
> > enumeration to maintain for each command. And many commands will
> > likely reuse the same object ID.
>
> A policy pointer, really.
Sort of, but it has to be stable along time for userspace, right?
Actually, it's an ID.
> The list of policies is just built internally when you dump out a policy
> with its sub-policies for nested attributes/arrays.
If we expose these to userspace, we need that these object IDs are
stable, hence the enum. So userspace results in a simple program that
just makes look ups for the object ID that contains the description of
the attributes that are available.
