On Mon, 1 Mar 2010, Hector Oron wrote:
Hello,
Nowadays, the number of devices (non x86) is growing and growing.
Lots of these devices have not upstream linux kernel support, which
makes it a bit harder to maintain in the context of debian-installer.
Also, afaict, debian-installer team does not like to add complexity to
d-i, which I understand, so it has better maintainability in the
future.
Also live-installer could be the path to track for such kind of
devices, but again, live-installer was not meant for such purposes and
I believe maintainer won't be happy to add such extra features.
Ubuntu people has been working on a nice tool (evolution from
build_arm_rootfs) named 'rootstock' which basically prepares a
filesystem for ARM targets.
I have N armel devices, some mipsel ones and powerpc, most of them
are not mainlined supported, but a third party supports it. I would
like to work on a tool which can handle all my devices and it is
scalable to support other people devices, either using native or
cross; with MTD, SD, USB support; with and without using qemu magic;
with official debian repositories and non-official ones (SH, avr32,
uClibc targets, ...)
I have started a couple wiki pages for porting PS3 and EfikaMX
(still WIP) boards to Debian in a "hackish" way. I would also like to
add balloonboard support among others.
I would like to have some feedback from the community to see which
it is best way forward *in a Debian way of doing things* or
suggestions and thoughts. So the question would be:
Which is best way forward, in your opinion, for supporting non-x86
arches installations (even installation done from a x86 platform)?
(debian-installer, live-installer, rootstock or start from scratch)
Kind regards,
--
Héctor Orón
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/dd0a3d701003011102k3478ac26g87f060088b6be...@mail.gmail.com
I have a suggestion. The best solution to the 'devices shipped with
hard/impossible-to-change binary kernels' problem, as far as I can tell,
would have to come not from the Debian team, but from the upstream kernel
team.
Namely, if there was ALWAYS a way (which could not be turned off) to
extract a kernel's configuration (in a format which could be plunked into
/usr/src/linux and used to build new modules) from the running kernel,
things would be much simpler.
Why this has not already been done is beyond me.
Yes, it is nice that there is a kernel OPTION that makes the current
kernel config show up as /proc/config or whatnot. But there is certainly
room for a 'middle path', perhaps spitting out some fugly binary which can
be interpreted by an external program/script and thus -converted- into a
properly formatted config file.
I have one of the CT-PC89E machines. It has a binary kernel. This kernel
is burned into a partition of the internal 2GB SSD which, as far as I can
tell, is not any known type of filesystem ('file', run on a dd dump of
this partition, just says 'data'; the only way to get any useful info out
of this partition's contents is to pass it through 'strings'). As has been
pointed out on this thread, the problem of devices shipped with
binary-only kernels is only going to get worse.
It would be EXCELLENT if I could just run some external program and have
it dump a config file... Then I could go in and compile as many new
modules as I want. For example, ext3... which this machine's kernel lacks
support for!
If every kernel in the future had a non-disableable ability to dump a
'fingerprint' of its config data (even in some fugly format that required
an external program to interpret), then the Chinese manufacturers could
not pull this crap (not without explicitly editing the kernel source to
remove this feature, which I HIGHLY doubt most would bother with).
--Jessica
