Date: Sat, 9 Mar 2002 19:03:08 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101533b8b0508ebb56@[128.113.24.47]> In-Reply-To: <27966.1015713342@critter.freebsd.dk> References: <27966.1015713342@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:35 PM +0100 3/9/02, Poul-Henning Kamp wrote: >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. Yes. The field in the 'struct stat' returned from stat(). Userland, posix, etc. The struct is supposed to include fields named st_dev and st_ino, of type dev_t and ino_t. >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. I don't see how this would work for OpenAFS. By that I mean that I do not know how the dev_t-pointer that you're talking about is used when implementing something like OpenAFS or ARLA support. I'm afraid I'm only familiar with userland programming, and your answer is from the kernel point of view... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu 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?p05101533b8b0508ebb56>