From owner-cvs-all Sat Jan 11 20:59:34 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3FC937B401; Sat, 11 Jan 2003 20:59:32 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CF6D43ED8; Sat, 11 Jan 2003 20:59:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0C4xWYp052069; Sat, 11 Jan 2003 20:59:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0C4xV5a052068; Sat, 11 Jan 2003 20:59:31 -0800 (PST) Date: Sat, 11 Jan 2003 20:59:31 -0800 (PST) From: Matthew Dillon Message-Id: <200301120459.h0C4xV5a052068@apollo.backplane.com> To: Alfred Perlstein Cc: Jake Burkholder , 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 ... References: <200301120137.h0C1bD0E098037@repoman.freebsd.org> <20030111213259.E212@locore.ca> <200301120254.h0C2srcS043241@apollo.backplane.com> <20030112040835.GA33821@elvis.mu.org> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :* Matthew Dillon [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. : :-- :-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.' 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. 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message