| To: | Ralf Baechle <ralf@linux-mips.org> |
|---|---|
| Subject: | Re: RM7k cache_flush_sigtramp |
| From: | Dominic Sweetman <dom@mips.com> |
| Date: | Mon, 4 Aug 2003 09:45:33 +0100 |
| Cc: | Dominic Sweetman <dom@mips.com>, Adam Kiepul <Adam_Kiepul@pmc-sierra.com>, Fuxin Zhang <fxzhang@ict.ac.cn>, linux-mips@linux-mips.org |
| In-reply-to: | <20030801092649.GA17624@linux-mips.org> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <9DFF23E1E33391449FDC324526D1F259017DF087@SJC1EXM02> <16170.7179.635988.268987@doms-laptop.algor.co.uk> <20030801092649.GA17624@linux-mips.org> |
| Sender: | linux-mips-bounce@linux-mips.org |
Ralf, > Linux supports the traditional MIPS UNIX cacheflush(2) syscall through > a libc interface. Since I've not seen any other use for the call than > I/D-cache synchronization. I'd just make cacheflush(3) use SYNCI where > available... SYNCI just does what's required to execute code you just wrote: that's a D-cache writeback and an I-cache invalidate. It doesn't invalidate the D-cache afterwards, which is required by the definition of cacheflush(3). I think it would be better to provide cache manipulation calls defined top-down (by their purpose); but so long as we are stuck with calls which are defined as performing particular low-level actions, it's surely dangerous to guess that we know what they are used for so we can trim the functions accordingly... -- Dominic Sweetman MIPS Technologies |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RM7k cache_flush_sigtramp, Fuxin Zhang |
|---|---|
| Next by Date: | Re: RM7k cache_flush_sigtramp, Maciej W. Rozycki |
| Previous by Thread: | Re: RM7k cache_flush_sigtramp, Ralf Baechle |
| Next by Thread: | Re: RM7k cache_flush_sigtramp, Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |