Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) ===================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) Notes on the change from 16-bit UIDs to 32-bit UIDs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) ===================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) :Author: Chris Wing <wingc@umich.edu>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) :Last updated: January 11, 2000
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) - kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9)   when communicating between user and kernel space in an ioctl or data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)   structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) - kernel code should use uid_t and gid_t in kernel-private structures and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)   code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) What's left to be done for 32-bit UIDs on all Linux architectures:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) - Disk quotas have an interesting limitation that is not related to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)   maximum UID/GID. They are limited by the maximum file size on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)   underlying filesystem, because quota records are written at offsets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)   corresponding to the UID in question.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)   Further investigation is needed to see if the quota system can cope
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)   properly with huge UIDs. If it can deal with 64-bit file offsets on all 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)   architectures, this should not be a problem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) - Decide whether or not to keep backwards compatibility with the system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)   accounting file, or if we should break it as the comments suggest
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)   (currently, the old 16-bit UID and GID are still written to disk, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)   part of the former pad space is used to store separate 32-bit UID and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)   GID)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) - Need to validate that OS emulation calls the 16-bit UID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)   compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)   uses the 32-bit UID system calls properly otherwise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)   This affects at least:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) 	- iBCS on Intel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) 	- sparc32 emulation on sparc64
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) 	  (need to support whatever new 32-bit UID system calls are added to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 	  sparc32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) - Validate that all filesystems behave properly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)   At present, 32-bit UIDs _should_ work for:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) 	- ext2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 	- ufs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) 	- isofs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) 	- nfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) 	- coda
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 	- udf
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)   Ioctl() fixups have been made for:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 	- ncpfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) 	- smbfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)   Filesystems with simple fixups to prevent 16-bit UID wraparound:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 	- minix
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) 	- sysv
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) 	- qnx4
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)   Other filesystems have not been checked yet.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) - The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)   all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)   more are needed. (as well as new user<->kernel data structures)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) - The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)   sh, and sparc32. Fixing this is probably not that important, but would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73)   require adding a new ELF section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) - The ioctl()s used to control the in-kernel NFS server only support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)   16-bit UIDs on arm, i386, m68k, sh, and sparc32.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) - make sure that the UID mapping feature of AX25 networking works properly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)   (it should be safe because it's always used a 32-bit integer to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)   communicate between user and kernel)