chrt requires priority argument

chrt requires priority argument

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

chrt requires a priority argument, even for classes ( like batch )
that do not support them.  If you specify a non zero value, then the
command fails.  I think the argument should be ignored and forced to
zero for these classes, and the man page updated to indicate that the
priority is ignored for those classes that don't use it.  If the
argument could be made optional so you can omit it that would be nice too.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS8/TxAAoJEI5FoCIzSKrw1FEH/12oM8MaMSQzJSLaHwB23DnT
hFGjIBFMn8nSbIXQinnhO+XmtCpoQUrRZ0rBZ6BjYno8t7NGpV1KZsX4x/cC8ZQD
kJj2jgxu8A8ETagPw1oPfIklZbq3FNQhTE+IczrQWlAr8elr1DB+m0pf/GVpN6b+
PiGvE+PUBnElOnEMic3uDQqvXZWSd+bDEcM99Gs2X9zH2nK1eGblhJav4uP5B3cY
kJqTROeB/hb2Yiiur0tEE7/TJoIYlNJbo7Va3LmhyUCiNYk3YMqep45Jh+2jSZ77
EP1EZ7OXea3NGdEc0dgE3Hb/OumkcEowxeEJLpz8sUN1LZf+I6wcL02O7fV9eHQ=
=TF0C
-----END PGP SIGNATURE-----

Re: chrt requires priority argument

[Karel Zak]

On Thu, Feb 06, 2014 at 03:47:45PM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> chrt requires a priority argument, even for classes ( like batch )
> that do not support them.  If you specify a non zero value, then the
> command fails.  I think the argument should be ignored and forced to
> zero for these classes

 Well, why do you expect this correction in userspace? I really
 don't like when we're trying to be more smart than kernel.

 For example for setpriority() is kernel able to do the correction
 for prio argument when the argument is out of the expected range. For
 some reason sched_setscheduler() is not so smart and incorrect
 priority ends with error.

 IMHO is better to follow kernel for so low-level utils like chrt(1)
 than silently hide mistakes in usage. And the current code is also
 ready for possible future kernel changes -- implement extra
 corrections and policies in userspace means that one day you will in
 conflict with your kernel.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com