On 8/31/12 11:01 AM, Richard Purdie wrote:
On Fri, 2012-08-31 at 15:29 +0100, Phil Blundell wrote:
On Wed, 2012-08-29 at 23:22 +0100, Phil Blundell wrote:
As far as I know, only Intel have ever expressed any real interest in
having this feature work. My recollection is that there are some
supposed "carrier grade" systems where this is, for whatever reason, a
requirement.
None of the carrier-grade people (or indeed any others) seem to have
spoken up in favour of a separate /usr in the past 3 days or so, which
does rather suggest that nobody actually cares about it.
Maybe the TSC would like to reconsider whether this is in fact a
worthwhile thing to go on trying to support in oe-core or whether it
should just assume that / and ${prefix} will be the same filesystem.
I think the people in question are at a conference at the moment and
dealing with a few issues so they fact they haven't spoken up doesn't
surprise me.
As Richard mentioned, a lot of folks were at a conference last week and with the
holiday (in the US) over the weekend were not around to reply before.
I'm fine with merging the symlink change. As others have mentioned, if
it is an issue, a script to turn the links into copies can be written
relatively easily.
Frankly, I'm an advocate of the split, and I'm in favor of the symlink change.
A dangling link is fine for a non-criticial component like a timezone file. If
the system attempts to get the time, it will simply fall back to GMT, which to
me is acceptable on embedded systems.
I don't think dropping support for / and ${prefix} makes sense as long
as it doesn't excessively hurt us. It is up to users to step up and help
maintain the use cases they care about and so far, they have done this.
So I think the position the TSC took is the correct one. Certainly we
can revisit it but its not going to stop this patch going in for
example.
Again, I agree with this.
At Wind River we've been following up and sending patches. The issue is that we
(OE) need to keep reviewing them and determining if they continue to make sense
or not. If we get into a situation where we've moved everything from /usr to /,
it's pretty clear it no longer makes sense! However, we're still far from the
point.
initramdisk (from the comments to the links Khem sent out) is certainly a
primary issue, but not the one I've been focused on in the past...
A number of devices that I've worked with do something -similar- to the ramdisk
for early booting. Boot order becomes:
firmware/bootloader -> kernel -> [small] rootfs mount (RO) -> run init
init -> module loading -> setup -> 'late' udev config -> mount filesystems
(/usr) -> 'early' udev config
(late udev is running the daemon and watching for hotplug events, early udev is
what triggers device creation behaviors. The orders are switched both for
performance, and because other then plugable devices -- the device tree is more
or less static from one boot to the next, so our root has it pre-seeded...)
Many of the devices also have a validation and restoration system on root as
well, that is performed by the setup step. If the validation fails, then
corrective actions can be taken to "fix" the system. The / is always a RO
system.. the device may contain more then one '/' to allow for upgrades, but the
active one is always RO to avoid various potential problems.
The more software that gets put onto the system, the harder it will be to do
field upgrades w/o a reboot. (Since we don't want to allow / to change.)
Keeping the root small makes for a quicker boot, smaller set of partitions, and
easier restoration on failure in my experience.
---
Again, if creating split systems no longer makes sense, I'm not against dumping
the code.. I am going to be monitoring our customers, as much as I'm able, over
the next 6 months -> year and seeing if anyone is doing this type of split
anymore.. if they're not.. then we (OE) may, justifiably, abandon this behavior.
--Mark
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
