Messages in this thread |  | | | Date | Fri, 15 Dec 2000 22:21:17 +0100 | | From | Werner Almesberger <> |
| |
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/
|  |