On Tue, 26 Aug 2008, Nick Piggin wrote:
On Tuesday 26 August 2008 19:30, Ingo Molnar wrote:* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:Your arguments were along the line of:So... no reply to this? I'm really wondering how it's OK to breakI disagree
documented standards and previous Linux behaviour by default for
something that it is trivial to solve in userspace? [...]
* It probably doesn't break anything (except we had somebody report
that it breaks their app)
I'm a real-time oldtimer. An application which hogs the CPU for 9.9
seconds with SCHED_FIFO priority is just broken. It's broken beyond
all limits, whether POSIX allows to do that or Linux obeyed the
request of the braindamaged application design.
From my point of view, as an RT user, any kernel that supports SMP yet can'tguarantee me %100 of even one _my_ processors is just a plainly broken kernel.
* If it does break something then they must be doing something stupid
(I refuted that because there are several legitimate ways to use rt
scheduling that is broken by this)
* We have many other APIs and tools that don't conform to posix (why
is that a reason to break this one?)
Simply because we use common sense instead of following every single
POSIX brainfart by the letter.
* We should break the API to cater for stupid users and distros who
create local DoS and/or lock up their boxes (except this is trivial
to solve by setting sysctls or having a watchdog or using sysrq)
For the vast majority of users and RT developers a sane default of
sanity measures is useful and sensible.
If someone wants to shoot himself in the foot then it's not an
unreasonable request that he needs to disable the safety guards before
pulling the trigger.