Message ID | 20171112231511.4666-1-linux@rasmusvillemoes.dk |
---|---|
Headers | show |
Series | net: core: devname allocation cleanups | expand |
On Mon, 13 Nov 2017 00:15:03 +0100 Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > It's somewhat confusing to have both dev_alloc_name and > dev_get_valid_name. I can't see why the former is less strict than the > latter, so make them (or rather dev_alloc_name_ns and > dev_get_valid_name) equivalent, hardening dev_alloc_name() a little. > > Obvious follow-up patches would be to only export one function, and > make dev_alloc_name a static inline wrapper for that (whichever name > is chosen for the exported interface). But maybe there is a good > reason the two exported interfaces do different checking, so I'll > refrain from including the trivial but tree-wide renaming in this > series. > > Rasmus Villemoes (7): > net: core: improve sanity checking in __dev_alloc_name > net: core: move dev_alloc_name_ns a little higher > net: core: eliminate dev_alloc_name{,_ns} code duplication > net: core: drop pointless check in __dev_alloc_name > net: core: check dev_valid_name in __dev_alloc_name > net: core: maybe return -EEXIST in __dev_alloc_name > net: core: dev_get_valid_name is now the same as dev_alloc_name_ns > > net/core/dev.c | 62 +++++++++++++++++++++------------------------------------- > 1 file changed, 22 insertions(+), 40 deletions(-) > Looks good to me. Can't see anything obviously wrong with this. I think the two functions started out heading in different directions.
From: Rasmus Villemoes <linux@rasmusvillemoes.dk> Date: Mon, 13 Nov 2017 00:15:03 +0100 > It's somewhat confusing to have both dev_alloc_name and > dev_get_valid_name. I can't see why the former is less strict than the > latter, so make them (or rather dev_alloc_name_ns and > dev_get_valid_name) equivalent, hardening dev_alloc_name() a little. > > Obvious follow-up patches would be to only export one function, and > make dev_alloc_name a static inline wrapper for that (whichever name > is chosen for the exported interface). But maybe there is a good > reason the two exported interfaces do different checking, so I'll > refrain from including the trivial but tree-wide renaming in this > series. Series applied, thanks.