Date: Sat, 11 Jan 2003 20:59:31 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> 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: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:* 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.
:
:--
:-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
<dillon@backplane.com>
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?200301120459.h0C4xV5a052068>