Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: invalidating udev cache, how?
Date: Thu, 04 Dec 2008 18:11:58 +0100	[thread overview]
Message-ID: <gh930v$ks4$1@ger.gmane.org> (raw)
In-Reply-To: <49380C4F.1050809@dls.net>

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




      parent reply	other threads:[~2008-12-04 17:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04 16:05 invalidating udev cache, how? Koen Kooi
2008-12-04 16:15 ` Tom Rini
2008-12-04 17:35   ` Koen Kooi
2008-12-04 18:49     ` Tom Rini
2008-12-04 19:02       ` Koen Kooi
2008-12-04 19:17         ` Tom Rini
2008-12-04 16:35 ` Thomas Kunze
2008-12-04 17:03   ` Koen Kooi
2008-12-04 16:58 ` Mike (mwester)
2008-12-04 17:09   ` Mike (mwester)
2008-12-04 17:41     ` Koen Kooi
2008-12-04 18:50       ` Tom Rini
2009-03-03  5:11       ` Denys Dmytriyenko
2009-03-03  7:24         ` Koen Kooi
2009-03-03 15:16           ` Tom Rini
2008-12-04 17:11   ` Koen Kooi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='gh930v$ks4$1@ger.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox