Re: Linus's include file strategy redux

[Werner Almesberger <Werner.Almesberger@epfl.ch>]

LA Walsh wrote:
> 	I think in my specific case, perhaps, linux/malloc.h *is* a public
> interface that is to be included by module writers and belongs in the
> 'public interface dir -- and that's great.  But it includes files like
> 'slab.h' which are kernel mm-specific that may change in the future.

As far as I understand the scenario you're describing, this seems to
be the only problem. <public>/malloc.h shouldn't need to include
<private>/slab.h.

If there's anything <private>/slab.h provides (either directly or
indirectly) that is needed in <public>/malloc.h, that should either be
in another public header, or malloc.h actually shouldn't depend on it.

Exception: opaque types; there one would have to go via a __ identifier,
i.e.

<public>/foo.h defines  struct __foo ...;
<public>/bar.h includes <public>/foo.h
               and uses #define FOOSIZE sizeof(struct __foo)
<private>/foo.h either  typedef struct __foo foo_t;
                or      #define foo __foo  /* ugly */

Too bad there's no  typedef struct __foo struct foo;

I don't think restructuring the headers in this way would cause
a long period of instability. The main problem seems to be to
decide what is officially private and what isn't.

> 	Any other solution, as I see it, would break existing module code.

Hmm, I think what I've outlined above wouldn't break more code than
your approach. Obviously, modiles currently using "private" interfaces
are in trouble either way.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/