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 [EMAIL PROTECTED] /
/_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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
