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
Adrian Bunk <[email protected]> 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.
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.
On Sat, 2005-12-17 at 11:28 +0100, Bodo Eggert wrote:
> Adrian Bunk <[email protected]> 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
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
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.
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 <[email protected]>
--- 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"
>> > 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/
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
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 ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me