invalidating udev cache, how?

invalidating udev cache, how?

[Koen Kooi]

Hi,

The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev 
dance that can take a few seconds to a minute depending on machine speed 
and kernel options. It is working a bit too well at the moment:

* user boots image with 2.6.26 kernel on an omap board
* user gets /dev/fb0
* user fixes the bootargs in uboot to enable the overlay
* user doesn't get /dev/fb1

so remove /etc/dev.tar and reboot: /dev/fb1 appears.

I also encountered a case where the permissions on /dev/null where wrong 
during first boot (it's a mystery why that happened) and udev cached 
those making ssh daemons fail on boot.

My current ideas:

1) remove /etc/dev.tar if its > x weeks old
2) recreate it on shutdown
3) remove it after x times

option 1) breaks on systems without an RTC and/or no /etc/timestamp
option 2) moves the slowness to shutdown
option 3) requires extra logic and filesystem access

and all options don't fix the first case I mentioned, they all take a 
while to make /dev/fb1 appear.

The key is that it should be transparent to users, so adding a check for 
.e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies 
that users are aware of the problem and know how to 'fix' it.

Does anyone have other ways to invalidate the cache, and if not, which 
option would get your vote?

regards,

Koen

Re: invalidating udev cache, how?

[Tom Rini]

On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote:
> Hi,
>
> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev  
> dance that can take a few seconds to a minute depending on machine speed  
> and kernel options. It is working a bit too well at the moment:
>
> * user boots image with 2.6.26 kernel on an omap board
> * user gets /dev/fb0
> * user fixes the bootargs in uboot to enable the overlay
> * user doesn't get /dev/fb1
>
> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>
> I also encountered a case where the permissions on /dev/null where wrong  
> during first boot (it's a mystery why that happened) and udev cached  
> those making ssh daemons fail on boot.
>
> My current ideas:
>
> 1) remove /etc/dev.tar if its > x weeks old
> 2) recreate it on shutdown
> 3) remove it after x times
>
> option 1) breaks on systems without an RTC and/or no /etc/timestamp
> option 2) moves the slowness to shutdown
> option 3) requires extra logic and filesystem access
>
> and all options don't fix the first case I mentioned, they all take a  
> while to make /dev/fb1 appear.
>
> The key is that it should be transparent to users, so adding a check for  
> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies  
> that users are aware of the problem and know how to 'fix' it.
>
> Does anyone have other ways to invalidate the cache, and if not, which  
> option would get your vote?

2 is a different (and perhaps not as) slow.  Also, prepopulate the cache
with fb1?  Or is this all done on the live system with nothing done
during image creation?

-- 
Tom Rini

Re: invalidating udev cache, how?

[Thomas Kunze]

Koen Kooi schrieb:
> Hi,
>
> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev 
> dance that can take a few seconds to a minute depending on machine 
> speed and kernel options. It is working a bit too well at the moment:
>
> * user boots image with 2.6.26 kernel on an omap board
> * user gets /dev/fb0
> * user fixes the bootargs in uboot to enable the overlay
> * user doesn't get /dev/fb1
>
> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>
> I also encountered a case where the permissions on /dev/null where 
> wrong during first boot (it's a mystery why that happened) and udev 
> cached those making ssh daemons fail on boot.
>
> My current ideas:
>
> 1) remove /etc/dev.tar if its > x weeks old
> 2) recreate it on shutdown
> 3) remove it after x times
>
> option 1) breaks on systems without an RTC and/or no /etc/timestamp
> option 2) moves the slowness to shutdown
> option 3) requires extra logic and filesystem access
>
> and all options don't fix the first case I mentioned, they all take a 
> while to make /dev/fb1 appear.
>
> The key is that it should be transparent to users, so adding a check 
> for .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that 
> implies that users are aware of the problem and know how to 'fix' it.
>
> Does anyone have other ways to invalidate the cache, and if not, which 
> option would get your vote?
I don't think it should be invalidated automagically. Problems only 
happen if some bootloader args are changed, don't they? In this case its
ok to let the user unvalidate the cache. (A user who changes bootloader 
arguments should be able to do this. )
But maybe we should add a message to udev script like:
udev: no coldplugging, using /etc/udev.tar as cache
to make it more obvious that udev uses a cache.

