Date: Mon, 13 Jun 2005 22:03:43 +0100 From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> To: Scott Long <scottl@samsco.org> Cc: Daniel Eischen <deischen@freebsd.org>, Julian Elischer <julian@elischer.org>, Apache Xie <apachexm@hotmail.com>, freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() Message-ID: <20050613210343.GL29811@parcelfarce.linux.theplanet.co.uk> In-Reply-To: <42ADD6AC.3060505@samsco.org> References: <Pine.GSO.4.43.0506131332380.23852-100000@sea.ntplx.net> <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote: > >Lot's of driver use file->private to get at per-device data easily, > >but that's just a shortcut. > > Ok, I thought that you were talking about per-process data being in the > file descriptor. Can't be done. FWIW, the main difference between FreeBSD and Linux in that area is that *all* files are vnode-based - we simply have pseudo-filesystems for pipes and sockets. So we have a single method (->release()) instead of multi-level scheme FreeBSD uses and unlike ->d_close() it does see struct file * (what with being a counterpart of ->fo_close()). While we are at it, is there any reason for passing struct thread * to ->fo_close() and then to vop_close()? <greps> 1) out of ->fo_close() instances only svr4_soo_close(), kqueue_close() and vn_closefile() look at the struct thread * in question. svr4_soo_close() panics if td is NULL (i.e. pass such descriptor in SCM_RIGHTS, make sure that it's garbage-collected by unp_gc() and watch closef(fp, NULL) panic the box). 2) vn_closefile() ends up passing it to VOP_CLOSE(). vop_close instances mostly ignore it or pass to other such instances. However, some do not - e.g. coda_close() panics if it gets NULL ap->a_td due to error = venus_close(vtomi(vp), &cp->c_fid, flag, cred, td->td_proc); AFAICS, the only reason for passing that pointer is kludge with controlling tty handling in spec_close() (or devfs_close() in -HEAD). And it doesn't look right, even ignoring the ugliness...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050613210343.GL29811>