Re: [PATCH v4 11/23] powerpc/syscall: Rename syscall_64.c into syscall.c

[Christophe Leroy]

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