Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: image.bbclass: USE_DEVFS is now useless
Date: Tue, 01 Apr 2014 22:29:02 +0100	[thread overview]
Message-ID: <1396387742.3038.34.camel@e130.pbcl.net> (raw)
In-Reply-To: <1396374702.2910.27.camel@ted>

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.

p.




  parent reply	other threads:[~2014-04-01 21:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 11:11 image.bbclass: USE_DEVFS is now useless Matthieu CRAPET
2014-04-01 17:44 ` Phil Blundell
2014-04-01 17:48   ` Phil Blundell
2014-04-01 17:51     ` Richard Purdie
2014-04-01 18:01       ` Mark Hatle
2014-04-01 19:34         ` Richard Purdie
2014-04-01 21:29       ` Phil Blundell [this message]
2014-04-02  8:47         ` Paul Eggleton
2014-04-02  8:08 ` Laurentiu Palcu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1396387742.3038.34.camel@e130.pbcl.net \
    --to=pb@pbcl.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox