On Fri, 2017-04-07 at 12:55 -0700, David Miller wrote:
>
> One idea. We use the macro thing to generate a "netlink.pot" file
> and then some userland tree can contain the latest netlink.pot and
> the translations.
Right. For the record - since we just talked about it - I was thinking
of putting
From: Johannes Berg
Date: Fri, 07 Apr 2017 21:46:46 +0200
> On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote:
>> I suspect that someone will eventually give us a hard time about the
>> strings wrt. internationalization. :-) It's solvable at least
>> partially in
On Fri, 2017-04-07 at 21:45 +0200, Pablo Neira Ayuso wrote:
>
> We only need to store the pointer to the attribute in the error
> container structure. We can calculate the offset from nl_err() by
> pasing the skbuff as parameter there, right?
Ah, that's a good point, we could store the nlattr
On Fri, 2017-04-07 at 12:43 -0700, David Miller wrote:
>
> I have no strong opinions about string length.
>
> In my opinion, I would like to believe that if someone tried to get a
> networking patch applied that emitted a rediculously long string then
> we would give them feedback about how that
On Fri, Apr 07, 2017 at 09:29:17PM +0200, Johannes Berg wrote:
> On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote:
> > I think the most flexible way is to pass the container error
> > structure to nla_parse() so it sets this for you. This would also
> > save tons of "malformed attribute"
From: Pablo Neira Ayuso
Date: Fri, 7 Apr 2017 21:35:50 +0200
> On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote:
> [...]
>> Let's just discuss the UAPI, since people complain we don't talk
>> about that enough :-) For those playing at home it is three new
>>
On Fri, Apr 07, 2017 at 12:20:53PM -0700, David Miller wrote:
[...]
> Let's just discuss the UAPI, since people complain we don't talk
> about that enough :-) For those playing at home it is three new
> attributes returned in a netlink ACK when the application asks
> for the extended response:
>
From: Pablo Neira Ayuso
Date: Fri, 7 Apr 2017 21:27:14 +0200
> On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote:
>> From: Johannes Berg
>> Date: Fri, 07 Apr 2017 21:09:45 +0200
>>
>> > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira
From: Pablo Neira Ayuso
Date: Fri, 7 Apr 2017 21:21:34 +0200
> For my usecases in netfilter, the attributes and an specific error
> code should be enough to figure out what is wrong. Will not need
> strings.
>
> BTW, we may not have an offset, eg. EINVAL because of missing
On Fri, 2017-04-07 at 21:27 +0200, Pablo Neira Ayuso wrote:
>
> > Also another way to look at this is that we're providing a lot of
> > new power and expressability. So even if only one aspect of the
> > new error reporting is used it's a positive step forward.
True.
> > So allow offset "0"
On Fri, 2017-04-07 at 21:21 +0200, Pablo Neira Ayuso wrote:
>
> For my usecases in netfilter, the attributes and an specific error
> code should be enough to figure out what is wrong. Will not need
> strings.
Fair enough.
> BTW, we may not have an offset, eg. EINVAL because of missing
>
On Fri, Apr 07, 2017 at 12:22:23PM -0700, David Miller wrote:
> From: Johannes Berg
> Date: Fri, 07 Apr 2017 21:09:45 +0200
>
> > On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote:
> >> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
> >> [...]
On Fri, 2017-04-07 at 12:20 -0700, David Miller wrote:
> But what it lacks fundamentally is context. Therefore it can't be
> used to provide the offset or the bad attribute number. So it can't
> meet our requirements.
Yes, it doesn't address the requirements here, and in a sense I suspect
this
From: Johannes Berg
Date: Fri, 07 Apr 2017 21:09:45 +0200
> On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote:
>> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
>> [...]
>> > Heh. I think I really want to solve - at least partially -
>> >
From: Johannes Berg
Date: Fri, 07 Apr 2017 20:59:12 +0200
> Alexander Shishkin's patch
> https://patchwork.kernel.org/patch/7162421/
>
> was nice in a way because you could get away without passing the error
> structure down all the time, but like I said it doesn't
On Fri, Apr 07, 2017 at 09:09:45PM +0200, Johannes Berg wrote:
> On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote:
> > On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
> > [...]
> > > Heh. I think I really want to solve - at least partially -
> > > nla_parse()
> > > to see
On Fri, 2017-04-07 at 21:06 +0200, Pablo Neira Ayuso wrote:
> On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
> [...]
> > Heh. I think I really want to solve - at least partially -
> > nla_parse()
> > to see that it can be done this way. It'd be nice to even transform
> > all
> >
On Fri, 2017-04-07 at 21:02 +0200, Pablo Neira Ayuso wrote:
>
> > I'm tempted to apply this as-is just to show that person that
> > things do in fact happen eventually :-)
>
> We can just send follow up patches to refine, I think it's a good
> start, Johannes?
I guess we can. Like I just
On Fri, Apr 07, 2017 at 08:59:12PM +0200, Johannes Berg wrote:
[...]
> Heh. I think I really want to solve - at least partially - nla_parse()
> to see that it can be done this way. It'd be nice to even transform all
> the callers (I generated half of these patches with spatch anyway) to
> have at
On Fri, Apr 07, 2017 at 11:53:15AM -0700, David Miller wrote:
> From: Johannes Berg
> Date: Fri, 7 Apr 2017 20:26:17 +0200
>
> > So this is my first draft of what we'd talked about at netconf.
> > I'm not super happy with the way we have to pass the extended
> > error
On Fri, 2017-04-07 at 11:53 -0700, David Miller wrote:
> > Alexander Shishkin had a nice way of reporting static extended
> > error data, but that isn't really suitable for reporting the
> > offset or even reporting the broken attribute from nla_parse().
> >
> > Speaking of nla_parse(), that'll
From: Johannes Berg
Date: Fri, 7 Apr 2017 20:26:17 +0200
> So this is my first draft of what we'd talked about at netconf.
> I'm not super happy with the way we have to pass the extended
> error struct, but I don't see a way to implement reporting any
> dynamic
So this is my first draft of what we'd talked about at netconf.
I'm not super happy with the way we have to pass the extended
error struct, but I don't see a way to implement reporting any
dynamic information (like error offsets) in any other way.
Alexander Shishkin had a nice way of reporting
23 matches
Mail list logo