Date: 02 Mar 2001 00:23:05 +0100 From: Cyrille Lefevre <clefevre@poboxes.com> To: arch@FreeBSD.ORG Cc: scott_long@btc.adaptec.com Subject: Re: Arch question for a UDF FS driver Message-ID: <ae7513c6.fsf@gits.dyndns.org> In-Reply-To: John Polstra's message of "Wed, 28 Feb 2001 17:10:02 -0800 (PST)" References: <E0BFB46945D5D411BB590000D11ABE9203349F@btcexc01.btc.adaptec.com> <200103010110.f211A2843934@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra <jdp@polstra.com> writes: > Long, Scott <scott_long@btc.adaptec.com> wrote: > [...] > > Orange: Get ino_t bumped up to a uint64_t and modify all the other > > filesystems to deal with it accordingly. Advantage: no hackery needed for > > UDF. Disadvantage: may be the mother of all bikesheds. > > Unfortunately, values of type ino_t are passed from kernel to userland > via the stat(2) family of system calls. So if you change the size > of ino_t, it will change the shape of the stat structure. This > would introduce binary compatibility problems. There would have > to be yet another flavor of struct stat (we already have 3 of them > in <sys/stat.h>), and some new system calls for the new versions > of stat(), fstat(), and lstat(). I.e., you can't just change the > existing system calls without totally breaking old binaries. how about implementing transition xxx64() syscalls like solaris do ? http://www.freebsd.org/cgi/man.cgi?query=lfcompile64&sektion=5&apropos=0&manpath=SunOS+5.8 http://www.freebsd.org/cgi/man.cgi?query=lf64&sektion=5&apropos=0&manpath=SunOS+5.8 Cyrille. -- home: mailto:clefevre@poboxes.com UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ae7513c6.fsf>