| Message ID | ff9dd4accdc897013594768833d54444e4823bf9.1611585031.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | powerpc/32: Implement C syscall entry/exit | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/merge (41d8cb7ece7c81e4eb897ed7ec7d3c3d72fd0af4) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/next (e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linus/master (0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/fixes (41131a5e54ae7ba5a2bb8d7b30d1818b3f5b13d2) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linux-next (0da0a8a0a0e1845f495431c3d8d733d2bbf9e9e5) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: > syscall_64.c will be reused almost as is for PPC32. > > Rename it syscall.c Could you rename it to interrupt.c instead? A system call is an interrupt, and the file now also has code to return from other interrupts as well, and it matches the new asm/interrupt.h from the interrupts series. Thanks, Nick
From: Nicholas Piggin > Sent: 26 January 2021 10:21 > > Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: > > syscall_64.c will be reused almost as is for PPC32. > > > > Rename it syscall.c > > Could you rename it to interrupt.c instead? A system call is an > interrupt, and the file now also has code to return from other > interrupts as well, and it matches the new asm/interrupt.h from > the interrupts series. Hmmm.... That might make it harder for someone looking for the system call entry code to find it. In some sense interrupts are the simpler case. Especially when comparing with other architectures which have special instructions for syscall entry. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Excerpts from David Laight's message of January 26, 2021 8:28 pm: > From: Nicholas Piggin >> Sent: 26 January 2021 10:21 >> >> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: >> > syscall_64.c will be reused almost as is for PPC32. >> > >> > Rename it syscall.c >> >> Could you rename it to interrupt.c instead? A system call is an >> interrupt, and the file now also has code to return from other >> interrupts as well, and it matches the new asm/interrupt.h from >> the interrupts series. > > Hmmm.... > > That might make it harder for someone looking for the system call > entry code to find it. It's very grep'able. > In some sense interrupts are the simpler case. > > Especially when comparing with other architectures which have > special instructions for syscall entry. powerpc does have a special instruction for syscall, and it causes a system call interrupt. I'm not sure about other architectures, but for powerpc its more sensible to call it interrupt.c than syscall.c. Thanks, Nick
Le 28/01/2021 à 00:50, Nicholas Piggin a écrit : > Excerpts from David Laight's message of January 26, 2021 8:28 pm: >> From: Nicholas Piggin >>> Sent: 26 January 2021 10:21 >>> >>> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: >>>> syscall_64.c will be reused almost as is for PPC32. >>>> >>>> Rename it syscall.c >>> >>> Could you rename it to interrupt.c instead? A system call is an >>> interrupt, and the file now also has code to return from other >>> interrupts as well, and it matches the new asm/interrupt.h from >>> the interrupts series. >> >> Hmmm.... >> >> That might make it harder for someone looking for the system call >> entry code to find it. > > It's very grep'able. > >> In some sense interrupts are the simpler case. >> >> Especially when comparing with other architectures which have >> special instructions for syscall entry. > > powerpc does have a special instruction for syscall, and it causes a > system call interrupt. > > I'm not sure about other architectures, but for powerpc its more > sensible to call it interrupt.c than syscall.c. Many other architectures have a syscall.c but for a different purpose: it contains arch specific system calls. We have that in powerpc as well, it is called syscalls.c So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An interrupt most of the time refers to IRQ. For me system call is not an interrupt in the way it doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions, no I'm more inclined to call it exception.c Christophe
Excerpts from Christophe Leroy's message of February 2, 2021 4:15 pm: > > > Le 28/01/2021 à 00:50, Nicholas Piggin a écrit : >> Excerpts from David Laight's message of January 26, 2021 8:28 pm: >>> From: Nicholas Piggin >>>> Sent: 26 January 2021 10:21 >>>> >>>> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: >>>>> syscall_64.c will be reused almost as is for PPC32. >>>>> >>>>> Rename it syscall.c >>>> >>>> Could you rename it to interrupt.c instead? A system call is an >>>> interrupt, and the file now also has code to return from other >>>> interrupts as well, and it matches the new asm/interrupt.h from >>>> the interrupts series. >>> >>> Hmmm.... >>> >>> That might make it harder for someone looking for the system call >>> entry code to find it. >> >> It's very grep'able. >> >>> In some sense interrupts are the simpler case. >>> >>> Especially when comparing with other architectures which have >>> special instructions for syscall entry. >> >> powerpc does have a special instruction for syscall, and it causes a >> system call interrupt. >> >> I'm not sure about other architectures, but for powerpc its more >> sensible to call it interrupt.c than syscall.c. > > Many other architectures have a syscall.c but for a different purpose: it contains arch specific > system calls. We have that in powerpc as well, it is called syscalls.c > > So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An > interrupt most of the time refers to IRQ. That depends what you mean by interrupt and IRQ. Linux kind of considers any asynchronous maskable interrupt an irq (local_irq_disable()). But if you say irq it's more likely to mean a device interrupt, and "interrupt" usually refres to the asynch ones. But Linux doesn't really assign names to synchronous interrupts in core code. It doesn't say they aren't interrupts, it just doesn't really have a convention for them at all. Other architectures e.g., x86 also have things like interrupt descriptor table for synchronous interrupts as well. That's where I got the interrupt wrappers code from actually. So it's really fine to use the proper arch-specific names for things in arch code. I'm trying to slowly change names from exception to interrupt. > For me system call is not an interrupt in the way it > doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions, > no I'm more inclined to call it exception.c Actually that's backwards. Powerpc manuals (at least the one I look at) calls them all interrupts including system calls, and also the system call interrupt is actually the only one that doesn't appear to be associated with an exception. Also there is no distinction about expecte/unexpected -- a data storage interrupt is expected if you access a location without the right access permissions for example, but it is still an interrupt. These handlers very specifically deal with the change to execution flow (i.e., the interrupt), they do *not* deal with the exception which may be associated with it (that is the job of the handler). And on the other hand you can deal with exceptions in some cases without taking an interrupt at all. For example if you had MSR[EE]=0 you could change the decrementer or execute msgclr or change HMER SPR etc to clear various exceptions without ever taking the interrupt. Thanks, Nick
Le 02/02/2021 à 07:38, Nicholas Piggin a écrit : > Excerpts from Christophe Leroy's message of February 2, 2021 4:15 pm: >> >> >> Le 28/01/2021 à 00:50, Nicholas Piggin a écrit : >>> Excerpts from David Laight's message of January 26, 2021 8:28 pm: >>>> From: Nicholas Piggin >>>>> Sent: 26 January 2021 10:21 >>>>> >>>>> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: >>>>>> syscall_64.c will be reused almost as is for PPC32. >>>>>> >>>>>> Rename it syscall.c >>>>> >>>>> Could you rename it to interrupt.c instead? A system call is an >>>>> interrupt, and the file now also has code to return from other >>>>> interrupts as well, and it matches the new asm/interrupt.h from >>>>> the interrupts series. >>>> >>>> Hmmm.... >>>> >>>> That might make it harder for someone looking for the system call >>>> entry code to find it. >>> >>> It's very grep'able. >>> >>>> In some sense interrupts are the simpler case. >>>> >>>> Especially when comparing with other architectures which have >>>> special instructions for syscall entry. >>> >>> powerpc does have a special instruction for syscall, and it causes a >>> system call interrupt. >>> >>> I'm not sure about other architectures, but for powerpc its more >>> sensible to call it interrupt.c than syscall.c. >> >> Many other architectures have a syscall.c but for a different purpose: it contains arch specific >> system calls. We have that in powerpc as well, it is called syscalls.c >> >> So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An >> interrupt most of the time refers to IRQ. > > That depends what you mean by interrupt and IRQ. > > Linux kind of considers any asynchronous maskable interrupt an irq > (local_irq_disable()). But if you say irq it's more likely to mean > a device interrupt, and "interrupt" usually refres to the asynch > ones. > > But Linux doesn't really assign names to synchronous interrupts in > core code. It doesn't say they aren't interrupts, it just doesn't > really have a convention for them at all. > > Other architectures e.g., x86 also have things like interrupt > descriptor table for synchronous interrupts as well. That's where > I got the interrupt wrappers code from actually. > > So it's really fine to use the proper arch-specific names for things > in arch code. I'm trying to slowly change names from exception to > interrupt. > >> For me system call is not an interrupt in the way it >> doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions, >> no I'm more inclined to call it exception.c > > Actually that's backwards. Powerpc manuals (at least the one I look at) > calls them all interrupts including system calls, and also the system > call interrupt is actually the only one that doesn't appear to be > associated with an exception. > > Also there is no distinction about expecte/unexpected -- a data storage > interrupt is expected if you access a location without the right access > permissions for example, but it is still an interrupt. > > These handlers very specifically deal with the change to execution flow > (i.e., the interrupt), they do *not* deal with the exception which may > be associated with it (that is the job of the handler). > > And on the other hand you can deal with exceptions in some cases without > taking an interrupt at all. For example if you had MSR[EE]=0 you could > change the decrementer or execute msgclr or change HMER SPR etc to clear > various exceptions without ever taking the interrupt. > Ok, let's call it interrupt.c then, to be consistant with the interrupt wrapper story. Christophe
On Tue, Feb 02, 2021 at 04:38:31PM +1000, Nicholas Piggin wrote: > > So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An > > interrupt most of the time refers to IRQ. > > That depends what you mean by interrupt and IRQ. In the PowerPC architecture, an exception is an abnormal condition, and that can often cause an interrupt. What Christophe colloquially calls an "IRQ" here is called an external exception c.q. external interrupt. > But if you say irq it's more likely to mean > a device interrupt, and "interrupt" usually refres to the asynch > ones. Power talks about "instruction-caused interrupts", for one aspect of the difference here; and "precise" / "imprecise" interrupts for another. > So it's really fine to use the proper arch-specific names for things > in arch code. I'm trying to slowly change names from exception to > interrupt. Thanks :-) > > For me system call is not an interrupt in the way it > > doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions, > > no I'm more inclined to call it exception.c > > Actually that's backwards. Powerpc manuals (at least the one I look at) > calls them all interrupts including system calls, and also the system > call interrupt is actually the only one that doesn't appear to be > associated with an exception. Yeah. You could easily make such an exception, which is set when you execute a system call instruction, and cleared when the interrupt is taken, of course; but the architecture doesn't. > And on the other hand you can deal with exceptions in some cases without > taking an interrupt at all. For example if you had MSR[EE]=0 you could > change the decrementer or execute msgclr or change HMER SPR etc to clear > various exceptions without ever taking the interrupt. A well-known example is the exception bits in the FPSCR, which do not cause an interrupt unless the corresponding enable bits are also set. Segher
Le 26/01/2021 à 11:21, Nicholas Piggin a écrit : > Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am: >> syscall_64.c will be reused almost as is for PPC32. >> >> Rename it syscall.c > > Could you rename it to interrupt.c instead? A system call is an > interrupt, and the file now also has code to return from other > interrupts as well, and it matches the new asm/interrupt.h from > the interrupts series. > Done in v5 Christophe
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index fe2ef598e2ea..1cbc51fc82fd 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -49,7 +49,7 @@ obj-y := cputable.o syscalls.o \ hw_breakpoint_constraints.o obj-y += ptrace/ obj-$(CONFIG_PPC64) += setup_64.o \ - paca.o nvram_64.o note.o syscall_64.o + paca.o nvram_64.o note.o syscall.o obj-$(CONFIG_COMPAT) += sys_ppc32.o signal_32.o obj-$(CONFIG_VDSO32) += vdso32/ obj-$(CONFIG_PPC_WATCHDOG) += watchdog.o diff --git a/arch/powerpc/kernel/syscall_64.c b/arch/powerpc/kernel/syscall.c similarity index 100% rename from arch/powerpc/kernel/syscall_64.c rename to arch/powerpc/kernel/syscall.c
syscall_64.c will be reused almost as is for PPC32. Rename it syscall.c Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> --- arch/powerpc/kernel/Makefile | 2 +- arch/powerpc/kernel/{syscall_64.c => syscall.c} | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename arch/powerpc/kernel/{syscall_64.c => syscall.c} (100%)