[oe] invalidating udev cache, how?

Tom Rini trini at kernel.crashing.org
Thu Dec 4 16:15:43 UTC 2008


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




More information about the Openembedded-devel mailing list