Date: Sat, 11 Jan 2003 21:08:11 -0800 From: Alfred Perlstein <bright@mu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jake Burkholder <jake@locore.ca>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_acl.c kern_descrip.c kern_event.c kern_mac.c sys_pipe.c sys_socket.c uipc_socket.c uipc_syscalls.c uipc_usrreq.c vfs_aio.c vfs_syscalls.c vfs_vnops.c src/sys/netgraph ng_socket.c src/sys/sys file.h src/sys/ufs/ffs ... Message-ID: <20030112050811.GB33821@elvis.mu.org> In-Reply-To: <200301120459.h0C4xV5a052068@apollo.backplane.com> References: <200301120137.h0C1bD0E098037@repoman.freebsd.org> <20030111213259.E212@locore.ca> <200301120254.h0C2srcS043241@apollo.backplane.com> <20030112040835.GA33821@elvis.mu.org> <200301120459.h0C4xV5a052068@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [030111 20:59] wrote: > > : > :* Matthew Dillon <dillon@apollo.backplane.com> [030111 18:55] wrote: > :> > :> It's a cleanup. Ugliness I noticed as I was evaluating how easy it > :> would be to add a memory object file type. I don't see why you believe > :> a justification is required other then cleanup and code readability. > :> void *'s are things you only use when you need to. We certainly didn't > :> need to here. How exactly is this commit so bad that you are against it? > : > :What about third party/loadable DTYPEs? Isn't this more annoying > :than helpful for that case? You've also broken the style of this > :file by removing the f_ prefix. Please fix. > > Well, I went through various header files looking at unions. It's a > toss-up. I modeled the union after the one I vm_object.h, though it > seems to go both ways. I guess using the same field nomenclature is > more predominant but I generally prefer a name that makes it obvious > the field is a union. > > I have no problem changing the name but we can't call the > union f_data (we need to leave f_data open to catch source code > incompatibilities and to possibly use as a kernelland #define for > compatibility). We would have to think up of another name. Not really, if you keep it as f_data then people will not be able to compile code as they will get an error, that is unless they take the address of it, but that behavior is ok. using fd_ or fdata_ or filedata_ for the union members would be acceptable afaik. > I don't think third party/loadable DTYPEs are any more or less of > an issue with or without this change (do you even know of any?). > After all, sys/file.h is *ALREADY* not opaque... the DTYPE_ defines > are in sys/file.h and they are certainly type-specific, and most of > the rest of the kernel makes type-specific assumptions based on > the dtype. In other words, the struct file API is layer independant > but the use of the struct file in the kernel is not. They can make assumptions about the DTYPE being a certain value or one of several values, but they must provide a clean EINVAL return error path if it's not of an expected dtype. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030112050811.GB33821>