tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Lockless IP input queue, the pktqueue interface



On Thu, May 29, 2014 at 09:46:22AM -0500, David Young wrote:
> 
> I think that Mindaugas is being pragmatic here.  Developers are not
> equally brilliant[*], observant of the rules, or perceptive of the
> patterns, layers, or abstractions in the code.  He is writing the code
> in a way that discourages us from casually misusing or breaking it by
> getting under the abstraction.  I don't find that offensive.

Indeed, I note that over in tech-kern there is a long running thread
in which a user, trying to debug a problem with NetBSD, complains that
internals of the cd9660 implementation are *not* properly hidden and
are inappropriately exposed in public header files.  He seems shocked
that we do not go (did not go) much farther to hide implementation details
than we do.  I tend to agree.

We ought to make deliberate decisions about what interfaces we will
commit to publishing and expose only those, to the greatest degree
possible.  Exposing guts datastructures to ease grovelling with kmem
seems to me to be exactly the _wrong_ direction to go -- I believe
that kmem grovelling is a pernicious practice and should die (from my
point of view it represents one of the longest-standing major security
issues with NetBSD).

Note that implementation hiding does *not* impede source-level debugging
as if you've got the source, you've got the guts datastructures.

Inappropriately exposing guts also leads to compatibility nightmares and
impedes both necessary repair of poorly designed subsystems, and innovation
in new ones.  If you expose the guts, something _will_ use them, and then
you will be forced to either replace (at the least, recompile) a ton of
random code when you upgrade the kernel, or maintain complex, nasty,
error-prone backwards compatibility code forever.

I think we should design the system so we do _not_ have to replace a dozen
things in /sbin when we replace the kernel.  I certainly do not think we
should go in the other direction.

Thor


Home | Main Index | Thread Index | Old Index