Jens Thiele a écrit : > Aurelien Jarno <aurel...@aurel32.net> writes: > >> Actually it doesn't, it's just that the chroot's name I used was a bit >> smaller. > > ok > >> If we find from where this limit come, we can probably increase >> it (most probably in the kernel). > > Looking at the reported limits: > > cat test.c && make -k test && ./test > #include <stdio.h> > #include <limits.h> > #include <unistd.h> > #include <dirent.h> > > #define x(x) do{printf("%s=%d\n",#x,x);}while(0) > #define p(x) do{printf("%s=%d\n",#x,pathconf("/",x));}while(0) > > int main() > { > x(PATH_MAX); > x(_POSIX_PATH_MAX); > x(NAME_MAX); > x(MAXNAMLEN); > x(FILENAME_MAX); > x(_POSIX_NAME_MAX); > p(_PC_NAME_MAX); > p(_PC_PATH_MAX); > return 0; > } > make: »test« ist bereits aktualisiert. > PATH_MAX=1024 > _POSIX_PATH_MAX=256 > NAME_MAX=255 > MAXNAMLEN=255 > FILENAME_MAX=1024 > _POSIX_NAME_MAX=14 > _PC_NAME_MAX=255 > _PC_PATH_MAX=1024 > > So depending on the interpretation of those values (i only did a quick > look) this is a kernel or libc bug right? > > I guess it is a kernel bug. A quick look at the source did not reveal > something obvious in the nullfs code. A really wild guess in a > completely different corner (i am really a noob regarding (k)freebsd): >
The problem actually from here sys/sys/mount.h, and is not specific to procfs: | #define MNAMELEN 88 /* size of on/from name bufs */ ... | #define OMNAMELEN (88 - 2 * sizeof(long)) /* size of on/from name bufs */ The variable length depending on the architecture is there to keep the size of the structure statfs to 256 bytes. The problem in changing those values is that it will break the ABI of at least the statfs syscall. It's not impossible to change, but we have to take extreme care about that. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org