Date: Sat, 09 Mar 2002 23:35:42 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Garance A Drosihn <drosih@rpi.edu> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <27966.1015713342@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 09 Mar 2002 17:24:26 EST." <p05101532b8b03545561a@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <p05101532b8b03545561a@[128.113.24.47]>, Garance A Drosihn writes: >Should we increase the size of dev_t and ino_t? Right now, both >of them are unsigned 32-bit values. I shall claim that both of >those are too small, or at least they WILL be too small by the >time 6.0 rolls out. By dev_t I guess you mean the userland version of it (udev_t): the combined major and minor number. With DEVFS and properly written drivers, this field can be randomly assigned and will have no practical importance to the kernel. This is the direction we should move. The only argument I know for expanding it would be to make the slight hack used to hide the dictomy between the dev_t (a pointer) and the userland (u)dev_t (an integer) simpler on 64bit archs. The real solution would be to fix the software which makes bogus assumptions when reading kernel memory. >At the summit, it was stated that UFS2 should (hopefully) be >available for 5.0-release, and that it will be a 64-bit filesystem. UFS2 will have 64 bit inode numbers and will consequently very much like to have ino_t be 64bit. Traditionally (ie: "lex off_t") this means defining the relevant number of new syscalls (stat & fstat I think) so that we can still execute older programs. Summary: ino_t should be 64bit. dev_t should be uintptr_t or dev_t be renamed in the kernel. When is not really important since it will not be a backwards flag day, only a forwards flag day. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?27966.1015713342>