From owner-freebsd-current Thu Apr 3 15:45:27 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA26924 for current-outgoing; Thu, 3 Apr 1997 15:45:27 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA26915 for ; Thu, 3 Apr 1997 15:45:23 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA17735 for current@freebsd.org; Thu, 3 Apr 1997 16:28:39 -0700 From: Terry Lambert Message-Id: <199704032328.QAA17735@phaeton.artisoft.com> Subject: DISCUSS: system open file table To: current@freebsd.org Date: Thu, 3 Apr 1997 16:28:39 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. ----------------------------------------------------------------------------