Re: Suspend 2 merge: 35/51: Code always built in to the kernel.

[Pavel Machek]

Hi!

> > You have your own abstraction on the top of /proc? That's no-no.
> 
> You'd prefer the same code repeated 20 times?

Rest of kernel is pretty happy with /proc as-is. Why can't suspend2
just play along?

How many options are really neccessary? activate is not. selecting of
reboot can already be done in /sys. Some percentages? There really
should not be 20 things to configure.

> > > +		say("BIG FAT WARNING!! %s\n\n", suspend_print_buf);
> > > +		if (can_erase_image) {
> > > +			say("If you want to use the current suspend image, reboot and try\n");
> > > +			say("again with the same kernel that you suspended from. If you want\n");
> > > +			say("to forget that image, continue and the image will be erased.\n");
> > > +		} else {
> > > +			say("If you continue booting, note that any image WILL NOT BE REMOVED.\n");
> > > +			say("Suspend is unable to do so because the appropriate modules aren't\n");
> > > +			say("loaded. You should manually remove the image to avoid any\n");
> > > +			say("possibility of corrupting your filesystem(s) later.\n");
> > > +		}
> > > +		say("Press SPACE to reboot or C to continue booting with this kernel\n");
> > 
> > Plus kernel now actually expects user interaction to solve problems
> > during boot. No, no.
> 
> You want your cake and to eat it too? :> We don't want to warn the user
> before they shoot themselves in the foot, but not loudly enough that
> they can't help notice and choose to do something before the damage is
> done?

Kernel boot is not expected to be interactive. I'd do

if (can_erase_image)
	printk("Incorrect kernel version, image killed\n");
else
	panic("Can't kill suspended image");

									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/