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

Re: Areas of Emdebian to integrate into Debian



On Sun, 3 Apr 2011 17:15:52 +0100
Hector Oron<hector.oron@gmail.com>  wrote:

2011/4/3 Neil Williams<codehelp@debian.org>:

  * Add a field which allows a package to be cross buildable (that
might be delayed until we gain support for all that in Debian)

I'm not sure about this one. I think every package should be assumed to
be cross-buildable until proven otherwise.

Sorry, my use case is setting a flag which allows Debian autobuilders
to cross build a package, instead of natively build. Why do we want
that? ARM autobuilders take about 24hrs to complete current official
supported kernel builds, that is a big blocker to add more platforms
and think as well when there is a security flaw which needs to get
fixed, Debian kernels have to delay the fix until all architectures
are built. This is one situation where cross building could improve
status quo.

Personally, I doubt that ftpmaster will accept cross-built packages
into any "official" Debian repository for quite some time, if ever.
Cross-building support tools is one thing. Cross-built packages are
quite another. Have you had ANY indication that ftpmaster is even
slightly keen on such a division?

But is it reasonable for a cross build mirror repository to be created so that they can be diffd thus developing a huge database of cross built vs natively built packages to validate the crioss building process it self. If, after a year, that packages are identical it would be good evidence to support cross built repositories. Conversely, if the packages differ, we really might like to know that and may provoke investigation as to why.

There's a completely different argument here about why we *have* so
many variant boards which need varying kernel support. Kernel people
aren't happy with the constant variability of board-specific support
systems. Personally, I question whether each individual board needs to
have a bespoke config supported by bespoke patches which conflict with
other bespoke patches for other similar boards, so I'm with Linus on
this one.

https://lkml.org/lkml/2011/3/17/492

Nothing we can do to solve current situation.

Wrong. We can at least push people to collaborate, provide the tools
where we can and act appropriately when doing our own kernel stuff
(like in balloon).

Recently, balloon added support for having a single kernel for multiple
board configurations and handling the results via the vmlinuz.cmdline
support. That would seem to be the way forward to me because then we
could have a single set of patches which enable everything (even if not
present on a particular board) and then rely on the specific
commandline for that specific board to sort things out at boot. This
also lends itself to runtime kernel package upgrades and easier porting
of the patch set to newer kernels because more people are working on
the same patches, not their own.

This is sort of true. It does require that the bootloader can be customised to add that command line option. Its a source code hack in bootldr for example. Kernel command line setting is only one way of runtime configuration. If the platform variant can be detected early in the boot process then a similar effect can be acheived.

Note also that Debian boots via an initramfs/initrd with all(?) modules installed which it then replaces with the rootfs. This makes the image rather large and possibly not ideal for embedded - do we need all the LVM/RAID/SCSI module bloat just to boot our embedded device? Balloon solves this by booting a uclibc kernel/initramfs with a reduced module set off which it kexecs the main rootfs.

Is not that a way around device trees?

Which needs bootloader support too.

Possibly - the point though is that the patches get collated and worked
on together.

Should we provide security
fixes on those out of mainline tree kernels? Or should we just build
kernel versions which are marked as long term support (2..6.32,2.6.37)
and/or long term support for embedded (2.6.35)?

We don't have limitless resources.

Sure, that is why, we could concentrate in one version, the one tagged
by embedded community (which hopefully will be the same that kernel
guys tag as long term support, in the future). It would not be such a
pain to get this one kernel version right for next release (and
probably it might be linux kernel that Debian and other distros
release).

... and encourage everyone talking about kernels or wanting kernels
from Emdebian to work as part of a larger community and collate patches.

We don't have to do the work. We can encourage those who do the work to
try and make things go more smoothly.



Reply to: