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
