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]
Date:	Mon, 31 Jul 2006 11:40:25 -0400
From:	Theodore Tso <tytso@....edu>
To:	Bill Huey <billh@...ppy.monkey.org>
Cc:	Nicholas Miell <nmiell@...cast.net>, Edgar Toernig <froese@....de>,
	Neil Horman <nhorman@...driver.com>,
	Jim Gettys <jg@...top.org>, "H. Peter Anvin" <hpa@...or.com>,
	Dave Airlie <airlied@...il.com>,
	Segher Boessenkool <segher@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, a.zummo@...ertech.it,
	jg@...edesktop.org, Keith Packard <keithp@...thp.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: itimer again (Re: [PATCH] RTC: Add mmap method to rtc character driver)

On Sun, Jul 30, 2006 at 03:20:52PM -0700, Bill Huey wrote:
> > sched_policy).  At least, that's the theory.  The exact semantics of
> > what would actually be useful to application is I believe a little
> > unclear, and of course there is the question of whether there is
> 
> It's really up to the RT application to decide what it really wants. The
> role of the kernel is to give it what it has requested within reason.

Yes, but what is somewhat unclear is what knobs/parameters should be
made available to the application so it can clearly express what it
wants (i.e., can the thread be woken up early?  late?  How much leeway
should be allowed in terms of early/late triggering of the thread?
How does the scheduling of these cyclic threads interact with
non-cyclic SCHED_FIFO/SCHED_RR threads at other priorities?  etc.)  As
you say, this has been a somewhat researchy subject, and everyone has
different control knobs....

> > In any case, I don't think this is particularly interesting to the X
> > folks, although there may very well be real-time applications that
> > would find this sort of thing useful.
> 
> Right, the original topic has shifted. It's more interesting to me now. :)

Heh.  OK, so what are your requirements for this sort of feature, and
which application writers would be able to contribute their wishlist
for frequency-based scheduling?  I will say that the RTSJ document
does define Java interfaces for FBS, so that's one possible user of
such a feature.  But, I wouldn't want RTSJ to be the only thing
driving development of such a feature.  (Also, I should mention that
it's not something we've been asked for up until now, so we haven't
paid much attention to up until now.)

							- Ted
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