From: "Måns Rullgård" <mru@inprovide.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Configurable Magic Sysrq
Date: Fri, 29 Oct 2004 15:44:38 +0200 [thread overview]
Message-ID: <yw1xlldpiqpl.fsf@inprovide.com> (raw)
In-Reply-To: <20041029133527.GA25172@atrey.karlin.mff.cuni.cz> (Jan Kara's message of "Fri, 29 Oct 2004 15:35:27 +0200")
Jan Kara <jack@suse.cz> writes:
>> Andrew Morton <akpm@osdl.org> writes:
>>
>> > Jan Kara <jack@suse.cz> wrote:
>> >>
>> >> I know about a few people who would like to use some functionality of
>> >> the Magic Sysrq but don't want to enable all the functions it provides.
>> >
>> > That's a new one. Can you tell us more about why people want to do such a
>> > thing?
>> >
>> >> So I wrote a patch which should allow them to do so. It allows to
>> >> configure available functions of Sysrq via /proc/sys/kernel/sysrq (the
>> >> interface is backward compatible). If you think it's useful then use it :)
>> >> Andrew, do you think it can go into mainline or it's just an overdesign?
>> >
>> > Patch looks reasonable - we just need to decide whether the requirement
>> > warrants its inclusion.
>> >
>> > There have been a few changes in the sysrq code since 2.6.9 and there are
>> > more changes queued up in -mm. The patch applies OK, but it'll need
>> > checking and redoing. There's a new `sysrq-f' command in the pipeline
>> > which causes a manual oom-killer call.
>>
>> See also the patch I just posted to lkml.
> OK, Andrew, are you accepting the patch? The sysrq should probably go
> into SYSRQ_ENABLE_SIGNAL group...
Don't miss the update I posted a few minutes later.
>> I also thought of an improved way of selecting keys to enable.
>> Instead of an arbitrary bitmask, would it be possible to simply list
>> the keys you want to enable, such as "echo sku > /proc/sys/kernel/sysrq"?
> That would be possible of course but you'd have to do your own
> parsing in kernel and you are not supposed to change the sysrq
> setting often - usually just compute your favourite number, put it
> into boot scripts and you're done. So I'm not convinced it's useful
> very much.
I'm not likely to use either of them, so I'll leave it to you.
--
Måns Rullgård
mru@inprovide.com
next prev parent reply other threads:[~2004-10-29 13:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-29 9:39 [PATCH] Configurable Magic Sysrq Jan Kara
2004-10-29 9:46 ` Andrew Morton
2004-10-29 10:17 ` Jan Kara
2004-10-29 10:24 ` Andrew Morton
2004-10-29 20:09 ` Dave Jones
2004-10-30 6:45 ` Olaf Hering
2004-11-01 9:29 ` Jan Kara
2004-10-31 18:59 ` Pavel Machek
2004-10-29 11:34 ` Måns Rullgård
2004-10-29 13:35 ` Jan Kara
2004-10-29 13:44 ` Måns Rullgård [this message]
2004-10-29 14:33 ` Jan Engelhardt
2004-10-29 14:50 ` Jan Kara
2004-10-29 14:53 ` Jan Engelhardt
2004-11-01 9:09 ` Jan Kara
2004-10-31 18:52 ` Pavel Machek
2004-10-31 19:09 ` Dmitry Torokhov
2004-10-31 19:44 ` Pavel Machek
2004-10-31 19:12 ` Andreas Schwab
2004-11-01 0:52 ` Tim Connors
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=yw1xlldpiqpl.fsf@inprovide.com \
--to=mru@inprovide.com \
--cc=akpm@osdl.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.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 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.