[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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

 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.


Reply to: