RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER

RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER

[Rod Whitby]

> <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER to task-boot or task-base, depending on flash size.
> <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> <koen> to distinguish between task-bootstrap and task-base
> <rwhitby> does task-bootstrap still exist?
> <koen> rwhitby: I hope not
> <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason for existence then?
> <rwhitby> (and no definition of what it should be used for if it did have a current reason for existence)
> <koen> rwhitby: not that I know off, but your task-boot suggestion would make sense
> <rwhitby> koen: So it really should now be called something like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> <rwhitby> (since it doesn't have anything to do with MACHINEs)
> <koen> nor with BOOTSTRAP
> <koen> something like DEFAULT_TASK_PROVIDER?
> <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> <koen> do you want to write an RFC for that?

The proposal is to replace MACHINE_TASK_PROVIDER with
DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
set to task-boot, or task-base, or perhaps some other distro-specific
single task-foo value), plus other image-specific stuff.

Comments?  Objections?

BTW, task-bootstrap existence is as follows:

> ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstrap = "task-base"
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap = "1.0unionroot"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES = "task-bootstrap"
> ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require task-bootstrap.inc
> ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> ./packages/images/jlime-opie.bb:INSTALL_PACKAGES = "task-bootstrap task-opie-base task-opie-base-applets \
> ./removal.txt:Package Name:   task-bootstrap*

-- Rod

squasfs jffs2 default image settings

[Stelios Koroneos]

After a day of "head scratching" i realized the the reason an image i was
building, failed to load on a powerpc target was that the default settings
for squashfs squashfs-lzma and jffs2 were set to little endian architecture

//snip from  bitbake.conf

EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
EXTRA_IMAGECMD_squashfs = "-le -b 16384"
EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"

These look like they were set for a specific machine (maybe i am wrong), but
shouldn't the default settings be at least architecture neutral ?
(Even the block sizes shouldn't be defined there as a machine might be
better suited by another size)

Any objections to have EXTRA_IMAGECMD for these types of images default to
no specific settings  ?

Stelios S. Koroneos

