On ?t 10-03-05 16:42:18, David Zeuthen wrote: > On Thu, 2005-03-10 at 22:13 +0100, Pavel Machek wrote: > > On Thu 10-03-05 12:37:57, David Zeuthen wrote: > > > On Thu, 2005-03-10 at 10:56 +0100, Pavel Machek wrote: > > > > > Is it a problem providing these events? > > > > > > > > Why bloat kernel? > > > > > > How is this bloating the kernel? Do you disagree that asynchronous > > > notification is a good thing? I think not because that's exactly why the > > > kobject_uevent stuff was put it in the kernel in the first place. > > > > kobject_uevent in kernel does not mean we have to abuse it for suspend notifycation. > > (How would that notifycation work, btw? If done asynchronously, system will be suspended > > before processes will have chance to do anything). > > > > I was merely asking for an event when the system is resumed. > > I agree it doesn't make much sense for an event just before the system > is suspended - if this is needed I believe we can orchestrate it > completely from user space (things like making your email app > synchronize etc. comes to mind). You can have event when the system is resumed. Just do it in userspace. > > 1st explain why such notifycation is needed > > Things like e.g. networking needs to be initialized (check DHCP lease, > find a new access point, select new active device etc.) - we need this > for e.g. NetworkManager. > > Applications with timeouts, such as screen savers, needs tweaking too. > No problem, so, for example, running everything in /etc/resume.d/ would do the trick? No problem then. Modify your suspend script to do echo 4 > /proc/acpi/sleep /etc/resume.d/* . I'm *not* going to do that from kernel. But standartizing what needs to be ran on resume is indeed good idea, and few lines in Documentation/power/* are probably worth it. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
