Hi Thomas
> enterprise-grade VPN devices out of SheevaPlugs (implementing HA,
> Atateful failovers, Firewall, QoS on a single vlan-tagged interface).
Cool. Have you looked at the OpenRD which has 2Gbit interfaces?
They're more expensive than the SheevaPlug and the kernel support isn't
finished yet, but I
plan to make ARMedslack installable on that too.
> used is 2.6.31.1. Is there any plan at using the 2.6.32 kernel for the
> next release,
There won't be a Slackware ARM 13.0 release because the EABI port is too
new and untested -- I only completed it last month; whilst it's been
totally stable for me during development, I expect there to be problems
I don't yet know about.
Slackware 13.1 may be the next release if I think it's stable enough by
that time. For the time being, Slackware ARM -current will keep in sync
with Intel -current.
Slackware ARM usually has the latest stable kernel though, which usually
isn't in sync with Slackware x86 because as you say, the newer Kernels
usually contain ARM fixes.
> would feel much more comfortable using a cross-compile environment - I
> used to run one from a PowerPC (YDL) for my OpenWRT router and it was
> pretty nice. If there's no
documentation specific to ARMEdslack I will
> build one as I'd like to create images from my dev platform (x86) and
> use them straight in Qemu/Sheeva (I'll probably hack the installer too...).
I'm not sure what you mean here. Why would you need to do anything to the
installer? The installer is not related to any compilation environment.
ARMedslack's packages are compiled on a SheevaPlug (or what ever machine
is free which is the correct release and has the most up to date
installation), and using distcc is sent to a cluster of x86 machines
running a cross compiler that has the identical versions of glibc,
binutils and gcc as the Slackware ARM host. So I get the benefits of
having fast compilation times and having the packages work correctly.
If you're building an entire OS, cross compiling really isn't much fun
because many packages' build systems aren't made to cross compile so
you'd
have to modify them. The best part is when the Makefile tries to execute
a binary just compiled in order to process some data -- an example of
which is ncurses. This is why the first ARMedslack was built inside of
"Scratchbox" - www.scratchbox.org
I don't know of any distribution apart from Emdebian, which does not build
their packages natively.
> Also it looks like the kernel support UBIFS but there's no instructions
> for using it. IMHO it should not only be documented but also the
> recommended filesystem as it is much better in many technical aspects.
You're talking about installation of the OS onto the NAND flash on the
SheevaPlug? I don't know how to support that for a couple of reasons:
1. I didn't spend enough time looking
2. The NAND on the SheevaPlug is 512MB in size which isn't enough to
put a full installation of Slackware (~4GB) on
to. A full
installation is the recommended way to install Slackware.
Therefore I'd have to maintain a list of packages of a slimmed
down installation.
If somebody wanted to maintain a list of packages that could fit inside
512MB and still leave enough space for the running system, then the "tag
files" could be added to the installer image and presented as an
installation option.
I'd *like* to be able to do it because I believe it'd be useful
but I don't have time to maintain it.
> PS: Could the mailing list be linked to from the main ARMedslack page?
> I'm not sure if I missed something but I had to do a Google search to
> find it.
It is on the front page of www.armedslack.org.
--
Stuart Winter
Slackware ARM: www.armedslack.org
_______________________________________________
ARMedslack mailing list
ARMedslack <at> lists.armedslack.orghttp://lists.armedslack.org/mailman/listinfo/armedslack
RSS Feed