On Thu, Mar 17, 2005 at 02:44:57PM -0500, Albert Cahalan wrote:
> Does the ARM kernel provide a special page of code for
> apps to execute? If not, then ARM is irrelevant.
No. However, I was responding to your suggestion that supporting
self modifying code in the kernel is trivial.
> Doesn't ARM
On Thu, 2005-03-17 at 16:55 +, Russell King wrote:
> On Tue, Mar 15, 2005 at 10:23:54AM -0500, Albert Cahalan wrote:
> > On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
> > > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > >
> > > > When the vsyscall page is created, copy the one ne
On Tue, Mar 15, 2005 at 10:23:54AM -0500, Albert Cahalan wrote:
> On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
> > On Mon, 14 Mar 2005, Albert Cahalan wrote:
> >
> > > When the vsyscall page is created, copy the one needed function
> > > into it. The kernel is already self-modifying
On 15 Mar 2005 at 10:25, john stultz wrote:
> On Mon, 2005-03-14 at 21:37 -0800, Christoph Lameter wrote:
> > Note that similarities exist between the posix clock and the time sources.
> > Will all time sources be exportable as posix clocks?
>
> At this point I'm not familiar enough with the posi
john stultz wrote:
On Mon, 2005-03-14 at 21:37 -0800, Christoph Lameter wrote:
Note that similarities exist between the posix clock and the time sources.
Will all time sources be exportable as posix clocks?
At this point I'm not familiar enough with the posix clocks interface to
say, although its
On Mon, 2005-03-14 at 21:37 -0800, Christoph Lameter wrote:
> Note that similarities exist between the posix clock and the time sources.
> Will all time sources be exportable as posix clocks?
At this point I'm not familiar enough with the posix clocks interface to
say, although its probably outsid
Albert Cahalan wrote:
I know it works for PowerPC. You'll need an isync instruction
of course. You may also want a sync instruction and some code
to invalidate the cache.
For PPC you'll want to flush the dcache, then invalidate the icache.
This will ensure that it works on all processors.
Chris
-
On Mon, 2005-03-14 at 19:22 -0800, Christoph Lameter wrote:
> On Mon, 14 Mar 2005, Albert Cahalan wrote:
>
> > When the vsyscall page is created, copy the one needed function
> > into it. The kernel is already self-modifying in many places; this
> > is nothing new.
>
> AFAIK this will only works
On Fri, 11 Mar 2005, john stultz wrote:
> +/* cyc2ns():
> + * Uses the timesource and ntp ajdustment interval to
> + * convert cycle_ts to nanoseconds.
> + * If rem is not null, it stores the remainder of the
> + * calculation there.
> + *
> + */
This funct
Note that similarities exist between the posix clock and the time sources.
Will all time sources be exportable as posix clocks?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/ma
On Mon, 14 Mar 2005, Albert Cahalan wrote:
> When the vsyscall page is created, copy the one needed function
> into it. The kernel is already self-modifying in many places; this
> is nothing new.
AFAIK this will only works on ia32 and x86_64 and not definitely not
on ia64. Who knows about the oth
On Mon, 2005-03-14 at 12:27 -0800, Matt Mackall wrote:
> On Mon, Mar 14, 2005 at 12:04:07PM -0800, john stultz wrote:
> > > > > > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > > > > > > +{
> > > > > > > > + switch (ts->type) {
> > > > > > > > + case TIMESOURC
On Mon, 14 Mar 2005, Matt Mackall wrote:
> We can either stick all the generic mmio timer functions in the
> vsyscall page (they're tiny) or leave the vsyscall using type/ptr but
> have the kernel internally use only the function pointer. Someone
> who's more familiar with the vsyscall timer code s
On Mon, 2005-03-14 at 16:28 -0800, Christoph Lameter wrote:
> On Mon, 14 Mar 2005, john stultz wrote:
>
> > Huh. So if I understand you properly, all timesources should have valid
> > read_fnct pointers that return the cycle value, however we'll still
> > preserve the type and mmio_ptr so fsyscall
On Mon, 14 Mar 2005, john stultz wrote:
> Huh. So if I understand you properly, all timesources should have valid
> read_fnct pointers that return the cycle value, however we'll still
> preserve the type and mmio_ptr so fsyscall/vsyscall bits can use them
> externally?
>
> Hmm. I'm a little cautio
On Fri, 11 Mar 2005, john stultz wrote:
> +/* get_lowres_timestamp():
> + * Returns a low res timestamp.
> + * (ie: the value of system_time as calculated at
> + * the last invocation of timeofday_periodic_hook() )
> + */
> +nsec_t get_lowres_timestamp(void)
> +{
> + nsec_t ret;
> +
john stultz wrote:
On Sat, 2005-03-12 at 16:49 -0800, Matt Mackall wrote:
~
+ /* finally, update legacy time values */
+ write_seqlock_irqsave(&xtime_lock, x_flags);
+ xtime = ns2timespec(system_time + wall_time_offset);
+ wall_to_monotonic = ns2timespec(wall_time_offset);
On Mon, Mar 14, 2005 at 12:04:07PM -0800, john stultz wrote:
> > > > > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > > > > > +{
> > > > > > > + switch (ts->type) {
> > > > > > > + case TIMESOURCE_MMIO_32:
> > > > > > > + return (cycle_t)readl(ts->mmio_ptr);
> > >
On Mon, 2005-03-14 at 11:51 -0800, Matt Mackall wrote:
> On Mon, Mar 14, 2005 at 11:43:21AM -0800, john stultz wrote:
> > On Mon, 2005-03-14 at 11:29 -0800, Matt Mackall wrote:
> > > On Mon, Mar 14, 2005 at 10:42:45AM -0800, john stultz wrote:
> > > >
> > > > > > +static inline cycle_t read_timeso
On Mon, Mar 14, 2005 at 11:43:21AM -0800, john stultz wrote:
> On Mon, 2005-03-14 at 11:29 -0800, Matt Mackall wrote:
> > On Mon, Mar 14, 2005 at 10:42:45AM -0800, john stultz wrote:
> > >
> > > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > > > +{
> > > > > + switch
On Mon, 2005-03-14 at 11:29 -0800, Matt Mackall wrote:
> On Mon, Mar 14, 2005 at 10:42:45AM -0800, john stultz wrote:
> >
> > > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > > +{
> > > > + switch (ts->type) {
> > > > + case TIMESOURCE_MMIO_32:
> > > > +
On Mon, Mar 14, 2005 at 10:42:45AM -0800, john stultz wrote:
>
> > > +static inline cycle_t read_timesource(struct timesource_t* ts)
> > > +{
> > > + switch (ts->type) {
> > > + case TIMESOURCE_MMIO_32:
> > > + return (cycle_t)readl(ts->mmio_ptr);
> > > + case TIMESOURCE_MMIO_64:
> > > +
On Sat, 2005-03-12 at 16:49 -0800, Matt Mackall wrote:
> On Fri, Mar 11, 2005 at 05:24:15PM -0800, john stultz wrote:
> > +struct timesource_t timesource_jiffies = {
> > + .name = "jiffies",
> > + .priority = 0, /* lowest priority*/
> > + .type = TIMESOURCE_FUNCTION,
> > + .read_fnct = jiff
Matt Mackall <[EMAIL PROTECTED]> writes:
> On Fri, Mar 11, 2005 at 05:24:15PM -0800, john stultz wrote:
>> +struct timesource_t timesource_jiffies = {
>> +.name = "jiffies",
>> +.priority = 0, /* lowest priority*/
>> +.type = TIMESOURCE_FUNCTION,
>> +.read_fnct = jiffies_read,
>> +
On Fri, Mar 11, 2005 at 05:24:15PM -0800, john stultz wrote:
> +struct timesource_t timesource_jiffies = {
> + .name = "jiffies",
> + .priority = 0, /* lowest priority*/
> + .type = TIMESOURCE_FUNCTION,
> + .read_fnct = jiffies_read,
> + .mask = (cycle_t)~0,
Not sure this is ri
All,
This patch implements the architecture independent portion of the time
of day subsystem. For a brief description on the rework, see here:
http://lwn.net/Articles/120850/ (Many thanks to the LWN team for that
clear writeup!)
The exciting new changes are ntp_scale() has been rem
26 matches
Mail list logo
