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

On Tue, Sep 9, 2014 at 2:17 PM, Gleb Smirnoff <glebius_at_freebsd.org> wrote:

>   Luigi,
>
> On Tue, Sep 09, 2014 at 01:01:13PM +0200, Luigi Rizzo wrote:
> L> > The harm is obvious: someone commits code that _uses_ spare field
> L> > without assigning it a new name. Spare field is a placeholder. Of
> L> > course you can use it while you experiment. However, I don't see
> L> > problem with patching your source tree where you experiment.
> L>
> L> The problem with _not_ having spares is that you have to recompile
> L> everything after patching the headers. With the spares, i could
> L> make netmap a simple add-on kernel module with no dependencies.
> L> Same on linux for what matters (there wasn't a spare there, but
> L> nobody used ax25 and i could check and reuse it).
>
> What if another kernel hacker comes and also uses if_pspare[0] for
> his own super-duper feature? What would you do, if then a user
> reports that enabling netmap on his box instapanics if he had
> some other feature turned on?
>

​i'll live with that if there is contention
and the use of the pspare is not checked
(in linux i do check that the pointer is not used
before trying to use it).

With the removal of the spares we remove the risk
but also prevent people from loading the module without
recompiling the whole kernel. That is a bit too radical
as a path to safety.
It's like saying that rather than seat belts and airbags
we should not drive to reduce our
chances of being involved in a car accident.



> L> > The ABI plan for 'struct ifnet' is that the struct becomes
> L> > opaque for device drivers. So its size and alignment no longer
> L> > matters. Those who want to add new fields to struct ifnet,
> L> > would also need to add accessor methods. Bits of this plan
> L> > are already committed by Marcel, but its only first step.
> L>
> L> ​spare fields <-> spare accessors​
>
> Let me repeat: in future device drivers will not be capable
> to dereference struct ifnet. So, any feature pointers would
> be accessed via functions, making struct ifnet no longer part
> of ABI. This hasn't yet happened, but one already can (and
> should!) use accessors in any new code.
>
>
let me repeat too :)

My point is preserving support for out of tree modules,
and spares (or spare accessors, or the ABI you mention below;
something that gets you quickly a vendor specific pointer
from an opaque ifnet) were useful for that.

I think the removal of spares should have happened together
with the commit of the new mechanism. If it is ready now,
let's move with it and be done with this discussion.

If not, I would like to bring back the pspares
with a big note summarizing this discussion,
and remove then when the new mechanism is ready.
If i read correctly your comment below about
the "properly named placeholder" you seem to be ok with that ?

cheers
luigi

L> > I'm afraid that if fields are there back, the situation that
> L> > happened with netmap (use of spare field) would repeat.
> L>
> L> ​the spare pointer used by netmap was clearly indicated by a comment,
> L> and giving it a dedicated name instead of if_pspare[0] was
> L> expected to happen (hopefully together with a __FreeBSD_version bump,
> L> which has not happened).
>
> I don't agree that /* 1 netmap, 7 TDB */ is a clear comment. I
> understood as "in future one of those is to be used for netmap".
>
> Regarding __FreeBSD_version: the field should have been renamed
> in the commit that brought in netmap, not in my commit. My commit
> removed a field that must not be used, so it is not a reason
> to bump.
>
> If you need closest __FreeBSD_version for the change, then
> please use 1100030, it happened next day.
>
> L> I am not worried that the name change was missed when deleting
> if_pspare[].
> L> Mistakes happen and the error was promptly corrected (apart from the
> L> version bump).
> L>
> L> What worries me is losing some flexibility in dealing with
> L> out-of-tree kernel modules.
>
> Just put a properly named placeholder for them as a quick solution.
>
> A nicer solution would be to add an API for storing vendor-specific
> pointers on ifnet, providing a cookie. I'm discussing that now with
> kmacy_at_, who also thinks in that direction.
>
> --
> Totus tuus, Glebius.
>



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo_at_iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
 TEL      +39-050-2211611               . via Diotisalvi 2
 Mobile   +39-338-6809875               . 56122 PISA (Italy)
-----------------------------------------+-------------------------------