7 3

[alpine-devel] i486 vserver kernel?

Jon Clausen
Details
Message ID
<20101004110235.GG2458@nx8220.ymmv.dk>
Sender timestamp
1286190155
DKIM signature
missing
Download raw message
Hi

I have these old, underpowered, resource starved singleboard machines.
(VIA Samuel 2 CPU, 512 MB RAM)

I'd like to extend their life a little longer, and one way of doing that
would be using them for 'pet projects'. 'vserver' seems a likely way of
getting the most out of the hardware, except that the CPU doesn't support
instructions that the i686 kernel needs (CMOV)

I managed to get a proof of concept system running by recompiling a vserver
kernel configured for i486, but...

1: An 'official' i486 build would be much nicer (and easier for me ;)

2: If for some reason 1: isn't feasible, what are the steps to set up a
(semi-)automated buildsystem?
I guess it would entail something on the order of
* getting notified when there's a new kernel version
* syncronizing the sources
* generating a new 'i486 .config'
* compile/package

Hints much appreciated :)
/jon
-- 
YMMV


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<1286197843.28650.61.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<20101004110235.GG2458@nx8220.ymmv.dk> (view parent)
Sender timestamp
1286197843
DKIM signature
missing
Download raw message
On Mon, 2010-10-04 at 13:02 +0200, Jon Clausen wrote: 
> Hi
> 
> I have these old, underpowered, resource starved singleboard machines.
> (VIA Samuel 2 CPU, 512 MB RAM)
> 
> I'd like to extend their life a little longer, and one way of doing that
> would be using them for 'pet projects'. 'vserver' seems a likely way of
> getting the most out of the hardware, except that the CPU doesn't support
> instructions that the i686 kernel needs (CMOV)
> 
> I managed to get a proof of concept system running by recompiling a vserver
> kernel configured for i486, but...
> 
> 1: An 'official' i486 build would be much nicer (and easier for me ;)

hum. I think there was a reason switch to i586, but i dont remember what
it was. I wonder if it was related to better virtualization guest
support or something.

I think it would be nice to support this kind of old hardware so I'm
switching to i486 for linux-vserver til someone comes with some good
reasons to switch back to i586.

Please try the linux-vserver kernel in edge.

> 2: If for some reason 1: isn't feasible, what are the steps to set up a
> (semi-)automated buildsystem?
> I guess it would entail something on the order of
> * getting notified when there's a new kernel version
> * syncronizing the sources
> * generating a new 'i486 .config'
> * compile/package
> 
> Hints much appreciated :)

This should not be too hard for you to set up either.

>From the top of my head, something like:

Do a git clone

cd main/linux-vserver

abuild unpack prepare installdeps
cd src/build && make menuconfig
# select i486 processor.
# save and exit kernel config

copy .config to ../../kernelconfig.x86

cd ../../
abuild checksum

now you have your modified kernel config. You can now git commit this
change.

To keep it up-to-date, simply do git pull --rebase and rebuild when the
upstram changes.

I dont really have good ideas when it comes to notifications. I suppose
you could do the git pull --rebase from a cronjob and check if the
linux-vserver/APKBUILD has changed or similar.

You can also copy the the linux-vserver to a separate package,
linux-vserver-i486 or similar. I have a script that bump package
versions so update to new version is just a question of 'abump
package-<newversion>'


-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jon Clausen
Details
Message ID
<20101006150135.GB2482@nx8220.ymmv.dk>
In-Reply-To
<1286197843.28650.61.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1286377296
DKIM signature
missing
Download raw message
On Mon, 04 Oct, 2010 at 15:10:43 +0200, Natanael Copa wrote:
> On Mon, 2010-10-04 at 13:02 +0200, Jon Clausen wrote: 

> > 1: An 'official' i486 build would be much nicer (and easier for me ;)
> 
> hum. I think there was a reason switch to i586, but i dont remember what
> it was. I wonder if it was related to better virtualization guest
> support or something.
> 
> I think it would be nice to support this kind of old hardware so I'm
> switching to i486 for linux-vserver til someone comes with some good
> reasons to switch back to i586.

Actually I was thinking more in terms of kernel 'flavours' or
'architechtures'. People with newer HW might be better off (as in get better
performance) with i586 or i686 kernels.

Is it feasible to introduce multiple builds? Sort of:

linux-vserver-i486-2.6.32.24-r0.apk
linux-vserver-i586-2.6.32.24-r0.apk

> Please try the linux-vserver kernel in edge.

Well, "it boots" is about all I can say ATM - had to shuffle some stuff
around, so I haven't gotten to actually running any guests yet.

But thanks so far ;)