Regards,
Thomas

Re: invalidating udev cache, how?

[Mike (mwester)]

Koen Kooi wrote:
...
> My current ideas:
> 
> 1) remove /etc/dev.tar if its > x weeks old
> 2) recreate it on shutdown
> 3) remove it after x times
> 
> option 1) breaks on systems without an RTC and/or no /etc/timestamp
> option 2) moves the slowness to shutdown
> option 3) requires extra logic and filesystem access
> 
> and all options don't fix the first case I mentioned, they all take a
> while to make /dev/fb1 appear.
> 
> The key is that it should be transparent to users, so adding a check for
> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
> that users are aware of the problem and know how to 'fix' it.
> 
> Does anyone have other ways to invalidate the cache, and if not, which
> option would get your vote?

A slight improvement would be to make the dev.tar file dependent upon
the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
doesn't match the current command line.  This could be a very fast
operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.

Mike (mwester)

Re: invalidating udev cache, how?

[Koen Kooi]

On 04-12-08 17:35, Thomas Kunze wrote:
> Koen Kooi schrieb:
>> Hi,
>>
>> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev
>> dance that can take a few seconds to a minute depending on machine
>> speed and kernel options. It is working a bit too well at the moment:
>>
>> * user boots image with 2.6.26 kernel on an omap board
>> * user gets /dev/fb0
>> * user fixes the bootargs in uboot to enable the overlay
>> * user doesn't get /dev/fb1
>>
>> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>>
>> I also encountered a case where the permissions on /dev/null where
>> wrong during first boot (it's a mystery why that happened) and udev
>> cached those making ssh daemons fail on boot.
>>
>> My current ideas:
>>
>> 1) remove /etc/dev.tar if its > x weeks old
>> 2) recreate it on shutdown
>> 3) remove it after x times
>>
>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>> option 2) moves the slowness to shutdown
>> option 3) requires extra logic and filesystem access
>>
>> and all options don't fix the first case I mentioned, they all take a
>> while to make /dev/fb1 appear.
>>
>> The key is that it should be transparent to users, so adding a check
>> for .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that
>> implies that users are aware of the problem and know how to 'fix' it.
>>
>> Does anyone have other ways to invalidate the cache, and if not, which
>> option would get your vote?
> I don't think it should be invalidated automagically. Problems only
> happen if some bootloader args are changed, don't they? In this case its
> ok to let the user unvalidate the cache. (A user who changes bootloader
> arguments should be able to do this. )
> But maybe we should add a message to udev script like:
> udev: no coldplugging, using /etc/udev.tar as cache
> to make it more obvious that udev uses a cache.

Bootloader args, kernel updates and even changing a powersupply or usb 
hub can change the dev nodes, so putting the burden on the (usually 
unsuspecting) user is not an option. Or imagine things like the BUG 
where coldplugging your modules won't work, only hot-plugging.

regards,

Koen

Re: invalidating udev cache, how?

[Mike (mwester)]

Mike (mwester) wrote:

> A slight improvement would be to make the dev.tar file dependent upon
> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
> doesn't match the current command line.  This could be a very fast
> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.

As I consider this further, we could actually just save and compare
/proc/atags if that's present on the device in question (falling back to
/proc/cmdline if not present).  That would catch *any* changes passed in
to the kernel via the bootloader.

Flashing a new kernel would seem to be another logical place to
invalidate the cache, so adding a comparison of "uname -rv" would be a
reasonable way to catch that.

Mike (mwester)

Re: invalidating udev cache, how?

[Koen Kooi]

