From: "Måns Rullgård" <mru@inprovide.com>
To: Wiktor <victorjan@poczta.onet.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFD] 'nice' attribute for executable files
Date: Wed, 30 Mar 2005 21:03:37 +0200 [thread overview]
Message-ID: <yw1xll85vtva.fsf@ford.inprovide.com> (raw)
In-Reply-To: <424AE18B.1080009@poczta.onet.pl> (Wiktor's message of "Wed, 30 Mar 2005 19:27:39 +0200")
Wiktor <victorjan@poczta.onet.pl> writes:
> Måns Rullgård wrote:
>> It can be done entirely in userspace, if you want it. Just hack your
>> shell to examine some extended attribute of your choice, and adjust
>> the nice value before executing files. Then arrange to have the shell
>> run with a negative nice value. This can be easily accomplished with
>> a simple wrapper, only for the shell.
>>
>
> this method can be applied, as you've written, only for shell (which
> have to be hacked before). so, every program that runs any other
> program should be hacked to use
> pre-execution-renice-database. rewriting all the programs in the world
> takes a bit more time than i have to the death. woudn't it be simplier
> to implement it in kernel, somewhere near setuid/setgid bits? if it
> would make system slower, support of such attribute could be optional,
> just like acl-s.
You could wrap /lib/ld-linux.so, and get all dynamically linked
programs done in one sweep.
> i've found a way to perform such function in userland, but it is
> awful, and, if some program runs another, that should be reniced, very
> often, starting a shell (even ash) for each call will surely smoke my
> cpu.
Using a shell to run external programs is quite common. The system()
and popen() functions both invoke the shell.
> this feature without doubt belongs to kernel - it is performed every
> time kernel starts a program, and it is not so complicated like, let's
> say, hotplug support, is it?
I'm not so sure it belongs at all. The can of worms it opens up is a
bit too big, IMHO.
--
Måns Rullgård
mru@inprovide.com
next prev parent reply other threads:[~2005-03-30 19:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.ed33rit.1e148rh@ifi.uio.no>
2005-03-29 20:45 ` [RFD] 'nice' attribute for executable files Bodo Eggert
2005-03-30 16:07 ` Wiktor
2005-03-30 16:55 ` Måns Rullgård
2005-03-30 17:27 ` Wiktor
2005-03-30 19:03 ` Måns Rullgård [this message]
2005-03-30 20:16 ` Wiktor
2005-03-30 20:43 ` Måns Rullgård
2005-04-01 15:26 ` Wiktor
2005-04-01 16:07 ` Måns Rullgård
2005-03-31 5:46 ` Jan Engelhardt
2005-03-31 15:56 ` Horst von Brand
2005-03-31 16:05 ` Måns Rullgård
2005-04-01 15:40 ` Wiktor
2005-04-01 16:12 ` Måns Rullgård
2005-04-01 17:27 ` Horst von Brand
2005-03-30 19:40 ` Bodo Eggert
2005-03-30 21:03 ` Lee Revell
2005-03-29 19:55 Wiktor
2005-03-29 21:02 ` Lee Revell
2005-03-30 19:55 ` Bill Davidsen
2005-03-31 5:51 ` Matt Mackall
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=yw1xll85vtva.fsf@ford.inprovide.com \
--to=mru@inprovide.com \
--cc=linux-kernel@vger.kernel.org \
--cc=victorjan@poczta.onet.pl \
/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.