remove CONFIG_UID16

remove CONFIG_UID16

[Adrian Bunk]

It seems noone noticed that CONFIG_UID16 was accidentially always 
disabled in the latest -mm kernels.

Is there any reason against removing it completely?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: remove CONFIG_UID16

[Christoph Hellwig]

On Sat, Dec 17, 2005 at 05:44:10AM +0100, Adrian Bunk wrote:
> It seems noone noticed that CONFIG_UID16 was accidentially always 
> disabled in the latest -mm kernels.
> 
> Is there any reason against removing it completely?

Yes, it breaks backwards-compatilbity for not even that old binaries.

There's not way we're ever going to remove it.

Re: remove CONFIG_UID16

[Adrian Bunk]

On Sat, Dec 17, 2005 at 01:18:07PM +0000, Christoph Hellwig wrote:
> On Sat, Dec 17, 2005 at 05:44:10AM +0100, Adrian Bunk wrote:
> > It seems noone noticed that CONFIG_UID16 was accidentially always 
> > disabled in the latest -mm kernels.
> > 
> > Is there any reason against removing it completely?
> 
> Yes, it breaks backwards-compatilbity for not even that old binaries.
> 
> There's not way we're ever going to remove it.

You are right.

Sorry, this was a dumb idea

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: remove CONFIG_UID16

[Bill Davidsen]

Adrian Bunk wrote:
> On Sat, Dec 17, 2005 at 01:18:07PM +0000, Christoph Hellwig wrote:
> 
>>On Sat, Dec 17, 2005 at 05:44:10AM +0100, Adrian Bunk wrote:
>>
>>>It seems noone noticed that CONFIG_UID16 was accidentially always 
>>>disabled in the latest -mm kernels.
>>>
>>>Is there any reason against removing it completely?
>>
>>Yes, it breaks backwards-compatilbity for not even that old binaries.
>>
>>There's not way we're ever going to remove it.
> 
> 
> You are right.
> 
> Sorry, this was a dumb idea

The question is, did you prove that (a) the people who need it are smart 
enough to set it, or (b) the people who need it are not testing -mm kernels.

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

Re: remove CONFIG_UID16

[Matt Mackall]

On Sat, Dec 17, 2005 at 05:44:10AM +0100, Adrian Bunk wrote:
> It seems noone noticed that CONFIG_UID16 was accidentially always 
> disabled in the latest -mm kernels.

Hmm, did I break it?

-- 
Mathematics is the supreme nostalgia of our time.

[-mm patch] re-enable UID16 for !EMBEDDED

[Adrian Bunk]

On Sat, Dec 17, 2005 at 11:54:48AM -0800, Matt Mackall wrote:
> On Sat, Dec 17, 2005 at 05:44:10AM +0100, Adrian Bunk wrote:
> > It seems noone noticed that CONFIG_UID16 was accidentially always 
> > disabled in the latest -mm kernels.
> 
> Hmm, did I break it?

Yes, patch below.

cu
Adrian


<--  snip  -->


UID16 was accidentially disabled for !EMBEDDED.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.15-rc5-mm3-full/init/Kconfig.old	2005-12-17 19:55:58.000000000 +0100
+++ linux-2.6.15-rc5-mm3-full/init/Kconfig	2005-12-17 19:56:12.000000000 +0100
@@ -337,10 +337,11 @@
 config UID16
 	bool "Enable 16-bit UID system calls" if EMBEDDED
 	depends !ALPHA && !PPC && !PPC64 && !PARISC && !V850 && !ARCH_S390X
 	depends !X86_64 || IA32_EMULATION
 	depends !SPARC64 || SPARC32_COMPAT
+	default y
 	help
 	  This enables the legacy 16-bit UID syscall wrappers.
 
 config CC_OPTIMIZE_FOR_SIZE
 	bool "Optimize for size"

Re: remove CONFIG_UID16

[Bodo Eggert]

Adrian Bunk <bunk@stusta.de> wrote:

> It seems noone noticed that CONFIG_UID16 was accidentially always
> disabled in the latest -mm kernels.
> 
> Is there any reason against removing it completely?

Maybe embedded systems.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: remove CONFIG_UID16

[Lee Revell]

On Sat, 2005-12-17 at 11:28 +0100, Bodo Eggert wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > It seems noone noticed that CONFIG_UID16 was accidentially always
> > disabled in the latest -mm kernels.
> > 
> > Is there any reason against removing it completely?
> 
> Maybe embedded systems.

The comments in the code say it's for backwards compatibility:

(from include/linux/highuid.h)

 *
 * CONFIG_UID16 is defined if the given architecture needs to
 * support backwards compatibility for old system calls.
 *

This implies that removing it would break some applications, right?

Lee

Re: remove CONFIG_UID16

[Jan Engelhardt]

>> > It seems noone noticed that CONFIG_UID16 was accidentially always
>> > disabled in the latest -mm kernels.
>> > 
>> > Is there any reason against removing it completely?
>> 
>> Maybe embedded systems.
>
>The comments in the code say it's for backwards compatibility:
>
>(from include/linux/highuid.h)
>
> *
> * CONFIG_UID16 is defined if the given architecture needs to
> * support backwards compatibility for old system calls.
> *
>
>This implies that removing it would break some applications, right?


So what are the most recent apps that still use them, and for what kernel 
were they originally designed?



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: remove CONFIG_UID16

[Lee Revell]

On Wed, 2005-12-21 at 23:33 +0100, Jan Engelhardt wrote:
> >> > It seems noone noticed that CONFIG_UID16 was accidentially always
> >> > disabled in the latest -mm kernels.
> >> > 
> >> > Is there any reason against removing it completely?
> >> 
> >> Maybe embedded systems.
> >
> >The comments in the code say it's for backwards compatibility:
> >
> >(from include/linux/highuid.h)
> >
> > *
> > * CONFIG_UID16 is defined if the given architecture needs to
> > * support backwards compatibility for old system calls.
> > *
> >
> >This implies that removing it would break some applications, right?
> 
> 
> So what are the most recent apps that still use them, and for what kernel 
> were they originally designed?

I don't think this is a productive line of reasoning, even if we could
not identify one such app.  We should not break user visible APIs
without a compelling reason.

Lee