Digital OPSiS - Embedded Inteligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces@openembedded.org
> [mailto:openembedded-devel-bounces@openembedded.org]On Behalf Of
> Rod Whitby
> Sent: Tuesday, May 01, 2007 11:17 AM
> To: openembedded-devel@openembedded.org
> Subject: [oe] RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER
>
>
> > <rwhitby> so in my mokoslug distro, I set MACHINE_TASK_PROVIDER
> to task-boot or task-base, depending on flash size.
> > <rwhitby> what is MACHINE_TASK_PROVIDER really meant to be used for?
> > <koen> to distinguish between task-bootstrap and task-base
> > <rwhitby> does task-bootstrap still exist?
> > <koen> rwhitby: I hope not
> > <rwhitby> koen: so MACHINE_TASK_PROVIDER has no current reason
> for existence then?
> > <rwhitby> (and no definition of what it should be used for if
> it did have a current reason for existence)
> > <koen> rwhitby: not that I know off, but your task-boot
> suggestion would make sense
> > <rwhitby> koen: So it really should now be called something
> like BOOTSTRAP_IMAGE_FOUNDATION_TASK or something?
> > <rwhitby> (since it doesn't have anything to do with MACHINEs)
> > <koen> nor with BOOTSTRAP
> > <koen> something like DEFAULT_TASK_PROVIDER?
> > <rwhitby> yep, DEFAULT_TASK_PROVIDER floats my boat.
> > <koen> do you want to write an RFC for that?
>
> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.
>
> Comments?  Objections?
>
> BTW, task-bootstrap existence is as follows:
>
> > ./conf/distro/generic.conf:PREFERRED_PROVIDER_task-bootstrap =
> "task-bootstrap"
> >
> ./conf/distro/include/oplinux.inc:PREFERRED_PROVIDER_task-bootstra
> p = "task-base"
> >
> ./conf/distro/angstrom-2007.1.conf:PREFERRED_PROVIDER_task-bootstr
> ap = "task-bootstrap"
> >
> ./conf/distro/jlime-donkey.conf:PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> >
> ./conf/distro/openprotium.conf:#PREFERRED_PROVIDER_task-bootstrap
> = "task-bootstrap"
> > ./conf/machine/gumstix.conf:PREFERRED_VERSION_task-bootstrap =
> "1.0unionroot"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:PROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:RPROVIDES
> = "task-bootstrap"
> > ./packages/obsolete/tasks/task-bootstrap-unionroot.bb:require
> task-bootstrap.inc
> > ./packages/obsolete/tasks/task-bootstrap.bb:require task-bootstrap.inc
> > ./packages/images/jlime-opie.bb:DEPENDS = "task-bootstrap task-opie"
> > ./packages/images/jlime-opie.bb:INSTALL_PACKAGES =
> "task-bootstrap task-opie-base task-opie-base-applets \
> > ./removal.txt:Package Name:   task-bootstrap*
>
> -- Rod
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: squasfs jffs2 default image settings

[Rod Whitby]

Stelios Koroneos wrote:
> After a day of "head scratching" i realized the the reason an image i was
> building, failed to load on a powerpc target was that the default settings
> for squashfs squashfs-lzma and jffs2 were set to little endian architecture
> 
> //snip from  bitbake.conf
> 
> EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x40000"
> EXTRA_IMAGECMD_squashfs = "-le -b 16384"
> EXTRA_IMAGECMD_squashfs-lzma = "-le -b 16384"
> 
> These look like they were set for a specific machine (maybe i am wrong), but
> shouldn't the default settings be at least architecture neutral ?
> (Even the block sizes shouldn't be defined there as a machine might be
> better suited by another size)
> 
> Any objections to have EXTRA_IMAGECMD for these types of images default to
> no specific settings  ?

Fine with me.  I think the nslu2 and ixp4xx are the few dual-endian
machines in OE, and both of them are already set up to set the
endianness, padding and block size on those commands explicitly.

-- Rod

Re: RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER

[Marcin Juszkiewicz]

Dnia wtorek, 1 maja 2007, Rod Whitby napisał:

> The proposal is to replace MACHINE_TASK_PROVIDER with
> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
> set to task-boot, or task-base, or perhaps some other distro-specific
> single task-foo value), plus other image-specific stuff.

DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
devices) in a way that we will have:

- task-boot
- task-base
- task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)

This way we will be able to create images with wifi/bt support for PDA 
with pcmcia but no internal wifi/bt by using task-base-extended as 
DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
amount of space for rootfs will get task-base so users will be free to 
install extra stuff.

What do you think?

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.

Re: RFC: Rename MACHINE_TASK_PROVIDER to DEFAULT_TASK_PROVIDER

[Rod Whitby]

Marcin Juszkiewicz wrote:
> Dnia wtorek, 1 maja 2007, Rod Whitby napisał:
> 
>> The proposal is to replace MACHINE_TASK_PROVIDER with
>> DEFAULT_TASK_PROVIDER throughout OE, and encourage all image-foo.bb
>> maintainers to base their image on DEFAULT_TASK_PROVIDER (which can be
>> set to task-boot, or task-base, or perhaps some other distro-specific
>> single task-foo value), plus other image-specific stuff.
> 
> DEFAULT_TASK_PROVIDER is good idea for me. I would like to merge it with 
> my proposal change to task-base (adding wifi/bt for pcmcia/usbhost/pci 
> devices) in a way that we will have:
> 
> - task-boot
> - task-base
> - task-base-extended (wifi/bt added for pcmcia/usbhost/pci machines)
> 
> This way we will be able to create images with wifi/bt support for PDA 
> with pcmcia but no internal wifi/bt by using task-base-extended as 
> DEFAULT_TASK_PROVIDER (set in distro config) and devices with smaller 
> amount of space for rootfs will get task-base so users will be free to 
> install extra stuff.
> 
> What do you think?

+1 from me.

Can you add:

PROVIDES = "${PACKAGES}"

to task-base.bb while you are there?  I know it should not be required
(it should happen automatically), but for some reason the automatic
stuff is not working for this file at the moment.  I cannot build an
image based on task-boot instead of task-base without doing the above.

-- Rod