[OE-core] image.bbclass: USE_DEVFS is now useless

[Paul Eggleton]

On Tuesday 01 April 2014 22:29:02 Phil Blundell wrote:
> On Tue, 2014-04-01 at 18:51 +0100, Richard Purdie wrote:
> > On Tue, 2014-04-01 at 18:48 +0100, Phil Blundell wrote:
> > > Also note that the default for USE_DEVFS was (and is) 1, so the lack
> > > of this check is actually causing a difference in the default
> > > behaviour.  If there's no appetite for reinstating the USE_DEVFS
> > > mechanism per se then it seems like it would be a good idea to make
> > > the default IMAGE_DEVICE_TABLE be blank in order to restore the
> > > previous default of no /dev in the rootfs.
> > > 
> > > At present you get a somewhat arbitrary-seeming smattering of devices
> > > from meta/files/device_table-minimal.txt, including such anachronisms
> > > as /dev/ttySA0 and /dev/apm_bios.  It's hard to imagine that anybody
> > > actually wants this stuff in their rootfs in this day and age.
> > 
> > Can we kill apmd at the same time? Please? :)
> 
> I can't see why not.  I'd be surprised if there were many/any real users
> left, beyond possibly some legacy stuff in meta-handheld, and it
> definitely doesn't seem "core" by any reasonable interpretation of the
> term.
> 
> Apart from packagegrounds, the only recipe in oe-core that mentions a
> dependency on apmd is matchbox-panel (for the battery applet
> presumably); that dependency is conditional on having apm in
> MACHINE_FEATURES (which it isn't by default), and it seems a bit fishy
> anyway since I can't immediately think of a reason why matchbox-panel
> would need the actual daemon.
> 
> So, I think it should probably be safe to just rescind support for both
> apmd and the MACHINE_FEATURE apm in oe-core.  If meta-handheld, meta-oe
> or anybody else wants to keep apmd then they can do so in their own
> layers although I rather hope that nobody does.

I'm generally in favour of this too, however, one of the things that apmd 
provided was the ability to have scripts run on suspend/resume - is there a 
more modern mechanism that should replace this? zaurusd and opie currently 
rely on this (yeah, I know...)

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre