lkml.org 
[lkml]   [2010]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Process to push changes to include/linux/types.h
On Thu, 14 Oct 2010 15:34:52 -0400
Eric Paris <eparis@redhat.com> wrote:

> A patch was posted a bit ago by agruen which made a change to
> include/linux/types.h changing aligned_u64 to __aligned_u64 and exposing
> this new type to userspace.
>
> http://marc.info/?l=linux-kernel&m=128316627912457&w=2
>
> Everyone seemed to agree the patch was a good idea and was correct. At
> the moment this change only really affects network code, but I would
> very much like to make use of this change in the notification tree.
> Dave Miller did not apply the patch because "Someone has to first add
> the types to linux/types.h, and that doesn't go through my tree."
>
> http://marc.info/?l=linux-kernel&m=128634544524035&w=2
>
> I'm a little stuck as to the right path forward. I normally would have
> had no qualms about adding __aligned_u64 to types.h in the notification
> tree and pushing it to Linus next go-round and then the net tree could
> convert and potentially drop the old aligned_u64 type (but again that
> would be outside the net tree). Since Dave isn't willing to add the
> type and I don't want to get called too many bad names, I figured I
> should try to find if there is some better way, maintainer, or tree who
> should be adding this new type.
>
> Who needs to sign off on a new type in types.h? Who should add it?
> Should I just ram it on in there myself, take any flames that come
> along, and then let net finish their cleanups after I've been charred?
> Any suggestions on the best course of action would be appreciated.
>

The usual approach here is someone sends it to me and I send it to
Linus ;)

If the change is simple, obviously safe and is needed in two or more
subsystem trees then I'll usually sneak it into mainline late in -rc,
simply to make everyone's life easier. Of course, you could both agree
to merge the same patch into local trees and I assume that git will
sort it all out.

For this particular patch I'd suggest it be split into two: one adds
the new __aligned_u64 and friends. The second patch kills off
aligned_u64 and friends. I'd say the first four-liner would then be
safe for immediate merge and the cleanup patch can go in any old time.



Regarding the patch itself: it uses open-coded
__attribute__((aligned(...))), however we have the __aligned(...)
helpers in compiler.h.

I'm always a bit ambivalent about those helpers (__packed, etc).
They're not a very kernely thing to do, but the gcc __attribute__
syntax really is a mouthful.

And adding a compiler.h dependency to the shared-with-userspace types.h
may not be practical or safe, dunno.


So if this works, I'd suggest preparing the simple four-liner with the
intention of an immediate merge.



\
 
 \ /
  Last update: 2010-10-14 21:57    [W:0.045 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site