Re: [PATCH] style(5): No struct typedefs

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [...] 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B