On Thu, 2018-09-13 at 18:58 -0300, Marcelo Ricardo Leitner wrote: > > It would be easier and IMHO cleaner if I could simply list these "read > > only attributes" with NLA_REJECT policy for "set" request. > > Not that I'm against this. Point was fields that are considered output > only today are probably being silently ignored, and we can't change > them to be NLA_REJECT as it would break user applications. Indeed. > Then we > will have fields that are rejected, and those old that are not. In the > long run, nearly all output fields would be marked as NLA_REJECT, > okay. Perhaps, yes, though I assume it would only really be true for new families that bother to mark as such. > Then I ask my first question again: why reject these? They are not > hurting anything, are they? It's different from your example I think. > In there, the extra information which was ignored leads to a > different behavior. So in one case I was thinking of, there are some fields that simply cannot be used for input, they're only used for output. But it may not always be obvious to somebody using the API. Thus, I think it makes sense to instruct the kernel to reject that, so that whoever gets confused has immediate feedback that their usage is wrong. If we ignore that, they may not realize their error immediately. I think the ethtool case is similar: you can read and write some fields, and only read others - but if you try to write the read-only fields would you prefer to be told "sorry, this is not possible" vs. it being silently ignored? I'd definitely prefer the former. > Maybe it would be better to have NLA_IGNORE instead? </idea> I don't think so, it doesn't give any feedback to the application author that they're doing something wrong. johannes
