Re: Lockless IP input queue, the pktqueue interface

[Darren Reed <darrenr%netbsd.org@localhost>]

On 29/05/2014 5:06 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed <darrenr%netbsd.org@localhost> wrote:
> > > No, there is no need to expose the structure.  Even if there would be
> > > another internal component using the structure(s) one should consider
> > > accessors/mutators.  Even if that component would have a good reason
> > > not to use accessors/mutators, the structure should be placed under
> > > #ifdef __SUBSYSTEM_PRIVATE (and certainly #ifdef _KERNEL).  However,
> > > I strongly discourage to start from the last step without having a
> > > necessity first.
> > >
> > > One of the main reasons why we ended up with our network stack being
> > > such a mess is exactly this: the internal structures are exposed and
> > > accessed all over the place, there is a lack of strict interfacing,
> > > and the information hiding principle is not followed.
> > So if someone were to write a program to grovel through a crash dump
> > or /dev/mem and print out these structures, how would they get the
> > definition of it?
> This is getting off-topic, but for the sake of wondering readers:
>
> Serialize and export the structure, or create a wrapper structure used
> for data transportation, or implement interface with accessors/mutators.
> If you think that you should be able to fiddle with any structure in the
> kernel (as it would be 1980s) then you are plain wrong (do I really need
> to explain this?).

Your justification for including the structure in the .c file is that
developers can't betrusted to not use header files that clearly aren't
public interfaces. That's what code review is for and puts the focus of
what you're arguing as being a "human problem" and not a "technology
problem." You can't solve "human problems" with technology. Putting the
structure there won't stop determined people, it will just make it harder
and they'll begrudge NetBSD for making their life harder.

Putting structures inside a .c file represents a very short term view
of how the implementation willevolve and be used.

The method that I've seen used in Solaris (for example) is to use
foo_impl.h to providethe details of data structure that are essentially
private and those .h filesmay or may notbe shipped as part of the end
user system.Using pktqueue_private.h might be suitable.

Arguing that idealism from a certain period of time is no longer valid
requires invoking another form of idealism and leaving behind being
pragmatic.

But if you're dead set on taking this approach, feel free to ignore
my suggestions and what I've seen done in other platforms. I can't
stop you any more than I can stop it raining.

Darren