On 04-12-08 17:58, Mike (mwester) wrote:
> Koen Kooi wrote:
> ...
>> My current ideas:
>>
>> 1) remove /etc/dev.tar if its>  x weeks old
>> 2) recreate it on shutdown
>> 3) remove it after x times
>>
>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>> option 2) moves the slowness to shutdown
>> option 3) requires extra logic and filesystem access
>>
>> and all options don't fix the first case I mentioned, they all take a
>> while to make /dev/fb1 appear.
>>
>> The key is that it should be transparent to users, so adding a check for
>> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
>> that users are aware of the problem and know how to 'fix' it.
>>
>> Does anyone have other ways to invalidate the cache, and if not, which
>> option would get your vote?
>
> A slight improvement would be to make the dev.tar file dependent upon
> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
> doesn't match the current command line.  This could be a very fast
> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.

That solves only part of the problem, since on omap3 we enable a 
different fb driver that doesn't require any bootargs (and safely 
ignores the ones for the old driver) and gives you an additional overlay 
(/dev/fb2).

But I think combining the 'cmp /proc/cmdline /etc/dev_cmdline' with 
option 2) would solve most of the problems I'm seeing in a not-too-ugly 
way :)

Thanks for the suggestion!

regards,

Koen

Re: invalidating udev cache, how?

[Koen Kooi]

On 04-12-08 17:15, Tom Rini wrote:
> On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote:
>> Hi,
>>
>> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev
>> dance that can take a few seconds to a minute depending on machine speed
>> and kernel options. It is working a bit too well at the moment:
>>
>> * user boots image with 2.6.26 kernel on an omap board
>> * user gets /dev/fb0
>> * user fixes the bootargs in uboot to enable the overlay
>> * user doesn't get /dev/fb1
>>
>> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>>
>> I also encountered a case where the permissions on /dev/null where wrong
>> during first boot (it's a mystery why that happened) and udev cached
>> those making ssh daemons fail on boot.
>>
>> My current ideas:
>>
>> 1) remove /etc/dev.tar if its>  x weeks old
>> 2) recreate it on shutdown
>> 3) remove it after x times
>>
>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>> option 2) moves the slowness to shutdown
>> option 3) requires extra logic and filesystem access
>>
>> and all options don't fix the first case I mentioned, they all take a
>> while to make /dev/fb1 appear.
>>
>> The key is that it should be transparent to users, so adding a check for
>> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
>> that users are aware of the problem and know how to 'fix' it.
>>
>> Does anyone have other ways to invalidate the cache, and if not, which
>> option would get your vote?
>
> 2 is a different (and perhaps not as) slow.  Also, prepopulate the cache
> with fb1?  Or is this all done on the live system with nothing done
> during image creation?

It's done during first boot, since as the problem points out everything 
is highly dependant on bootloader/kernel/moonphase.

regards,

Koen

Re: invalidating udev cache, how?

[Koen Kooi]

On 04-12-08 18:09, Mike (mwester) wrote:
> Mike (mwester) wrote:
>
>> A slight improvement would be to make the dev.tar file dependent upon
>> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
>> doesn't match the current command line.  This could be a very fast
>> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.
>
> As I consider this further, we could actually just save and compare
> /proc/atags if that's present on the device in question (falling back to
> /proc/cmdline if not present).  That would catch *any* changes passed in
> to the kernel via the bootloader.
>
> Flashing a new kernel would seem to be another logical place to
> invalidate the cache, so adding a comparison of "uname -rv" would be a
> reasonable way to catch that.

That should indeed take care of bootargs and kernel version changes. I'm 
still tempted to add option 2) to all that :)

regards,

Koen

Re: invalidating udev cache, how?

[Tom Rini]

