> On 07/07/11 20:41, Peter Mazinger wrote: > > Hi, > >> This fixes a problem identified by Mark Salter on C6X big-endian > >> systems. We should not use "unsigned short int mode"; the proper > >> type is in theory mode_t, but here we need to use kernel_mode_t > >> since this structure is used for communication with the kernel, and > >> some targets have a 16-bit kernel_mode_t and 32-bit mode_t. > > > > haven't looked closely, but if this header gets installed on target, > > [__]kernel_mode_t is not/should not be defined. If the structure is > > not meant to be used on target, than it should be guarded (like > > _LIBC), else we should use mode_t here and handle accordingly in > > code. > > Accordingly meaning...? Should we translate kernel structures to user > structures here? That would get really ugly.
It is, we do that in some places already like xstatconv.c, where we provide a common stat structure. The sigaction implementation had also similar problems, at least 3 types of arch-specific structures are present, the members are not even the same (or in same order), vda intended to make changes, but sincerely I did not follow up how far the changes went. > Can't we ensure that the necessary type is defined somewhere? My understanding for a libc is that we try to expose to userspace a common interface, hiding specialities of the kernel. Let's see what others think... Regards, Peter -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
