[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cleaning up kernel's headers for userspace



On Tue, 2006-04-25 at 17:03 +0000, Tim Yamin wrote: 
> > We used to occasionally receive complaints that this was Fedora-specific
> > 'breakage', and upstream maintainers were sometimes reluctant to fix
> > their abuse of header files.
> 
> Indeed, which is why we took the other approach to this problem since we
> need things to compile to our users, not just package maintainers :)

Yes, but you still ship bug-fix patches which fix things when the
upstream tarball is broken, surely? You're not just held hostage to
broken upstream maintainers, although of course it's _better_ when we
can get stuff fixed upstream.

> Hm, I quite like the idea of the #warning. And for files that are
> blatantly pure __KERNEL__ we can just do:
> 
> #warning "<linux::asm-arch/blah.h>: this header is deprecated, fix yer shizzle!"
> #endif

We really don't need that for 99% of the kernel-private files, and I
think it's overkill to do that kind of thing when we can just remove the
files.

If you really want to accommodate code which is known to be broken not
just in theory but also in practice, then we can annotate asm/atomic.h
that way for a while in the upstream kernel before we remove it from the
'export' list in a few months' time. Are there other private files you'd
want to do that for?

> > > But I don't think it is realistic that kernel developers will start
> > > fixing their header files for user inclusion. In most cases you will
> > > get only negativ feedback if you send patches, which fixes header
> > > files for userland inclusion.
> 
> This has been a problem in the past. The other problem has been fixing
> glibc so it includes headers in a sane way in places (we also got negative
> feedback there when we tried).

Can you be specific about what was requested, and how it would have
helped? I'm sure Uli has no intention of making it harder for us to make
progress with cleaning up the kernel headers.

That subject might be best pursued with a pruned Cc list.

> What we really need is not random kernel devs but arch maintainers. So
> anything that goes in asm-arch "works".

I think we need _both_ types of developer to actually care about how
their header files look in userspace.

> When I get some time I'll look into x86+ia64.

Cool, thanks.

-- 
dwmw2



Reply to: