> What about a header like ethtool.h? Isn't its whole reason for
> existing to provide a common ABI for ethtool.c and the various
> drivers that support it?
no. this is counter to the
don't-include-kernel-headers-in-userspace-programs policy.
kernel types are not userspace types, kernel namespace isn't userspace
namespace.
> Likewise sockios.h, which ethtool (and no doubt many others) also
> #includes. Unless you're going to encapsulate all possible ioctl
> interfaces into libc, sockios.h (for example) provides a piece of the
> ABI that's needed by the user code, not just by libc. Why would it
> make sense to require retyping of this stuff?
> If, on the other hand, the argument is that user-kernel ABI
> definitions should be isolated in their own headers, and not mixed up
> (hence __KERNEL__), that's a much more restricted argument. My
> impression is that this is *not* the argument though; is it?
If there -must- be parts of the kernel that are visible to userspace,
yes, we should separate them and make that separation obvious. I would
not call our current setup obvious :)
IMHO the current __KERNEL__ "policy" is largely unenforced... It takes
no time at all to find any number of cases (drivers adding ioctls are
the worst) where a header is shared between userspace and kernelspace,
and it pollutes kernel types or structures to userspace, or vice versa.
If we want to avoid the retyping (which is IMHO the most clean
separation for all cases, even if it involves drudgery) then separating
out code into libc-only headers would be nice.
Jeff
-- Jeff Garzik | A recent study has shown that too much soup Building 1024 | can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/