> > 2: If for some reason 1: isn't feasible, what are the steps to set up a
> > (semi-)automated buildsystem?
> > I guess it would entail something on the order of
> > * getting notified when there's a new kernel version
> > * syncronizing the sources
> > * generating a new 'i486 .config'
> > * compile/package
> > 
> > Hints much appreciated :)
> 
> This should not be too hard for you to set up either.
> 
> From the top of my head, something like:

<snip>

For the time being, I'll just 'coast along' with the i486 kernel from
'edge'... but thanks for 'outline'.

regards,
jon
-- 
YMMV


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<1286439953.1540.12.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<20101006150135.GB2482@nx8220.ymmv.dk> (view parent)
Sender timestamp
1286439953
DKIM signature
missing
Download raw message
On Wed, 2010-10-06 at 17:01 +0200, Jon Clausen wrote:
> On Mon, 04 Oct, 2010 at 15:10:43 +0200, Natanael Copa wrote:
> > On Mon, 2010-10-04 at 13:02 +0200, Jon Clausen wrote: 
...
> Actually I was thinking more in terms of kernel 'flavours' or
> 'architechtures'. People with newer HW might be better off (as in get better
> performance) with i586 or i686 kernels.

we use the term "flavor" for the patchsets. linux-grsec, linux-vserver.

> Is it feasible to introduce multiple builds? Sort of:
> 
> linux-vserver-i486-2.6.32.24-r0.apk
> linux-vserver-i586-2.6.32.24-r0.apk

This would be the best, yes. Unfortunally it would require some extra
maintenence work. How about 3rd party modules? dahdli-linux-vserver for
instance. I also does a quick test to verify that the kernel actually
boot in a virtual machine before I push the change. Should I test both
i486 and i586? The biggest issue is that those things are not a one-time
job and currently I'm pretty much at the limit of what I can maintain.

I am also planning to do alpine x86_64 soonish and I think most high-end
vserver hosts will be using that, so I'm not that keen on start with
linux-vserver-i486, linux-vserver-i586, linux-vserver-i686 for the time
beeing.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jon Clausen
Details
Message ID
<20101007090257.GA2467@nx8220.ymmv.dk>
In-Reply-To
<1286439953.1540.12.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1286442178
DKIM signature
missing
Download raw message
On Thu, 07 Oct, 2010 at 10:25:53 +0200, Natanael Copa wrote:
> On Wed, 2010-10-06 at 17:01 +0200, Jon Clausen wrote:
> > On Mon, 04 Oct, 2010 at 15:10:43 +0200, Natanael Copa wrote:
> > > On Mon, 2010-10-04 at 13:02 +0200, Jon Clausen wrote: 
> ...
> > Actually I was thinking more in terms of kernel 'flavours' or
> > 'architechtures'. People with newer HW might be better off (as in get better
> > performance) with i586 or i686 kernels.
> 
> we use the term "flavor" for the patchsets. linux-grsec, linux-vserver.

ok

> > Is it feasible to introduce multiple builds? Sort of:
> > 
> > linux-vserver-i486-2.6.32.24-r0.apk
> > linux-vserver-i586-2.6.32.24-r0.apk
> 
> This would be the best, yes. Unfortunally it would require some extra
> maintenence work. How about 3rd party modules? dahdli-linux-vserver for
> instance. I also does a quick test to verify that the kernel actually
> boot in a virtual machine before I push the change. Should I test both
> i486 and i586? The biggest issue is that those things are not a one-time
> job and currently I'm pretty much at the limit of what I can maintain.

Yeah, I kinda figured it'd be something like that, so until someone comes
along with reasons to switch back to i586/i686 I'm happy :)

If/when someone does, then I'm just going to have to look into setting up a
build system.

> I am also planning to do alpine x86_64 soonish and I think most high-end
> vserver hosts will be using that,

This is good news. I'm sure you're right about high-end, but I think even
comparatively low-end as well.

> so I'm not that keen on start with
> linux-vserver-i486, linux-vserver-i586, linux-vserver-i686 for the time
> beeing.

Understandable.

regards,
jon
-- 
YMMV


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teräs
Details
Message ID
<4CAD9782.3050207@iki.fi>
In-Reply-To
<20101007090257.GA2467@nx8220.ymmv.dk> (view parent)
Sender timestamp
1286444930
DKIM signature
missing
Download raw message
On 10/07/2010 12:02 PM, Jon Clausen wrote:
> On Thu, 07 Oct, 2010 at 10:25:53 +0200, Natanael Copa wrote:
>> On Wed, 2010-10-06 at 17:01 +0200, Jon Clausen wrote:
>>> On Mon, 04 Oct, 2010 at 15:10:43 +0200, Natanael Copa wrote:
>>> Is it feasible to introduce multiple builds? Sort of:
>>>
>>> linux-vserver-i486-2.6.32.24-r0.apk
>>> linux-vserver-i586-2.6.32.24-r0.apk
>>
>> This would be the best, yes. Unfortunally it would require some extra
>> maintenence work. How about 3rd party modules? dahdli-linux-vserver for
>> instance. I also does a quick test to verify that the kernel actually
>> boot in a virtual machine before I push the change. Should I test both
>> i486 and i586? The biggest issue is that those things are not a one-time
>> job and currently I'm pretty much at the limit of what I can maintain.
> 
> Yeah, I kinda figured it'd be something like that, so until someone comes
> along with reasons to switch back to i586/i686 I'm happy :)
> 
> If/when someone does, then I'm just going to have to look into setting up a
> build system.