On Thu, Dec 04, 2008 at 06:35:10PM +0100, Koen Kooi wrote:
> On 04-12-08 17:15, Tom Rini wrote:
>> On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote:
>>> Hi,
>>>
>>> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev
>>> dance that can take a few seconds to a minute depending on machine speed
>>> and kernel options. It is working a bit too well at the moment:
>>>
>>> * user boots image with 2.6.26 kernel on an omap board
>>> * user gets /dev/fb0
>>> * user fixes the bootargs in uboot to enable the overlay
>>> * user doesn't get /dev/fb1
>>>
>>> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>>>
>>> I also encountered a case where the permissions on /dev/null where wrong
>>> during first boot (it's a mystery why that happened) and udev cached
>>> those making ssh daemons fail on boot.
>>>
>>> My current ideas:
>>>
>>> 1) remove /etc/dev.tar if its>  x weeks old
>>> 2) recreate it on shutdown
>>> 3) remove it after x times
>>>
>>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>>> option 2) moves the slowness to shutdown
>>> option 3) requires extra logic and filesystem access
>>>
>>> and all options don't fix the first case I mentioned, they all take a
>>> while to make /dev/fb1 appear.
>>>
>>> The key is that it should be transparent to users, so adding a check for
>>> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
>>> that users are aware of the problem and know how to 'fix' it.
>>>
>>> Does anyone have other ways to invalidate the cache, and if not, which
>>> option would get your vote?
>>
>> 2 is a different (and perhaps not as) slow.  Also, prepopulate the cache
>> with fb1?  Or is this all done on the live system with nothing done
>> during image creation?
>
> It's done during first boot, since as the problem points out everything  
> is highly dependant on bootloader/kernel/moonphase.

Right.  I was thinking about this more.  That's why internally we do
this differently.  First, what you want cached is only the stuff that
will be cold-plugged (ie whats built into the kernel only, not the
modules to be loaded up after we start udev).  The easy way out is what
we do, provide the full cache as part of the image (and it's OK if you
have fb[012]), and the board guy says "OK, this is ready, here's the
udev cache".

-- 
Tom Rini

Re: invalidating udev cache, how?

[Tom Rini]

On Thu, Dec 04, 2008 at 06:41:50PM +0100, Koen Kooi wrote:
> On 04-12-08 18:09, Mike (mwester) wrote:
>> Mike (mwester) wrote:
>>
>>> A slight improvement would be to make the dev.tar file dependent upon
>>> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
>>> doesn't match the current command line.  This could be a very fast
>>> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.
>>
>> As I consider this further, we could actually just save and compare
>> /proc/atags if that's present on the device in question (falling back to
>> /proc/cmdline if not present).  That would catch *any* changes passed in
>> to the kernel via the bootloader.
>>
>> Flashing a new kernel would seem to be another logical place to
>> invalidate the cache, so adding a comparison of "uname -rv" would be a
>> reasonable way to catch that.
>
> That should indeed take care of bootargs and kernel version changes. I'm  
> still tempted to add option 2) to all that :)

Updating the cache at shutdown means you can end up with random
hotplugged junk sticking around.  It's probably not much messier than
just starting out with a few maybe nodes in your cache, but it's worth
noting.

-- 
Tom Rini

Re: invalidating udev cache, how?

[Koen Kooi]

On 04-12-08 19:49, Tom Rini wrote:
> On Thu, Dec 04, 2008 at 06:35:10PM +0100, Koen Kooi wrote:
>> On 04-12-08 17:15, Tom Rini wrote:
>>> On Thu, Dec 04, 2008 at 05:05:58PM +0100, Koen Kooi wrote:
>>>> Hi,
>>>>
>>>> The udev 124 has cache (/etc/dev.tar) to avoid doing the coldplug udev
>>>> dance that can take a few seconds to a minute depending on machine speed
>>>> and kernel options. It is working a bit too well at the moment:
>>>>
>>>> * user boots image with 2.6.26 kernel on an omap board
>>>> * user gets /dev/fb0
>>>> * user fixes the bootargs in uboot to enable the overlay
>>>> * user doesn't get /dev/fb1
>>>>
>>>> so remove /etc/dev.tar and reboot: /dev/fb1 appears.
>>>>
>>>> I also encountered a case where the permissions on /dev/null where wrong
>>>> during first boot (it's a mystery why that happened) and udev cached
>>>> those making ssh daemons fail on boot.
>>>>
>>>> My current ideas:
>>>>
>>>> 1) remove /etc/dev.tar if its>   x weeks old
>>>> 2) recreate it on shutdown
>>>> 3) remove it after x times
>>>>
>>>> option 1) breaks on systems without an RTC and/or no /etc/timestamp
>>>> option 2) moves the slowness to shutdown
>>>> option 3) requires extra logic and filesystem access
>>>>
>>>> and all options don't fix the first case I mentioned, they all take a
>>>> while to make /dev/fb1 appear.
>>>>
>>>> The key is that it should be transparent to users, so adding a check for
>>>> .e.g 'ignore_dev.tar=1' in bootargs wouldn't work, since that implies
>>>> that users are aware of the problem and know how to 'fix' it.
>>>>
>>>> Does anyone have other ways to invalidate the cache, and if not, which
>>>> option would get your vote?
>>> 2 is a different (and perhaps not as) slow.  Also, prepopulate the cache
>>> with fb1?  Or is this all done on the live system with nothing done
>>> during image creation?
>> It's done during first boot, since as the problem points out everything
>> is highly dependant on bootloader/kernel/moonphase.
>
> Right.  I was thinking about this more.  That's why internally we do
> this differently.  First, what you want cached is only the stuff that
> will be cold-plugged (ie whats built into the kernel only, not the
> modules to be loaded up after we start udev).  The easy way out is what
> we do, provide the full cache as part of the image (and it's OK if you
> have fb[012]), and the board guy says "OK, this is ready, here's the
> udev cache".

That also makes it pretty much machines specific, which is something I'd 
like to avoid. But you're right, it would make things slightly better, 
but it doesn't scale with kernel versions, bootargs variations, board 
variations and general appearances of Murphy.
And the boards I'm working with now have a lot of usb drivers builtin, 
and I will need to spend a lot of time on google to work out all the 
devnodes.

regards,

Koen

Re: invalidating udev cache, how?

[Tom Rini]

On Thu, Dec 04, 2008 at 08:02:44PM +0100, Koen Kooi wrote:
> On 04-12-08 19:49, Tom Rini wrote:
[snip]
>> Right.  I was thinking about this more.  That's why internally we do
>> this differently.  First, what you want cached is only the stuff that
>> will be cold-plugged (ie whats built into the kernel only, not the
>> modules to be loaded up after we start udev).  The easy way out is what
>> we do, provide the full cache as part of the image (and it's OK if you
>> have fb[012]), and the board guy says "OK, this is ready, here's the
>> udev cache".
>
> That also makes it pretty much machines specific, which is something I'd  
> like to avoid. But you're right, it would make things slightly better,  
> but it doesn't scale with kernel versions, bootargs variations, board  
> variations and general appearances of Murphy.
> And the boards I'm working with now have a lot of usb drivers builtin,  
> and I will need to spend a lot of time on google to work out all the  
> devnodes.

I'm not sure it won't scale, but honestly I do have a much more
controlled environment.  But, I see it being a generic hook (if it
exists, use it) that's machine specific (so it's always machine correct)
being a feature, not a bug.  bootargs and board variations don't matter
here, your machine-specific cache should have every cold-plug device
present (again, wasting space on a few extra dev nodes saves sanity and
prevents non-working situations later).

Also, USB is exactly what you don't want to have cached.  When I was
investigating this a while back, it was ptys and other very common stuff
that was 95% of the nodes being created.  The rest was framebuffer, UBI
control and so on.  But even with USB, it comes down to what's going to
get a coldplug faked hotplug, not what will be plugged in later.
External devices that stay plugged in through a reset can be re-created
in the background and will exist before the user can really do anything,
I'm willing to be (as that's what I saw on our boards).

>
> regards,
>
> Koen
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Tom Rini

Re: invalidating udev cache, how?

[Denys Dmytriyenko]

On Thu, Dec 04, 2008 at 06:41:50PM +0100, Koen Kooi wrote:
> On 04-12-08 18:09, Mike (mwester) wrote:
>> Mike (mwester) wrote:
>>
>>> A slight improvement would be to make the dev.tar file dependent upon
>>> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
>>> doesn't match the current command line.  This could be a very fast
>>> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.
>>
>> As I consider this further, we could actually just save and compare
>> /proc/atags if that's present on the device in question (falling back to
>> /proc/cmdline if not present).  That would catch *any* changes passed in
>> to the kernel via the bootloader.
>>
>> Flashing a new kernel would seem to be another logical place to
>> invalidate the cache, so adding a comparison of "uname -rv" would be a
>> reasonable way to catch that.
>
> That should indeed take care of bootargs and kernel version changes. I'm 
> still tempted to add option 2) to all that :)

Sorry for bringing up this old discussion. Are there any plans to implement 
the above checks in udev?

-- 
Denys

Re: invalidating udev cache, how?

[Koen Kooi]

On 03-03-09 06:11, Denys Dmytriyenko wrote:
> On Thu, Dec 04, 2008 at 06:41:50PM +0100, Koen Kooi wrote:
>> On 04-12-08 18:09, Mike (mwester) wrote:
>>> Mike (mwester) wrote:
>>>
>>>> A slight improvement would be to make the dev.tar file dependent upon
>>>> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
>>>> doesn't match the current command line.  This could be a very fast
>>>> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.
>>> As I consider this further, we could actually just save and compare
>>> /proc/atags if that's present on the device in question (falling back to
>>> /proc/cmdline if not present).  That would catch *any* changes passed in
>>> to the kernel via the bootloader.
>>>
>>> Flashing a new kernel would seem to be another logical place to
>>> invalidate the cache, so adding a comparison of "uname -rv" would be a
>>> reasonable way to catch that.
>> That should indeed take care of bootargs and kernel version changes. I'm
>> still tempted to add option 2) to all that :)
>
> Sorry for bringing up this old discussion. Are there any plans to implement
> the above checks in udev?

Plans yes, time no :(

regards,

Koen

Re: invalidating udev cache, how?

[Tom Rini]

On Tue, Mar 03, 2009 at 08:24:44AM +0100, Koen Kooi wrote:
> On 03-03-09 06:11, Denys Dmytriyenko wrote:
>> On Thu, Dec 04, 2008 at 06:41:50PM +0100, Koen Kooi wrote:
>>> On 04-12-08 18:09, Mike (mwester) wrote:
>>>> Mike (mwester) wrote:
>>>>
>>>>> A slight improvement would be to make the dev.tar file dependent upon
>>>>> the bootargs; i.e. invalidate /etc/dev.tar file if the boot command line
>>>>> doesn't match the current command line.  This could be a very fast
>>>>> operation, just "cmp /proc/cmdline /etc/dev_cmdline" or similar.
>>>> As I consider this further, we could actually just save and compare
>>>> /proc/atags if that's present on the device in question (falling back to
>>>> /proc/cmdline if not present).  That would catch *any* changes passed in
>>>> to the kernel via the bootloader.
>>>>
>>>> Flashing a new kernel would seem to be another logical place to
>>>> invalidate the cache, so adding a comparison of "uname -rv" would be a
>>>> reasonable way to catch that.
>>> That should indeed take care of bootargs and kernel version changes. I'm
>>> still tempted to add option 2) to all that :)
>>
>> Sorry for bringing up this old discussion. Are there any plans to implement
>> the above checks in udev?
>
> Plans yes, time no :(

Can we make sure they're optional?

-- 
Tom Rini