Re: [RFC][MEGAPATCH] Change __ASSEMBLY__ to __ASSEMBLER__ (defined by GCC from 2.95 to current CVS)

[Bill Davidsen <davidsen@tmr.com>]

Kyle Moffett wrote:
> On Sep 12, 2005, at 11:47:56, Paul Jackson wrote:
> 
>> hpa wrote:
>>
>>> The only sane thing is to have a set of ABI headers with a clean,
>>> specific set of rules, which is included by the kernel private  headers,
>>> as well as userspace.
>>>
>>
>> Why must the ABI headers be included by both kernel and user  headers to
>> be sane?
>>
>> Hmmm ... I'm not sure I want to ask that, actually.  I have this  feeling
>> from the tone of your assertion that you can explain to me why such a
>> header organization is the only one that fits your mental model of how
>> these things are structured, but that communication between us may
>> break down when you try to convince me that your mental model for this
>> is the only correct one.
> 
> 
> If we acknowledge the fact that syncing the release dates of two  projects
> is basically futile, especially given that under your system the kernel
> headers would not change much/at-all to make the user-headers project
> easier, then any feature X that appears in a new release of the kernel
> will not be accessible from userspace tools without ignoring the  point of
> the user-headers project all together and having separate headers.   Given
> this, as well as the maintenance burden for those who would need to
> maintain the user-headers (which would be nearly nil if the current
> kernel headers could be cleaned up to the point which they could be used
> instead), this project is lots of messy work either way, but in the long
> run, if included into the upstream kernel, it will result in much less
> duplication of effort and much cleaner code.

The issue, as I see it, is not that the nifty new ioctl doesn't become 
instantly available, although that's not a small benefit of having one 
and only one set of user headers. The real benefit is avoiding the case 
where some part of the API *changes* and some feature stops working.

This is obviously uncommon, but not unheard of.

I see the greatest benefit from just not having two sets of headers, I 
believe all that stuff I learned in CS classes about not having two 
copies of stuff and assuming that they're the same. It would be less 
work to clean up the headers once, and let the folks who now maintain 
the separate headers become the "kernel janitors" to keep it clean.

Not my job, but we have someone offering to do the first cut at it, and 
it seems a desirable end result.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me