i486 optimization would be good for uniprocessor systems. Basically UP
kernel for i486, and SMP kernel for i586+.

But yes, it's more work. I wonder if we could automate the "does the
kernel boot test". I think it should be doable with qemu + a script to
monitor console output (e.g to check that we get getty prompt).

- Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<1286463256.1540.23.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<4CAD9782.3050207@iki.fi> (view parent)
Sender timestamp
1286463256
DKIM signature
missing
Download raw message
On Thu, 2010-10-07 at 12:48 +0300, Timo Teräs wrote:
> On 10/07/2010 12:02 PM, Jon Clausen wrote:
> > On Thu, 07 Oct, 2010 at 10:25:53 +0200, Natanael Copa wrote:
> >> On Wed, 2010-10-06 at 17:01 +0200, Jon Clausen wrote:
> >>> On Mon, 04 Oct, 2010 at 15:10:43 +0200, Natanael Copa wrote:
> >>> Is it feasible to introduce multiple builds? Sort of:
> >>>
> >>> linux-vserver-i486-2.6.32.24-r0.apk
> >>> linux-vserver-i586-2.6.32.24-r0.apk
> >>
> >> This would be the best, yes. Unfortunally it would require some extra
> >> maintenence work. How about 3rd party modules? dahdli-linux-vserver for
> >> instance. I also does a quick test to verify that the kernel actually
> >> boot in a virtual machine before I push the change. Should I test both
> >> i486 and i586? The biggest issue is that those things are not a one-time
> >> job and currently I'm pretty much at the limit of what I can maintain.
> > 
> > Yeah, I kinda figured it'd be something like that, so until someone comes
> > along with reasons to switch back to i586/i686 I'm happy :)
> > 
> > If/when someone does, then I'm just going to have to look into setting up a
> > build system.
> 
> i486 optimization would be good for uniprocessor systems. Basically UP
> kernel for i486, and SMP kernel for i586+.
> 
> But yes, it's more work. 

And delays kernel fixes as build time is numarch * time to compile
single kernel.

> I wonder if we could automate the "does the
> kernel boot test". I think it should be doable with qemu + a script to
> monitor console output (e.g to check that we get getty prompt).

It is infact half automated already. I run a script that builds iso with
specified kernel (vserver or grsec), installs qemu and boots it up with
ncurses interface. Then i just log in and do 'poweroff'.

If the boot iso had serial boot, then I could use something like
'expect' ur lua-pty to wait for login: and send 'root<enter>' and
'poweroff' and if success, then push the commit...

hum...

Does anyone have any objections to enable serial login by default? The
only reason I havent it enabled by default is that you never know what
devices are connected to computers serial interface (UPS? sms gateway?)
and once its enabled, it cannot be turned off from default iso.

I suppose i can make serial boot optional in alpine-iso makefile...

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Jon Clausen
Details
Message ID
<20101010083317.GA2445@nx8220.ymmv.dk>
In-Reply-To
<1286463256.1540.23.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1286699597
DKIM signature
missing
Download raw message
On Thu, 07 Oct, 2010 at 16:54:16 +0200, Natanael Copa wrote:
> On Thu, 2010-10-07 at 12:48 +0300, Timo Teräs wrote:

> > I wonder if we could automate the "does the
> > kernel boot test". I think it should be doable with qemu + a script to
> > monitor console output (e.g to check that we get getty prompt).
> 
> It is infact half automated already. I run a script that builds iso with
> specified kernel (vserver or grsec), installs qemu and boots it up with
> ncurses interface. Then i just log in and do 'poweroff'.

Is it possible to add networking/sshd to this test-setup?

If it is, then key-based auth might provide a way to automate the post build
test process without 'expect' (?)

> If the boot iso had serial boot, then I could use something like
> 'expect' ur lua-pty to wait for login: and send 'root<enter>' and
> 'poweroff' and if success, then push the commit...
> 
> hum...
> 
> Does anyone have any objections to enable serial login by default?

Personally, no - but this;

> The
> only reason I havent it enabled by default is that you never know what
> devices are connected to computers serial interface (UPS? sms gateway?)
> and once its enabled, it cannot be turned off from default iso.

may be a pretty good reason not to enable serial by default.

regards,
jon
-- 
YMMV


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---