linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Hockin <thockin@hockin.org>
To: torvalds@transmeta.com (Linus Torvalds)
Cc: thockin@hockin.org (Tim Hockin),
	schwidefsky@de.ibm.com (Martin Schwidefsky),
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.41 s390 (8/8): 16 bit uid/gids.
Date: Wed, 9 Oct 2002 11:24:46 -0700 (PDT)	[thread overview]
Message-ID: <200210091824.g99IOkI18617@www.hockin.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0210091046170.7355-100000@home.transmeta.com> from "Linus Torvalds" at Oct 09, 2002 10:47:36 AM

> On Wed, 9 Oct 2002, Tim Hockin wrote:
> > Linus, This is actually something I sent to Martin (and DaveM).  The __UID16
> > crap is because s390x and Sparc64 (and others?) do not want the highuid
> > stuff except in very specific places - namely compat code.  Just using
> > CONFIG_UID16_SYSCALLS has the same bad side-effect as CONFIG_UID16 - all or
> > nothing.  In short, we want to build uid16.o with highuid translations, and
> > a few other compat objects, but not everything.  Ugly.
> 
> So why don't we just split it up into all the sub-options? So that you 
> have a smørgåsbord of real options to select from..
> 
> In other words, that __UID16 thing should be a real CONFIG_XXX option.

Because Sparc64/s390x/? still need to tell highuid.h to do macro magic for
NEW_TO_OLD_UID() and friends in some places and not others.  A CONFIG_XXX
applies all the time to all files.

We can make the few sparc64/s390x sections just redefine the macros they
want in the files in question, if you prefer, but uid16.c is still a user of
highuid.h and needs to define __UID16.  If you prefer, __UID16 can be called
DO_HIGHUID_CONVERSIONS.

#define DO_HIGHUID_CONVERSIONS
#include <linux/uid16.h>

Or have a new uid16.h that unconditionally defines the macros.  Then
highuid.h can include uid16.h IFF CONFIG_UID16, and uid16.c can include
uid16.h.  I see this as MORE problematic, because someone, somewhere will
include uid16.h when they meant highuid.h.  Forcing a non CONFIG_UID16 arch
to explicity call out "I want uid16 macro conversion for THIS FILE" seems
safe.  Ugly, but safe.


  reply	other threads:[~2002-10-09 18:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-09 12:32 [PATCH] 2.5.41 s390 (8/8): 16 bit uid/gids Martin Schwidefsky
2002-10-09 17:24 ` Linus Torvalds
2002-10-09 17:38   ` Tim Hockin
2002-10-09 17:47     ` Linus Torvalds
2002-10-09 18:24       ` Tim Hockin [this message]
2002-10-09 22:10         ` Linus Torvalds
2002-10-09 22:43           ` Tim Hockin
2002-10-09 23:12             ` Linus Torvalds
2002-10-09 23:38               ` David S. Miller
2002-10-09 23:59                 ` Tim Hockin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210091824.g99IOkI18617@www.hockin.org \
    --to=thockin@hockin.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).