All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mike (mwester)" <mwester@dls.net>
To: openembedded-devel@openembedded.org
Subject: Re: [PATCH] udev 124: add cache invalidation logic on kernel change or its bootargs/cmdline
Date: Sat, 18 Apr 2009 13:56:29 -0500	[thread overview]
Message-ID: <49EA225D.2040304@dls.net> (raw)
In-Reply-To: <20090418175649.GZ17629@smtp.west.cox.net>

Tom Rini wrote:
> On Sat, Apr 18, 2009 at 11:31:38AM +0200, Koen Kooi wrote:
>> On 16-04-09 18:33, Tom Rini wrote:
>>> On Tue, Apr 14, 2009 at 07:49:58PM -0400, Denys Dmytriyenko wrote:
>>>
>>>> Signed-off-by: Denys Dmytriyenko<denis@denix.org>
>>>> ---
>>>>   recipes/udev/udev-124/init |   10 +++++++++-
>>>>   1 files changed, 9 insertions(+), 1 deletions(-)
>>> So, for making it optional, how about adding something to /etc/default
>>> to enable / disable dev caching all together?  And, I believe
>>> /proc/atags would just be cp /proc/atags /tmp/atags || touch /tmp/atags.
>> Do we really want atags in there? As the name says, they are ARM TAGs,  
>> and only when kexec is enabled. Does it buy us anything over 
>> /proc/cmdline?
> 
> I'll leave that up to mwester as it was his suggestion originally.

Executive Summary: I don't really care one way or another.


Detail for why this was mentioned in the first place:

The discussion that led up the ARM ATAG suggestion involved an
exploration of all the possible things that could happen to a device
that might cause trouble because of a stale cache.  Using /proc/cmdline
is good, but the suggestion to use the ATAG list was offered because it
captures not just the command line itself, but might also capture other
hardware changes.

As a specific example, consider the use case where one takes a bootable
SD-card image from one om-gta02 device, and plugs it into a different
one with a different hardware version (significant on the om-gta0x
devices).  The use of /proc/cmdline will result in a stale cache; the
use of /proc/atags will catch that the revision number in the atag list
has changed.

Is that sufficient reason to use /proc/atags?  I think that's a pretty
far-fetched and unusual use-case, and if someone is doing that, they
should expect things to break.

So I have no real-world concern if just /proc/cmdline is used.


Regards,
Mike (mwester)



      reply	other threads:[~2009-04-18 19:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 23:46 [RFC] Invalidating udev cache Denys Dmytriyenko
2009-04-14 23:49 ` [PATCH] udev 124: add cache invalidation logic on kernel change or its bootargs/cmdline Denys Dmytriyenko
2009-04-15  6:47   ` Koen Kooi
2009-04-15  6:54     ` Holger Schurig
2009-04-16  0:06       ` Denys Dmytriyenko
2009-04-16 12:34         ` Otavio Salvador
2009-04-16 13:04           ` Koen Kooi
2009-04-16 16:33   ` Tom Rini
2009-04-18  9:31     ` Koen Kooi
2009-04-18 17:56       ` Tom Rini
2009-04-18 18:56         ` Mike (mwester) [this message]

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=49EA225D.2040304@dls.net \
    --to=mwester@dls.net \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.