lkml.org 
[lkml]   [2000]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateFri, 15 Dec 2000 22:21:17 +0100
FromWerner 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/
\
 
 \ /
  Last update: 2005-03-22 12:52    [from the cache]
©2003-2010