Re: [PATCH 0/8] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote:

> > I.e. I'd generate the names like this:
> > 
> >     __{x64,x32,ia32}[_compat]_sys_waittid()
> > 
> > The fully consistent nomenclature would be someting like this:
> > 
> >  ffffffff8105f1e0 t            kernel_waitid    # common C function (64-bit kargs)
> >  ffffffff8105f2b0 t               SYS_waitid    # 64-bit uaddr args C function
> >  ffffffff8105f410 T         __x64_sys_waitid    # 64-bit-ptregs -> C stub
> >  ffffffff8105f430 T        __ia32_sys_waitid    # 32-bit-ptregs -> C stub
> >  ffffffff8105f450 t        COMPAT_SYS_waitid    # 32-bit uaddr args C function
> >  ffffffff8105f5e0 T __ia32_compat_sys_waitid    # 32-bit-ptregs -> C stub
> >  ffffffff8105f600 T  __x32_compat_sys_waitid    # 64-bit-ptregs -> C stub
> > 
> > Looks a lot tidier and a lot more logical, doesn't it?
> 
> Indeed. Want me to prepare a new patch 8/8 on top which does the renaming
> (for x86 and for the generic case), or will you do the re-naming while
> merging my patches yourself?

Please do an 8/8 patch that does the rename - I'll push out the first 7 patches so 
they get more testing.

Note, I have not checked the above name space for namespace collisions - but 
unless we are unlucky it should be fine.

BTW., is there any deep reason why some of these names are capitalized?

I.e. could we use:

  ffffffff8105f1e0 t            kernel_waitid    # common C function (64-bit kargs)
  ffffffff8105f2b0 t               sys_waitid    # 64-bit uaddr args C function
  ffffffff8105f410 T         __x64_sys_waitid    # 64-bit-ptregs -> C stub
  ffffffff8105f430 T        __ia32_sys_waitid    # 32-bit-ptregs -> C stub
  ffffffff8105f450 t        compat_sys_waitid    # 32-bit uaddr args C function
  ffffffff8105f5e0 T __ia32_compat_sys_waitid    # 32-bit-ptregs -> C stub
  ffffffff8105f600 T  __x32_compat_sys_waitid    # 64-bit-ptregs -> C stub

?

Note how this reduces naming complexity and increases the self-consistency even more.

Thanks,

	Ingo