Re: Embedded != Low Power
Neil Williams wrote:
On Wed, 2008-10-29 at 09:31 +1100, Brendan Simon wrote:
Embedded != Low Power
True.
Embedded != slow CPU too - in fact, I'm not sure that any flavour of
Emdebian will be suitable for really old or really slow CPU machines -
the underlying code is Debian after all. Functionality changes are one
thing but reducing the level of complexity of the code can only be done
to a point - choosing apps like GPE reduces the "frontend" complexity of
the code but you've still got to get the underlying libraries running.
I have to start somewhere so I'm starting with PDA-type devices.
Fair enough too. I just wanted to make the point so that it can be
considered in the bigger picture :)
I do agree that Emdebian should cater for low power, low capacity, low
speed devices, however it should also cater for higher end embedded
devices too.
Always been part of the plan. If anyone fancies stepping up to do some
of the development for Emdebian Grip, please say so. I'm happy
developing for Emdebian Crush and using Grip as a basis for Crush so if
people really want to develop Grip in and of itself, you'll need to help
me out here with your own time and effort. There's only so much I can do
and I'm pretty much at maximum with the current development workflow.
I can imagine. Your output is phenominal and is greatly appreciated !!!
emgrip can develop separately from the rest of emdebian-tools because it
cannot use Emdebian::Tools or other cross-building modules that are
being developed for Crush. If someone can take it on and start working
with Grip - building repositories, processing more packages, improving
in-build behaviour, implementing the DEB_BUILD_OPTION support that is
just an idea at this stage, adding a debhelper wrapper, adding CDBS and
CMake support, adding support for .changes files, download support via
an apt wrapper (maybe libcache-apt-perl), automation, porting to
edos-debcheck support using code from emdebcheck and options to apt (not
apt-cross), porting Grip to Debian Installer - then Grip will arrive
sooner. I envisage the code migrating to a different source package (I
thought maybe dpkg but only once Lenny is released) so feel free to work
on the code separately (rename the scripts to suit too) and let me know.
It all sounds so easy :)
I think it is hard to get started as Debian is so big and there are lots
of policies, etc. This is a good, but daunting to get started.
It's a matter of dipping in the toe, and getting wet (drowned), and
asking lots of questions :)
I want Grip to be a release-goal for Squeeze. I want someone to join the
work and let me get on with Crush, TDebs, cross-build support in Debian,
NMU's etc. You'll have all the support you need, just do some of the
work.
:-)
Agreed :)
From memory, Emdebian Grip would be a good candidate for this, right ???
Yes, when it actually arrives. :-)
Have a go with /usr/share/emdebian-tools/emgrip from emdebian-grip (in
the Emdebian repository) and file bugs about missing features, packages
that break or packages that still contain docs etc. Better still, take
on development of Grip and fix the bugs. You don't need the rest of
emdebian-tools to use Grip, just the TDeb support which is common to
both. The internal version of emgrip is 0.0.1 - the package got the
1.4.11 moniker because it is currently built from emdebian-tools
sources.
If you want to, you could change emgrip from perl to something else but
I would not be able to help you if you choose python and I'm not sure
that anything except perl or shell would be acceptable to the rest of
Debian for a debhelper/dpkg-dev build tool for use in all packages.
I'm a python man myself. How did you know? Must have been my tone of
voice ;-)
Seriously, I would never dream of changing all that perl code to
python. Too much to lose, for arguably little gain.
I have developed for PowerPC architecture, using Apple PowerPC PowerMacs
as the development hosts, however now that Apple have gone Intel, it
makes it harder to find powerful PowerPC platforms to build powerpc
binaries.
Ideally I would prefer to use powerful commodity PCs, and cross-compile
everything I need to customize.
Grip doesn't need to be cross-compiled, it should support native
building ON an Emdebian Grip machine. Yes, it probably will be slow but
cross-building is still not implemented in more than 1% of Debian
packages.
Grip needs to have almost a full package set - I'd guess at 10,000 or
maybe 15,000 packages of the 20,000 in Debian. Crush currently has 248.
Needs to ??? Why??? Surely we only need to Grip the packages that
people are likely to use. Surely we wouldn't grip things like qcad,
etc. Just grip the basic packages (same as crush) to start with, then
people can request others to be gripped as needed. This could be
automated via a web page to specify packages to be gripped and put in
the grip repository.
Ideally I could use all the pre-built powerpc debs from Lenny, and just
cross-compile new packages that I need to modify or create.
No, you just "grip" prebuilt debs from Lenny. Depending on how Grip
develops, there is nothing stopping Grip from actually working with Etch
packages or even Sarge.
OK, got it, but if I need to develop my own packages or modify an
existing package, then it must be done on the same architecture as the
grip device or on the grip device itself. This is not viable or
productive in some cases (eg. commercial development).
Cross-compilation on grunty commodity servers is the solution. I
thought about qemu but I believe the performance is so bad that it is
better to compile on the target.
Ideally, IMHO, Emdebian should be able to totally cross-compile a
powerpc <or insert favorite arch> distribution from scratch, and produce
exactly the same outputs (.debs) as a build on the native powerpc
<insert arch> host.
Is that a goal of Debian Grip ???
Cross-building is not part of Grip. Cross-building is initially related
only to Emdebian Crush using functionality changes for dependency
reduction. Cross-building may be a bonus from work on Crush but Grip is
essentially about repackaging prebuilt native binaries. Packages can be
"gripped" during the build, prior to inclusion into a Grip repository or
after downloading onto the device running Grip (if sufficient space
exists).
I still think cross-compiling packages is a good goal for emdebian.
Even Grip (cross compile my customizations and grip it, grip it good).
Maybe I'm really talking about crush (or a variant), but with standard
packages like glibc and coreutils rather than uclic and busybox, etc ???
Emdebian Grip aims to provide a natively-built Debian Installation for
any architecture supported by Debian in a way that is functionally
identical to Debian, just smaller and using TDebs in the Emdebian manner
for extra granularity. However, if Grip does get to 10,000 packages,
using Emdebian TDebs would turn that into more like 150,000 which may
well be a decision that has to be faced at some point.
Grip should support native building on the Grip device and if you base
it on Lenny and more so Squeeze, it will support cross-building on the
Grip device or using Grip as a target of cross-building on a different
box running Debian Squeeze. In such cases, you wouldn't use
emdebian-tools to cross build, you'd use 'dpkg-buildpackage -a' so that
the Crush functionality changes do not get applied but that depends on
the cross-building support being developed for Crush and implemented in
the Debian package.
Keep up the good work. Emdebian is going to rock to world - hopefully
sooner rather than later :)
Cheers, Brendan.
Reply to: