* invalidating udev cache, how?
@ 2008-12-04 16:05 Koen Kooi
2008-12-04 16:15 ` Tom Rini
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Koen Kooi @ 2008-12-04 16:05 UTC (permalink / raw)
To: openembedded-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: invalidating udev cache, how? 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 16:35 ` Thomas Kunze 2008-12-04 16:58 ` Mike (mwester) 2 siblings, 1 reply; 16+ messages in thread From: Tom Rini @ 2008-12-04 16:15 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:15 ` Tom Rini @ 2008-12-04 17:35 ` Koen Kooi 2008-12-04 18:49 ` Tom Rini 0 siblings, 1 reply; 16+ messages in thread From: Koen Kooi @ 2008-12-04 17:35 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 17:35 ` Koen Kooi @ 2008-12-04 18:49 ` Tom Rini 2008-12-04 19:02 ` Koen Kooi 0 siblings, 1 reply; 16+ messages in thread From: Tom Rini @ 2008-12-04 18:49 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 18:49 ` Tom Rini @ 2008-12-04 19:02 ` Koen Kooi 2008-12-04 19:17 ` Tom Rini 0 siblings, 1 reply; 16+ messages in thread From: Koen Kooi @ 2008-12-04 19:02 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 19:02 ` Koen Kooi @ 2008-12-04 19:17 ` Tom Rini 0 siblings, 0 replies; 16+ messages in thread From: Tom Rini @ 2008-12-04 19:17 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:05 invalidating udev cache, how? Koen Kooi 2008-12-04 16:15 ` Tom Rini @ 2008-12-04 16:35 ` Thomas Kunze 2008-12-04 17:03 ` Koen Kooi 2008-12-04 16:58 ` Mike (mwester) 2 siblings, 1 reply; 16+ messages in thread From: Thomas Kunze @ 2008-12-04 16:35 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:35 ` Thomas Kunze @ 2008-12-04 17:03 ` Koen Kooi 0 siblings, 0 replies; 16+ messages in thread From: Koen Kooi @ 2008-12-04 17:03 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:05 invalidating udev cache, how? Koen Kooi 2008-12-04 16:15 ` Tom Rini 2008-12-04 16:35 ` Thomas Kunze @ 2008-12-04 16:58 ` Mike (mwester) 2008-12-04 17:09 ` Mike (mwester) 2008-12-04 17:11 ` Koen Kooi 2 siblings, 2 replies; 16+ messages in thread From: Mike (mwester) @ 2008-12-04 16:58 UTC (permalink / raw) To: openembedded-devel 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:58 ` Mike (mwester) @ 2008-12-04 17:09 ` Mike (mwester) 2008-12-04 17:41 ` Koen Kooi 2008-12-04 17:11 ` Koen Kooi 1 sibling, 1 reply; 16+ messages in thread From: Mike (mwester) @ 2008-12-04 17:09 UTC (permalink / raw) To: openembedded-devel 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 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 0 siblings, 2 replies; 16+ messages in thread From: Koen Kooi @ 2008-12-04 17:41 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 17:41 ` Koen Kooi @ 2008-12-04 18:50 ` Tom Rini 2009-03-03 5:11 ` Denys Dmytriyenko 1 sibling, 0 replies; 16+ messages in thread From: Tom Rini @ 2008-12-04 18:50 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 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 1 sibling, 1 reply; 16+ messages in thread From: Denys Dmytriyenko @ 2009-03-03 5:11 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2009-03-03 5:11 ` Denys Dmytriyenko @ 2009-03-03 7:24 ` Koen Kooi 2009-03-03 15:16 ` Tom Rini 0 siblings, 1 reply; 16+ messages in thread From: Koen Kooi @ 2009-03-03 7:24 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2009-03-03 7:24 ` Koen Kooi @ 2009-03-03 15:16 ` Tom Rini 0 siblings, 0 replies; 16+ messages in thread From: Tom Rini @ 2009-03-03 15:16 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: invalidating udev cache, how? 2008-12-04 16:58 ` Mike (mwester) 2008-12-04 17:09 ` Mike (mwester) @ 2008-12-04 17:11 ` Koen Kooi 1 sibling, 0 replies; 16+ messages in thread From: Koen Kooi @ 2008-12-04 17:11 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2009-03-03 15:20 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.