From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Duplicate recipes in meta-oe
Date: Mon, 6 Feb 2012 14:02:14 -0600 [thread overview]
Message-ID: <4F3031C6.4010805@windriver.com> (raw)
In-Reply-To: <4F302D77.7030902@balister.org>
On 2/6/12 1:43 PM, Philip Balister wrote:
> On 02/06/2012 10:55 AM, Phil Blundell wrote:
>> On Mon, 2012-02-06 at 15:39 +0000, Paul Eggleton wrote:
>>> I talked to Koen at FOSDEM and apparently he prefers having a symlink rather
>>> than a copy for the timezone file. I can't express an opinion one way or
>>> another but it sounds like this one aspect still needs to be resolved - should
>>> this be selectable?
>>
>> I guess this is all bound up with the "/usr on a separate partition"
>> thing. If your position is that the root filesystem is meant to work
>> without /usr mounted then having /etc/localtime be a symlink
>> into /usr/share is probably not going to fly. Conversely, one were to
>> take the view that any reasonable system in the 21st century is going to
>> have / anḍ /usr on the same device, making it be a symlink would be a
>> fine idea.
>>
>> I think probably the right answer is to make "1970s-usr" be a
>> DISTRO_FEATURE and then the timezone recipes (and others) can adapt
>> themselves accordingly.
>
> Does anyone use a system where /usr is on a separate partition?
Where I have seen it is on some carrier grade blade systems. Each blade has a
small local boot partition, which a shared (read-only) /usr partition. The
small boot partition handles initial booting, setup and mounting.. while the
shared partition handles the majority of "unix infrastructure".
These systems do not use ramdisks, initrds, etc...
I'm also aware of some other systems that do this for boot performance reasons..
they do it for booting quickly to the main UI app, and in parallel mounting and
loading additional runtime apps from the /usr disk (RO) and a /var (RW) disk.
As things are available the UI options are made available to the end user. The
result is a -faster- perceived boot. Again ramdisks/initrds are not used
because of various reasons.
--Mark
> Philip
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
next prev parent reply other threads:[~2012-02-06 20:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-04 17:12 Duplicate recipes in meta-oe Khem Raj
2012-02-04 18:19 ` Khem Raj
2012-02-06 15:39 ` Paul Eggleton
2012-02-06 15:47 ` [oe] " Otavio Salvador
2012-02-06 15:55 ` Phil Blundell
2012-02-06 16:07 ` Koen Kooi
2012-02-06 19:43 ` Philip Balister
2012-02-06 20:02 ` Mark Hatle [this message]
2012-02-06 20:20 ` Phil Blundell
2012-02-06 20:48 ` Mark Hatle
2012-02-06 22:35 ` Phil Blundell
2012-02-06 23:38 ` Mark Hatle
2012-02-06 22:59 ` Khem Raj
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=4F3031C6.4010805@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.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