Re: invalidating udev cache, how?

[Koen Kooi <k.kooi@student.utwente.nl>]

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