Re: [ 00/10] [Suspend2] Modules support.

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > That's exactly what I'm terribly afraid of.  You have no way to
> > > enforce them, so they won't be respected.  And filesystems will die
> > > randomly and unpredictably.
> > 
> > Yes, this may happen if the userland helpers are buggy, but again any
> > root-equivalent process that is buggy can do the damage just as well.
> > 
> > Your point seem to be "we should implement this in the kernel to protect
> > the users from irresponsible authors of userland applications
> > and distributors".  I just don't agree with that.  [Going along this line of
> > reasoning we should implement fsck in the kernel too. ;-)]
> 
> fsck isn't sexy and is implemented by the authors of the filesystems
> or in close collaboration with them.  Even there, there is a lot of
> talk about fscking live systems but nobody has dared it yet.  That has
> some similarities with your situation.
> 
> There are two parts in your suspend userland helper.  The
> functionality code, which you, and Pavel, and other highly competent
> people will write.  I have no qualms with that one.  And then there
> is

Thanks :-).

> the chrome code, the sexy code, that everybody and his dog is going to
> want to muck with because that's where the looks are.  I'll give it 6
> months at best from when you have a working system before you get a
> submission for some themed, 3d-accelerated buzzword-compliant
> nightmare of a progress bar.  With demented pressure to have it in
> the

Well, this should be more like bootsplash support; simple, preload
bitmaps before you start suspend sequence, no 3d-accelerated
hell. I'll actually make sure I have reasonably-looking progress bar
ready, so people don't have reason to invent some nightmare.

> official distribution because it looks like Babylon 5 on steroids.
> Especially if you have a plugin structure, which otherwise makes a lot
> of sense technically.  Will you be able to trust this code to do no
> disk access and no other state changes that could be problematic (like
> changing vt back to X)?

If they try to switch back to X, it will just deadlock on them. If
they try to communicate using IPC, boom, deadlock. They still may do
something stupid; I'll do my best to educate them not to do
that. Writing to filesystem would be especially bad, for example. But
that should be reasonably easy to understand...
								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/