"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
> In spite of that, it should be considered. It allows this:
>
> $ ls -log /proc/self/fd
> total 0
> lrwx------ 1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4
> lrwx------ 1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4
> lrwx------ 1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4
> lrwx------ 1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429]
> lrwx------ 1 acahalan 64 Sep 21 09:12 4 -> event:[592]
> lr-x------ 1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd
Looks nice, I know, but it may mean file handles are indirect, in that you
have:
struct file->struct dentry->struct inode->struct winefile->struct file->...
if you can't store all the extra wine attributes on the struct file. It also
means that the inode or the dentry has to maintain a list of attached file's,
which I don't think it does at the moment.
> >> Any information not in kernel structure is Wine specific anyway, so
> >> should be separate
>
> It goes into the kernel structure, so that it won't be Wine-specific.
> SGI has already done this so that Samba would interact properly with
> regular UNIX software and the NFS server.
>
> (one might support SGI's API for this)
Hmmm... worth investigating. I take it that this was only done for IRIX, not
Linux.
> Yep, share bits definitely belong in the kernel. How else could
> you properly protect against regular (clueless) Linux software?
Probably do...
> We already have 3 ways to do file locking, so this is only 33% more.
66%... Don't forget LockFile/UnlockFile. These work very similarly to fcntl,
I think, but demand mandatory locking.
> Now THAT would be a disaster. Linux software ought to be able to rely
> on having these features available.
I agree, but does Linus?
> Modules are very bad for this.
Probably, but unless the code goes into the kernel proper, patch maintainance
can be a real nightmare. The greater the amount of kernel actually changed by
a patch, the worse it is.
> Named? That means you use the VFS.
Not necessarily. For file handles, you probably should (unless you want
drive-letter mappings to occur in the kernel - yuk), but the other things are
effectively in separate namespaces.
>> Don't use it then... it'll not be mandatory. Wine has also to support OS's
>> that can't or won't add Win32 support in the kernel.
You misunderstand me... _Using_ this API will not be mandatory, whether or not
it exists in the kernel proper.
> See a pattern here? System calls are not supposed to be modular.
knfsd? But I agree, really. But what is the likelyhood?
> We shouldn't have calls that appear and disappear on a whim.
True... that smacks of MS policy:-)
> Binary compatibility requires that system calls be available on
> all Linux systems.
Also true. You should be able to compile the module I currently have on all
Linux systems. Unfortunately, I can't test this at the moment.
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:25 EST