Date: Thu, 03 Apr 1997 17:27:00 -0800 From: David Greenman <dg@root.com> To: Terry Lambert <terry@lambert.org> Cc: current@FreeBSD.ORG Subject: Re: DISCUSS: system open file table Message-ID: <199704040127.RAA06069@root.com> In-Reply-To: Your message of "Thu, 03 Apr 1997 17:47:04 MST." <199704040047.RAA17931@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >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. >> >> It's already trivially easy to do file I/O in the kernel without a file >> descriptor. As you know, a "file descriptor" in FreeBSD is only a mechanism >> to translate a per-process file handle to a kernel vnode. For this reason, >> the very notion of a "file descriptor" is only relevant in the context of >> a process. It sounds like #4 is the main thing you're after, but I fail to >> see how this is relevant unless you have a process context in which to do >> the I/O, and in that case you already have easy access to the process' >> credentials. > >But... currently, a vnode reference is not the same thing as an open >reference. Actually, for all practical purposes, it is. Ideally, everything in the kernel would do a "VOP_OPEN" (actually, vn_open) for internal file I/O (such as coredumps)...and I think we actually do now. There was a time in the past where this wasn't the case, however. >Also, for things like a CIFS/SMBFS/AppleTalk/NetWare client, I want >to be able to use credentials which are not BSD process credentials, >but user credentials. I don't think this makes any sense. Process credentials are an instance of user credentials in the kernel. >I want to make the distinction between a cached reference and a real >reference, as well, both for the file I/O in a kernel thread, and >to get around some of the recent problems that come from VOP_LOCK >handling two types of locks. Hmmm. I agree with one thing: the current kludge of having vnodes with a "0" reference count + vnode generation count in the cache seems very wrong to me. It's done this way because of the handsprings one must do for NFS (and presumably any other "stateless" filesystem, which can't hold an "open" instance)... >Finally, there is the issue of taking faults in kernel mode without >a process context to sleep on. I'd like to see the sleeping moved to >the address of the field in the system open file table,so that the >sleep handle doesn't have to know what kind of caller is making the >call. Hmmm. Yes, I can see how this would be useful, but on the other hand, you have to have some saved state (whether that is a kernel thread or a process context), and any notion of kernel threads in FreeBSD (which I think is highly unlikely to ever occur) is going to have to deal with sleeping anyway...so I don't see a problem here. (Note: don't confuse this statement with kernel support for user threads, which IS very likely to occur in FreeBSD's near future). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704040127.RAA06069>