[oe] [PATCH] udev 124: add cache invalidation logic on kernel change or its bootargs/cmdline

[Mike (mwester)]

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 at 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)