Re: ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 19 Dec 2018, Vineet Gupta wrote:

> I took a stab at this but not really happy with taking this approach.
> 
> (1). Common code assumes disparate kernel and userland sigaction struct even
> though there's no reason for a *new* port to be: its not like all glibc code is
> shared/common although I agree it is best to do so as much as possible
> So this requires explicit copy over of 1 struct into other, when it could have
> been avoided altogether for some cases atleast (!SA_RESTORER).

So make the generic code optimize those cases based on appropriate 
conditionals (making sure to verify those conditionals are right for every 
architecture in glibc).

Any new architecture having much architecture-specific code for the kernel 
interface in glibc, beyond the basic definitions of how to call a syscall, 
is suspect, given that the kernel structures should be consistent across 
asm-generic architectures; we ought to make the defaults work so they are 
genuinely suitable as defaults for new architectures.  This may require 
changes to the sysdeps/unix/sysv/linux/ code if it's currently "generic" 
to old architectures but not so good for asm-generic ones.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-snps-arc



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux