Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

From: Alexander Leidinger <Alexander_at_Leidinger.net>
Date: Thu, 17 Aug 2006 13:37:21 +0200
Quoting Julian Elischer <julian_at_elischer.org> (from Thu, 17 Aug 2006  
03:30:35 -0700):

> Alexander Leidinger wrote:
>
>> Quoting Peter Jeremy <peterjeremy_at_optushome.com.au> (from Thu, 17   
>> Aug  2006 18:05:33 +1000):
>>
>>> On Wed, 2006-Aug-16 13:25:39 +0200, Alexander Leidinger wrote:

>>>> The intend is to change the default value to 2.6.x when the code is
>>>> stable enough.
>>>
>>>
>>> What is the plan for the 2.4.x code?  Will it be maintained (in which
>>> case, this should be documented), left to rot or explicitly deleted?
>>
>>
>> The 2.6 code is an extension to the 2.4 code. The 2.6 one is needed  
>>   for newer FC releases. So the current sysctl stuff is just a   
>> disabling of some code in some syscalls. The goal is get stable 2.6  
>>  extensions  and to forget about the 2.4 downgrade (removing the   
>> part which  disables some stuff currently, the rest is needed).
>>
>> So no need to document the effects of some specific values for    
>> osrelease, it's enough to say that only the default is supported, a  
>>   non default value may cause unwanted behavior and bugreports   
>> should be submitted with default values.
>
>
> having the ability to run older linux may be a good thing..how good is

Are you willing to take care of the old linux userland infrastructure  
in ports and to provide security support for old linux binaries? More  
recent linux binaries (e.g. FC5) will not run with 2.4.2 (glibc checks  
for the linux kernel version).

> their backwards compatibility.. I've heard of spme people being stuck
> on old
> versions of linux..  maybe the sysctl could stay if there is a problem
> to solve.

Clarification: the sysctl will stay, the code which disables some  
parts based upon the value of the sysctl is supposed to go away (ATM  
it's a bad hack which checks the osrelease number *on every call* of 2  
functions).

Anyone with interest in this is free to take care of this, as long as  
they coordinate with the people which work on the current  
infrastructure on emulation_at_ regarding the userland/security stuff and  
the kernel. Until someone stands up and shows results/progress, this  
is scheduled to vanish in the future.

Bye,
Alexander.

-- 
Good night, Mrs. Calabash, wherever you are.

http://www.Leidinger.net    Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild _at_ FreeBSD.org  : PGP ID = 72077137
Received on Thu Aug 17 2006 - 09:37:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:59 UTC