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. 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.
The list of policies is just built internally when you dump out a policy
with its sub-policies for nested attributes/arrays.
johannes
