>> [...] as I see it the divide you're sketching here ([...]) is the >> divide between interface and implementation, and in some cases the >> interface is more than just the typedefs.
> Sort of. > <sys/typedefs/vnode.h> // contains the "vnode_t" opaque type definition > <sys/impl/vnode_impl.h> // contains the guts of "struct vnode" and the other > implementation details > <sys/mount.h> // Contains some of the file system interfaces, some of which > use vnode_t > <sys/vnode.h> // Contains the vnode interfaces, which definitely use vnode_t > The latter if the two would each include <sys/typedefs/vnode.h>. You're right, I hadn't fully understood you. Hmm. What value is provided by separating the vnode_t type from the rest of the vnode interface (in <sys/vnode.h>)? If taken to its logical extreme (which of course ends up at a satirical position, like most logical extremes), this leads to <sys/typedefs/vnode.h> // vnode_t <sys/enums/vtype.h> // enum vtype <sys/enums/vtagtype.h> // enum vtagtype <sys/defines/VNODE_TAGS.h> // #define VNODE_TAGS <sys/structs/vnlock.h> // struct vnlock <sys/defines/IO_UNIT.h> // #define IO_UNIT <sys/defines/IO_APPEND.h> // #define IO_APPEND .... which I hope you agree is madness. What makes it worth singling out vnode_t for special treatment here? I would prefer to draw include-file boundaries more or less matching conceptual-API boundaries, which I thought was more or less where we started: <sys/vnode.h> defines the API to the vnode subsystem, including types, #defines, externs, etc. But I'm not sure how that would differ from what we have now. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B