Re: RFC: please put back spare fields in struct ifnet (removed in svn 270870)

From: Gleb Smirnoff <glebius_at_FreeBSD.org>
Date: Tue, 9 Sep 2014 14:37:19 +0400
  Luigi,

On Tue, Sep 09, 2014 at 12:13:42PM +0200, Luigi Rizzo wrote:
L> svn 270870 removed all the if_*spare fields in struct ifnet.
L> They are replaced with the following comment
L> 
L> /*
L>  * Spare fields to be added before branching a stable branch, so
L>  * that structure can be enhanced without changing the kernel
L>  * binary interface.
L>  */
L> 
L> ​which leaves me a bit unhappy.
L> Having a stable ABI is useful not only for stable branches,
L> but also (I would say even more) with head, so people can
L> run experimental code with limited modifications to the sources.
L> 
L> Cases in point:
L> - we used one spare field extensively when experimenting
L>   with netmap, and being able to just build a module without having
L>   to recompile the whole kernel was a big win.
L> - we are developing some software GSO and again it was great to have
L>   the spares in the tcpcb and in the ifnet so we could limit
L>   modifications to headers used by multiple sources.
L> 
L> I would kindly suggest to put the spares back.
L> I can't see how they can possibly harm.

The harm is obvious: someone commits code that _uses_ spare field
without assigning it a new name. Spare field is a placeholder. Of
course you can use it while you experiment. However, I don't see
problem with patching your source tree where you experiment.

The ABI plan for 'struct ifnet' is that the struct becomes
opaque for device drivers. So its size and alignment no longer
matters. Those who want to add new fields to struct ifnet,
would also need to add accessor methods. Bits of this plan
are already committed by Marcel, but its only first step.

I'm afraid that if fields are there back, the situation that
happened with netmap (use of spare field) would repeat.

-- 
Totus tuus, Glebius.
Received on Tue Sep 09 2014 - 08:37:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC