MACHINE_FEATURE changes

MACHINE_FEATURE changes

[Koen Kooi]

Hi,

Can someone please explain to me what

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=1bfa409a3a28cee60c4800d3caf33ce3f100d4ca

is trying to accomplish? It looks like this makes task-base unusable on 
om-gta0X, am I right?

regards,

Koen

Re: MACHINE_FEATURE changes

[Graeme Gregory]

On Fri, 20 Nov 2009 15:15:23 +0100
Koen Kooi <k.kooi@student.utwente.nl> wrote:

> Hi,
> 
> Can someone please explain to me what
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=1bfa409a3a28cee60c4800d3caf33ce3f100d4ca
> 
> is trying to accomplish? It looks like this makes task-base unusable
> on om-gta0X, am I right?
> 

Haven't done a build, but I think it means nothing other than FSO
based distros can suspend on gta01/02.

Graeme

Re: MACHINE_FEATURE changes

[Sebastian Spaeth]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Koen Kooi wrote:
> Can someone please explain to me what
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=1bfa409a3a28cee60c4800d3caf33ce3f100d4ca
> is trying to accomplish? It looks like this makes task-base unusable on
> om-gta0X, am I right?

FSO/SHR based distros use fso-apm rather than "apm".
Using PROVIDES in fso-apm however means that it's pulled into other
distros too.
We could do this with a virtual/apm but that would mean we need to set a
preferred provider for all other distros too.

So the least intrusive change seemed to remove apm from om-gtaX.
Mickey (informally) agreed with me, and as this change is very limited
in scope, it went in. It is more distro than machine-specific I have to
admit.

Better suggestions on how to achieve this are welcome.

spaetz



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]

Re: MACHINE_FEATURE changes

[Marcin Juszkiewicz]

Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth napisał(a):

> Better suggestions on how to achieve this are welcome.

In distro config:

MACHINE_FEATURES_om-gta01 = "this that those butnoapm"

This way your distro has what you want and others have what was set in machine 
config.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: MACHINE_FEATURE changes

[Michael 'Mickey' Lauer]

Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
> Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth napisał(a):
> 
> > Better suggestions on how to achieve this are welcome.
> 
> In distro config:
> 
> MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
> 
> This way your distro has what you want and others have what was set in machine 
> config.

Good idea.

For the records though, I would consider it being the machine
maintainer's call to define the machine config. If he decides that apm
is very misleading on said machine, perhaps because without taking
special care about the peripheral devices there will no be proper
suspend in the first place, then I might be inclined to follow this
reasoning and leave apm out there...

:M:

Re: MACHINE_FEATURE changes

[Graeme Gregory]

On Fri, 20 Nov 2009 15:39:41 +0100
Michael 'Mickey' Lauer <mickey@vanille-media.de> wrote:

> Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
> > Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth
> > napisał(a):
> > 
> > > Better suggestions on how to achieve this are welcome.
> > 
> > In distro config:
> > 
> > MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
> > 
> > This way your distro has what you want and others have what was set
> > in machine config.
> 
> Good idea.
> 
> For the records though, I would consider it being the machine
> maintainer's call to define the machine config. If he decides that apm
> is very misleading on said machine, perhaps because without taking
> special care about the peripheral devices there will no be proper
> suspend in the first place, then I might be inclined to follow this
> reasoning and leave apm out there...
> 

That indicates to me that FSO is broken. The last I checked any
application which has opened /dev/apm_bios can choose to hold off
the suspend until it has finished doing stuff(tm)

Turning off machine features for a broken DISTRO sounds wrong.

Graeme

Re: MACHINE_FEATURE changes

[Michael 'Mickey' Lauer]

Am Freitag, den 20.11.2009, 14:46 +0000 schrieb Graeme Gregory:
> On Fri, 20 Nov 2009 15:39:41 +0100
> Michael 'Mickey' Lauer <mickey@vanille-media.de> wrote:
> 
> > Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
> > > Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth
> > > napisał(a):
> > > 
> > > > Better suggestions on how to achieve this are welcome.
> > > 
> > > In distro config:
> > > 
> > > MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
> > > 
> > > This way your distro has what you want and others have what was set
> > > in machine config.
> > 
> > Good idea.
> > 
> > For the records though, I would consider it being the machine
> > maintainer's call to define the machine config. If he decides that apm
> > is very misleading on said machine, perhaps because without taking
> > special care about the peripheral devices there will no be proper
> > suspend in the first place, then I might be inclined to follow this
> > reasoning and leave apm out there...
> > 
> 
> That indicates to me that FSO is broken.

On the contrary, dearest friend. FSO is actually one of the few things
which get suspend and resume right on these machines.

>  The last I checked any
> application which has opened /dev/apm_bios can choose to hold off
> the suspend until it has finished doing stuff(tm)

It's not about /dev/apm_bios, it about cooperation with userland that
needs to do certain things like configuring the modem and the gps
devices to get the suspend to work in a deterministic way.

If someone wants to write apm.d script that do the same, they can go for
it and then enable apm per DISTRO or as Koen indicated, per TASK_APM.

:M:

Re: MACHINE_FEATURE changes

[Koen Kooi]

On 20-11-09 15:39, Michael 'Mickey' Lauer wrote:
> Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
>> Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth napisał(a):
>>
>>> Better suggestions on how to achieve this are welcome.
>>
>> In distro config:
>>
>> MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
>>
>> This way your distro has what you want and others have what was set in machine
>> config.
>
> Good idea.
>
> For the records though, I would consider it being the machine
> maintainer's call to define the machine config. If he decides that apm
> is very misleading on said machine, perhaps because without taking
> special care about the peripheral devices there will no be proper
> suspend in the first place, then I might be inclined to follow this
> reasoning and leave apm out there...

If that's the case, it should be at least noted in the commit message 
clearly. In this case it was a commit from someone very new to OE and it 
didn't include any explanation or SOBs or ACKs.

Since this is about the machine the is the default in our GettingStarted 
wiki, a mail to this list would have been nice as well, if only to 
increase the google juice :)

regards,

Koen

Re: MACHINE_FEATURE changes

[Michael 'Mickey' Lauer]

Am Freitag, den 20.11.2009, 15:47 +0100 schrieb Koen Kooi:
> On 20-11-09 15:39, Michael 'Mickey' Lauer wrote:
> > Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
> >> Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth napisał(a):
> >>
> >>> Better suggestions on how to achieve this are welcome.
> >>
> >> In distro config:
> >>
> >> MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
> >>
> >> This way your distro has what you want and others have what was set in machine
> >> config.
> >
> > Good idea.
> >
> > For the records though, I would consider it being the machine
> > maintainer's call to define the machine config. If he decides that apm
> > is very misleading on said machine, perhaps because without taking
> > special care about the peripheral devices there will no be proper
> > suspend in the first place, then I might be inclined to follow this
> > reasoning and leave apm out there...
> 
> If that's the case, it should be at least noted in the commit message 
> clearly. In this case it was a commit from someone very new to OE and it 
> didn't include any explanation or SOBs or ACKs.

True.

Since according to the MAINTAINERS file I seem to be the maintainer of
this machine I think i will reserve my right to change it then. Distros
which absolutely want apm on those Openmoko devices can still include
it.


> Since this is about the machine the is the default in our GettingStarted 
> wiki, a mail to this list would have been nice as well, if only to 
> increase the google juice :)

Heh, right.

:M:

Re: MACHINE_FEATURE changes

[Holger Hans Peter Freyther]

On Friday 20 November 2009 15:39:41 Michael 'Mickey' Lauer wrote:
> Am Freitag, den 20.11.2009, 15:30 +0100 schrieb Marcin Juszkiewicz:
> > Dnia piątek, 20 listopada 2009 o 15:24:39 Sebastian Spaeth napisał(a):
> > > Better suggestions on how to achieve this are welcome.
> >
> > In distro config:
> >
> > MACHINE_FEATURES_om-gta01 = "this that those butnoapm"
> >
> > This way your distro has what you want and others have what was set in
> > machine config.
> 
> Good idea.


Stupid question. What is fso-apm and what does it provide?

Re: MACHINE_FEATURE changes

[Michael 'Mickey' Lauer]

Am Freitag, den 20.11.2009, 19:46 +0100 schrieb Holger Hans Peter
Freyther:
> Stupid question. What is fso-apm and what does it provide?

An apm utility that has the same UI as apm, but uses FSO's DBus API
to do its job.

:M:

Re: MACHINE_FEATURE changes

[Holger Hans Peter Freyther]

On Friday 20 November 2009 19:54:22 Michael 'Mickey' Lauer wrote:
> Am Freitag, den 20.11.2009, 19:46 +0100 schrieb Holger Hans Peter
> 
> Freyther:
> > Stupid question. What is fso-apm and what does it provide?
> 
> An apm utility that has the same UI as apm, but uses FSO's DBus API
> to do its job.

Ah that is a bit unfortunate. You should be able to open /dev/apm_bios more 
than once so you should be able to have the real APM running and then open it 
again in the fso daemon. Didn't this work?

regards
	holger

Re: MACHINE_FEATURE changes

[Phil Blundell]

On Sat, 2009-11-21 at 18:23 +0100, Holger Hans Peter Freyther wrote:
> Ah that is a bit unfortunate. You should be able to open /dev/apm_bios more 
> than once so you should be able to have the real APM running and then open it 
> again in the fso daemon. Didn't this work?

The apm_bios interface is not exactly a paragon of good design: it's
only become as widespread as it has by historical accident, it
represents a weird in-kernel combination of IPC and actual hardware
control, and it isn't available cross-platform in any reliable fashion.

Rather than seeking to perpetuate the use of /dev/apm_bios by random
applications, I think we should encourage other distros to follow FSO's
example and replace it with other mechanisms that are better suited to
the 21st century.  If we could standardise on a single D-Bus API for
user-facing power management, with some kind of daemon responsible for
arbitrating those requests and converting them into whatever operations
are most suitable for the underlying kernel support (which might
be /dev/apm_bios in some circumstances) then that would be perfect.

p.

Re: MACHINE_FEATURE changes

[Koen Kooi]

On 20-11-09 15:24, Sebastian Spaeth wrote:
> Koen Kooi wrote:
>> Can someone please explain to me what
>>
>> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=1bfa409a3a28cee60c4800d3caf33ce3f100d4ca
>> is trying to accomplish? It looks like this makes task-base unusable on
>> om-gta0X, am I right?
>
> FSO/SHR based distros use fso-apm rather than "apm".
> Using PROVIDES in fso-apm however means that it's pulled into other
> distros too.

Which we do not want.

> We could do this with a virtual/apm but that would mean we need to set a
> preferred provider for all other distros too.

So instead you just broke all other distros.

> So the least intrusive change seemed to remove apm from om-gtaX.

Except that you just broke all other distros.

> Mickey (informally) agreed with me, and as this change is very limited
> in scope, it went in. It is more distro than machine-specific I have to
> admit.
>
> Better suggestions on how to achieve this are welcome.

Change task-base and task-boot to use APM =? "apm" and set APM = 
"fso-apm" in your distro.

Please revert the cset since it breaks every distro except SHR[1].

annoyed,

Koen

Re: MACHINE_FEATURE changes

[Sebastian Spaeth]

Koen Kooi wrote:

> Please revert the cset since it breaks every distro except SHR[1].

done

Re: MACHINE_FEATURE changes

[Holger Hans Peter Freyther]

On Friday 20 November 2009 15:41:36 Sebastian Spaeth wrote:
> Koen Kooi wrote:
> > Please revert the cset since it breaks every distro except SHR[1].
> 
> done

One thing with the revert... you have a PR that went backwards. You will have 
to figure out if that is a problem for your distro or not.


holger