Date: Tue, 7 May 2002 18:52:59 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Robert Watson <rwatson@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com> Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <p0511173cb8fe02157419@[128.113.24.47]> In-Reply-To: <Pine.NEB.3.96L.1020507093445.76283B-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1020507093445.76283B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:46 AM -0400 5/7/02, Robert Watson wrote: >On Tue, 7 May 2002, Matthew Dillon wrote: > > A bunch of things starting leaking out of the woodwork > > as I was playing around with 64 bit time_t's. At the > > very least I would pad the structures to handle things > > like 64 bit dev_t, ino_t, and file flags, and I would > > even consider padding now 96 bit structures like timespec > > to 128 bits across the board. It might also be worthwhile > > to make uid_t, gid_t, and pid_t 64 bits to support probable > > future work in those areas. > >My understanding from talking with Kirk and Poul-Henning is >that ino_t is definitely on the list already, as are a number >of the others at the file system image layer (such as block >pointers, et al). They should already have much of this >underway, and the temptation is to allow them to do the >grunt work if they're already doing it :-). Certainly we should try to talk them into doing as much of the work as we can convince them to do... :-) >dev_t I don't really have an opinion about. I would really really like to have the larger dev_t, but I expect everyone remembers my previous pleading on the topic. So, I will just add a "pretty please?" here as a reminder. I really think it's the right thing to do for OpenAFS, etc. >I guess the one opinion I haven't heard yet, and am a little >surprised not to have heard is: > > No, we shouldn't do this on architectural grounds. > >We've heard "yes" in various flavors, including moderated >"yes if we can manage it by the release". Not to invite a >bikeshed, but if there's going to be a strong argument >against such a change, it would be nice to hear it sooner. My vote is a pretty strong "yes" for at least the changes that Poul-Henning originally mentioned. I might want to change that vote if we're at mid-July and we can't seem to pull the changes together, but I think the new syscall vector is less painful than trying to do all the UFS2 work (which I *do* want in 5.0) via any other method. I would not mind if 5.0 slipped a month for that work. (not that I want it to slip, but I would not feel bad if we find out that it had to slip one month for this change). Where I start hemming and hawing is when it comes to how many other changes should be added. Basically I want "as many as we can do and still keep to the schedule". I would not want 5.0 to slip for other syscall-ish changes. -- Garance Alistair Drosehn = gad@gilead.netel.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?p0511173cb8fe02157419>