Re: [linux-sh:03190] Re: cache info

Paul Mundt <[email protected]> Sat, 20 Mar 2004 09:48:10 -0500
Newsgroups gmane.linux.ports.sh.devel,gmane.linux.ports.sh.general
Message-ID <[email protected]>
On Sat, Mar 20, 2004 at 04:12:22PM +0900, Kaz Kojima wrote:
> Indeed, vsyscall is interesting.  But it seems not appropriate
> that implementing vsyscall for the query function for cache info.
> This function will never be called often and there is no problem
> even if it is slow.

Ah, ok. In that case, going with a syscall probably wouldn't be too
terrible. Other platforms (ie, s390, etc.) already have their own
set of specific syscalls, so this isn't a huge issue as long as the
number is reserved and no one else uses it. (Though I'm not sure if
Marcelo will take additional syscalls in 2.4 at this point or not).

How important is the information that glibc needs early on in the
init process? Is it possible to use a generic definition that works
for the worst case and then re-evaluate that once procfs is up?

If all you need the data for is flushing, 2.4 already has a
sys_cacheflush on sh (it uses the sys_modify_ldt number, since no
one other than x86 uses it). I haven't added this to 2.6 as of yet
though, and it really should be under its own number. In this event,
sys_cacheflush() will already do the right thing, depending on what
op you hand it (see arch/sh/kernel/sys_sh.c in linux-2_4-branch).

> Of course, I encourage someone to implement vsyscall in 2.6 :-)
> It would be nice in general.  Thanks for your comment.
> 
I'll probably have a go at this later, it does look interesting.
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAXFmq1K+teJFxZ9wRAoVIAJ9kdjeUAeWRjpzyQdSJ7MouF64/cACfTq2G
j6Tr2CGAEEwJMmYE1woYTIU=
=8Qp0
-----END PGP SIGNATURE-----