[oe] 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Tom Rini