On Friday 12 April 2013 00:45:12 James Bottomley wrote: > On Thu, 2013-04-11 at 23:38 -0400, Mike Frysinger wrote: > > On Thursday 11 April 2013 22:34:43 John David Anglin wrote: > > > On 11-Apr-13, at 9:55 PM, Mike Frysinger wrote: > > > > On Sunday 07 April 2013 14:48:42 John David Anglin wrote: > > > >> On 7-Apr-13, at 2:39 PM, Mike Frysinger wrote: > > > >>> just to be clear, the only insn you need is: > > > >>> ble 0x100(%sr2, %r0); > > > >>> > > > >>> the kernel docs say sr2 holds the kernel gateway page (so i guess > > > >>> 0x100 is a > > > >>> known offset into that). the docs don't mention r0 that i can see, > > > >>> so i'm > > > >>> guessing it's one of those "always 0" registers ? > > > >> > > > >> Yes. There is also an entry at offset 0xb0 for light-weight- > > > >> syscalls. Currently, > > > >> this implements an atomic CAS operation used for pthread support. > > > > > > > > interesting. sounds like a poor man's vDSO. i'll document this the > > > > new > > > > vdso(7) man page. > > > > > > Not exactly, the code runs on the gateway page which is in kernel > > > space. The main reason for doing the operation in kernel space is to > > > prevent processes from being preempted while executing in the lock > > > region. In general, > > > parisc processes are not preempted on the gateway page. There are > > > some subtleties regarding fault handling. > > > > sure ... the Blackfin arch does a similar thing for providing fast atomic > > primitives to userspace since the ISA can't. > > > > what do you think of this section for vdso(7) ? i might have to split > > the "real" vdso arches from these others since there's a couple now > > (arm, bfin, parisc), and i think there might be more down the line > > (microblaze). > > I've got to say, I really don't think this can be classified as a vdso. > For a vdso, the kernel exports an ELF object that can be linked > dynamically into any elf binary requiring it. The ELF section > information provides full details and so vdso entries can be called by > symbol. strictly speaking, sure, a vDSO is only a vDSO if it's an ELF (since the acronym is literally "virtual dynamic shared object"). however, i see the vdso as being a bit more of a flexible concept -- it's a place of shared code that the kernel manages and exports for all userspace processes. fundamentally, the point of the vDSO is to provide services to greatly speed up userspace. in that regard, these mapped pages are exactly like vDSOs. thus i think it's appropriate to document these "fixed code" regions that many arches export (ARM, Blackfin, Itanium, Microblaze, PA-RISC) in the same man page as the vdso. especially since (currently) arches do one or the other, but not both. > In the parisc gateway page implementation, we have a set of "hidden" > primitives which the executable must know how to call (no self > description like a vdso). This mechanism is identical to the original > intent of the x86 int <n> instruction (an instruction that traps into > the kernel and performs some primitive action but to use it, you have to > know which function corresponds to which value of <n>). would it be useful to document all of them ? or just the ones that userspace actively uses (like syscall/cas) ? or should all of this be recorded in the kernel's Documentation/parisc/ subdir and just have the man page refer people there (like it does for ARM & Blackfin currently) ? -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
