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...
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
