Date: Thu, 3 Apr 1997 16:28:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: current@freebsd.org Subject: DISCUSS: system open file table Message-ID: <199704032328.QAA17735@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
I'm looking for discussion, pro and con. ---------------------------------------------------------------------------- I went looking into the system open file table today. I was mildly surprised at what I found. I would like to suggest functionally seperating process descriptor management from system open file table management. The purpose of this seperation would be to provide for the possibility of entries in the system open file table which do not exist in a per process open file table anywhere. The point of this exercise is to enable the creation of a descriptor based kernel level file I/O interface. This interface would be used both by the system calls which deal with per process descriptor manipulation, and it would also be usable within the kernel itself. This would be useful for: 1) File I/O in a kernel threading environment 2) File I/O from within some types of file system stacking layers; most notably "quota" and "ACL", but it would also be useful for SEF's suggested method of providing persistance for a devfs. 3) File I/O on non-normal files (sockets for CIFS/SMB and AllpeTalk file system support, pipes for FS->user event notification such as directory modifications being signalled to file browsers, etc.). 4) Any other kernel file I/O operations which rely on stored credentials established at file open(*). (*) The descriptor f_type and f_ops field are not relevent arguments in favor of this, since they are cruft which should be diked out. The facilities would be similar in nature to those provided by the AIX kernel. ----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704032328.QAA17735>