kth <kangtaeho2456@xxxxxxxxx> writes: > The highuid.rst document describes a transition that is outdated and no > longer relevant. Additionally, it references filesystems (ncpfs and smbfs), > which have been removed or replaced. > > Suggested-by: Matthew Wilcox <willy@xxxxxxxxxxxxx> > Signed-off-by: Kang Taeho <kangtaeho2456@xxxxxxxxx> > --- > Documentation/admin-guide/highuid.rst | 80 --------------------------- > Documentation/admin-guide/index.rst | 1 - > 2 files changed, 81 deletions(-) > delete mode 100644 Documentation/admin-guide/highuid.rst OK, I have applied this, but it was some work. For future reference: - When you do a v2 (or whatever), always include a description of what changed since the previous version under the "---" line. - Before sending another patch, email it to yourself and be sure that you can apply what you receive. This patch was whitespace damaged, but that is not all ... > > diff --git a/Documentation/admin-guide/highuid.rst b/Documentation/admin-guide/highuid.rst > deleted file mode 100644 > index 9239067563a1..000000000000 > --- a/Documentation/admin-guide/highuid.rst > +++ /dev/null > @@ -1,80 +0,0 @@ > -=================================================== > -Notes on the change from 16-bit UIDs to 32-bit UIDs > -=================================================== > - > -:Author: Chris Wing <wingc@xxxxxxxxx> > -:Last updated: January 11, 2000 > - > -- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t > - when communicating between user and kernel space in an ioctl or data > - structure. > - > -- kernel code should use uid_t and gid_t in kernel-private structures and > - code. > - > -What's left to be done for 32-bit UIDs on all Linux architectures: > - > -- Disk quotas have an interesting limitation that is not related to the > - maximum UID/GID. They are limited by the maximum file size on the > - underlying filesystem, because quota records are written at offsets > - corresponding to the UID in question. > - Further investigation is needed to see if the quota system can cope > - properly with huge UIDs. If it can deal with 64-bit file offsets on all > - architectures, this should not be a problem. > - > -- Decide whether or not to keep backwards compatibility with the system > - accounting file, or if we should break it as the comments suggest > - (currently, the old 16-bit UID and GID are still written to disk, and > - part of the former pad space is used to store separate 32-bit UID and > - GID) > - > -- Need to validate that OS emulation calls the 16-bit UID > - compatibility syscalls, if the OS being emulated used 16-bit UIDs, or > - uses the 32-bit UID system calls properly otherwise. > - > - This affects at least: > - > - - iBCS on Intel > - > - - sparc32 emulation on sparc64 > - (need to support whatever new 32-bit UID system calls are added to > - sparc32) > - > -- Validate that all filesystems behave properly. > - > - At present, 32-bit UIDs _should_ work for: > - > - - ext2 > - - ufs > - - isofs > - - nfs > - - coda > - - udf > - > - Ioctl() fixups have been made for: > - > - - ncpfs > - - smbfs > - > - Filesystems with simple fixups to prevent 16-bit UID wraparound: > - > - - minix > - - sysv > - - qnx4 > - > - Other filesystems have not been checked yet. > - > -- The ncpfs and smbfs filesystems cannot presently use 32-bit UIDs in This line here ^^^^^ contains your previous attempted fix; that, too, caused the patch to fail to apply. I had to hand edit it to get past that. Thanks, jon
