On Friday, July 08, 2011 10:05:35 Peter Mazinger wrote: > > On 07/07/11 20:41, Peter Mazinger wrote: > > >> 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...
we resort to adding this layer of indirection between the kernel and C library users only when we dont have a choice. shuffling bytes around from one struct layout to the other is wasteful overhead ... i wouldnt take xstatconv as a golden standard to be replicated. also, Bernd is modifying a struct that has already been shipped to C library users. we can change very few things now without breaking the ABI. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
