linux-kernel - Re: Stupid user with user-space questions, matrix LED driving with user space code only.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1361163968.29540.62.camel@jonspc>
Date:	Mon, 18 Feb 2013 05:06:08 +0000
From:	Jonathan Andrews <jon@...shouse.co.uk>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	anish kumar <anish198519851985@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Stupid user with user-space questions, matrix LED driving with
 user space code only.

On Sun, 2013-02-17 at 18:05 -0800, Greg KH wrote: 
> On Sun, Feb 17, 2013 at 02:37:24PM +0000, Jonathan Andrews wrote:
> > From a user perspective it seems a bit crap to have to change the kernel
> > if you have a workload that preemption is harmful to.  
> > In the case of something like the Raspberry Pi changing the kernel if
> > the distribution has not done the work for me sounds like real effort.
> > The kernel is tied to binary obscurity from broadcom... To build I need
> > a working cross compiler, toolchain, kernel sources, Pi specific patches
> > then to get everything in the correct place on an SD card containing two
> > filesystems.  Its possible but its not going to "just work" at my skill
> > level....
> 
> As you can not boot a kernel.org kernel on the RPI platform just yet,
> there's very little that the kernel.org community can do here to help
> you out.
Somebody could stick in the code to enable/disable preemption at runtime
on PREEMPT compiled kernels :-) - Then all I have to do is wait for it
to filter down to the Raspian kernel maintainers, i'm patient ;-) ?   

In all seriousness I assume preemption has a timer and an interrupt
vector, cant the timer simply be enabled/disabled leaving just the
kernel call mechanism untouched. IE a "preemption" kernel that is now
not preempting ...... OK, OK - I have many other egg sucking suggestions
but am I the only one who wants the functionality ?

Seems a half step to add all this wizzy real-time code to the kernel
then stop users doing real-time in user space by allowing the schedular
to yield during what a user wishes to be a citical section (from a
timing point of view not the atomic point of view).

What about a yield alignment mechanism for user space. IE the process
calls the kernel with a request "schedule me first after a yeild" - then
the process at least has whatever the timer granularity is to do
something timing critical... add a flag to ignore or defer interrupts
and you have a semi 'hard-realtime' behaviour for user space, allowing
user space to grab small chunks of real time. Yes a nasty looking
facility for SMP intel servers but really useful for embedded.

>   I suggest you go take this up with the developers whom you got
> this specific kernel build from, there's nothing we can do here about
> it.
I suspected it was not going to be simple. As I suspect my feature
request is not that simple but if you don't ask........

Thanks,
Jon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/