Re: Embedded and ARM Debian Sprint
On Sun, Nov 7, 2010 at 7:05 PM, Hector Oron <hector.oron@gmail.com> wrote:
> Hello,
>
> 2010/11/7 Luke Kenneth Casson Leighton <lkcl@lkcl.net>:
>
>> i haven't looked around, but has anyone suggested adding a
>> base64-encoded extension to the .deb name, containing a bit-field of
>> "capabilities"? the problem with splatting the capabilities into the
>> .deb itself is that you then end up with dozens of combinations of
>> capabilities, all with the exact same .deb filename. by encoding the
>> capabilities in the actual filename, you can still pick a particular
>> package by its version number etc. etc. _but_ you can identify whether
>> it will work on a particular CPU by decoding its capabilities bits.
>>
>> 0x1 -> v5, 0x2 -> v6 .... 0x10 -> NEON
>
> Yes, it is not bad idea at all. There are suggestions on encoding a
> flavour field on the Debian package name,
that is allmost the same thing, except you... *thinks* you'd now need
to add a "Provides:" with the original name.
> other suggestions of
> encoding the field after debian version,
yes - that's where i had it - in my mind at least :)
> other suggestions of handling
> multiple repositories with optimized libraries (maybe components).
yeah - but ... mmm...
>>> * Cross compilation environment (cross toolchains and target packages) - bare metal support
>
> I want to be able to (cross-)compile my firmware for Cortex M3 or
> MSP430. (bare-metal)
>
>> the level of expertise / machine-specific information is so vast that
>> i strongly advise against "beginning from scratch". whilst wookey (or
>> neil?) pointed out a few months back that it took several months -
>> almost a year - to do the armel port, most of which was done by hand,
>> and someone else pointed out recently that they managed in a couple of
>> weeks to recompile automatically several hundred packages for Cortex
>> A8, gaining a 40% performance jump by doing so, this is still an
>> insanely ridiculous situation... when you compare it to openembedded.
>
> Debian (binary based) != OpenEmbedded (source based)
that's the traditional view. actually, i'd say that debian is a
hybrid binary+source based. and emdebian dpkg-cross-compilation is
_definitely_ source-based.
so it's not quiiite as clear-cut as it looks. remember that just
because _you_ install binary packages doesn't mean that the packages
come out of thin air. (and yes, btw, i'm discovering that
openembedded supports the same sort of concept of "-dev" packages)
so you're missing the point by saying debian = binary-based,
openembedded = source-based: i envisage that openembedded would be
utilised to _build_ binary-based .deb packages, not "openembedded
would force the installation of source-based packages" which it
doesn't do anyway.
i envisage - quite literally - openembedded calling dpkg-buildpackage,
and that's pretty much it, besides setting up the cross-compiler
arguments, and taking care of situations where it all falls in a heap
:)
> Changes in Debian take longer because we need consensus among
> community to do things properly and maintainable in the long term. Why
> would I want to cross compile a whole distribution and run an extra
> emulation layer
... which if you've ever done cross-compiling of 32-bit apps on a
64-bit system you _know_ you have to have, so it's not like there's
any choice in the matter...
> (introducing more overhead in maintainability)
... which openembedded have already done the work on, thus making the
maintainability "burden" equal to zero....
> if I am
> able to debootstrap/multistrap it in less than a minute,
[ _somebody_ has to create that debootstrap. now, with a dozen
different flags, that "somebody" is now completely overwhelmed by the
sheer number of pre-compiled debootstraps needed to be made. ]
> then cross
> compile my application for faster development/test cycle to run on
> that system which already has gone through lots of QA proceedings.
why exactly. well for a start, i'd want, just like that guy who did
a partial rebuild of the entire debian mirror with Cortex A8
optimisations, to do instead of a partial rebuild of the entire debian
mirror to do a TOTAL rebuild of the entire debian mirror with Cortex
A8 optimisations.
for my special super-duper lovely production screamingly-fast
ship-it-noww product i don't _want_ a debootstrap in less than a
minute, because that debootstrap will have been precompiled with utter
shit options for the N out of 600 ARM licencee variants, and i want
the absolute fastest, or the absolute most efficient space-saving.
remember that you make these choices for people, whether to enable
thumb instructions which give a better compression ratio but worse
performance, you are _never_ going to have absolutely everyone happy.
yes i'd put up with a debootstrap
you-selected-it-all-for-me-and-it-runs-like-a-dog compile-time options
for the prototype / demo but i'd certainly not put up with it for
production.
regarding the QA issue: people who use openembedded, usually, know
that they're effectively "Doing A Gentoo". they _know_ that they have
to go through their own QA process.
but, again, this misses the point: the purpose of suggesting that an
openembedded recipe be created which utilises dpkg-buildpackage (or
cross-dpkg-buildpackage to be more precise) is to save those poor sods
who have to create those QA'd debootstrap images one f*** of a lot of
time.
i sure as s**t wouldn't recommend TO THE AVERAGE PERSON that they go
use openembedded-dpkg-buildpackage to create their own super-duper "a
la Gentoo" whoppingly-optimised debian distro from scratch, but bless
'em you can bet that that's exactly what will happen once the tool's
created... :)
>> question: why not recommend portage / gentoo instead of openembedded?
>
> Certainly this is a topic to be discussed. How do we provide a useful
> user land for systems with short size and memory requirements
> (Emdebian/Crush)?
emdebian / crush is just a different mirror with a different series
of packages. i envisage that openembedded-dpkg-cross-buildpackage
would simply be set up to have a different set of stuff in
sources.list, and that a build would... just... work!
> Do we need to have 100 developers to maintain the
> thing?
i'd say no. if it turns into 100 developers, then you're seriously
doing something wrong.
> (*bad idea*) Glibc or uClibc based? Trying to avoid
> fragmentation, it would be good to trim down already in use EGlibc,...
> It is to be discussed if we provide the tools (buildroot, bitbake,...)
> to build from $somewhere sources or if we are capable to provide a
> binary based image like the ones used by debian-installer using udebs
> or maybe something else $someone stills needs to propose/think about
> it.
the idea is to simply end up with the exact same .udebs and .debs
that you'd normally have to cross-compile by hand. if it takes
slightly longer in some cases because you have to run configure inside
qemu, that's not a big deal.
l.
Reply to: