David Howells writes:
> Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
> I think we have a misunderstanding here... I meant that using the VFS
> structures for Win32 objects like mutexes, semaphores and events is
> massive overkill, and uses a great deal of unnecessary memory.
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
Alternately, 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
$ ls -log /mutex
total 0
mrw--w---- 1 acahalan 0 Sep 21 09:33 720429
mrw--w---- 1 acahalan 0 Sep 18 19:33 2852
mrw------- 1 acahalan 0 Sep 21 09:33 53245325
mrw--w---- 1 acahalan 0 Sep 21 09:33 88234
$ ls -log /event
total 0
erw------- 1 acahalan 0 Sep 21 09:33 592
>>> (3) Linux file structures do not hold enough information to support
>>> CreateFile (access & sharing interactions).
>>
>> 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)
> What I meant on the CreateFile() front is that this function takes
> an access bitmask and a share bitmask which interact with other
> CreateFile()'s and some other functions. For instance, if two
> separate CreateFile()'s are issued on a file then the second is
> rejected if it's share mask excludes the first's access mask or
> if the first's share mask excludes the second's access mask.
Yep, share bits definitely belong in the kernel. How else could
you properly protect against regular (clueless) Linux software?
>> However, Unix has quite a lot of mechanisms for interprocess
>> comunication: signals, shared memory, SYSV IPC semaphores and messages,
>> sockets, pipes. A lot of kernel structers and code is just to make
>> this work efficiently and relaiably. Putting in the kernel subsystem
>> which to large degree has the same functionality (but with incompatible
>> interface) seems like a recipe for disaster (small is the project
>> dies, big is it makes its way to the kernel).
We already have 3 ways to do file locking, so this is only 33% more.
> Why should it be a disaster? It can just be kept as a module
> that is loaded to accelerate Wine.
Now THAT would be a disaster. Linux software ought to be able to rely
on having these features available. Modules are very bad for this.
Look, we don't have flock() in a module.
>> However, I would rather belive that they already exists. As long
>> as I understand the main problem is Wine I/O performance. The other
>> problem is to have efficient mutexes. I expect SYSV stuff to be
>> reasonably efficient, and very fast mutexes may be implemented
>> (almost) in user space using ix86 assembly. With shared memory and
>> fast mutexes it should be possible to move I/O to client side even
>> in multithreading programs.
>
> That entails all sorts of other problems... On Win32, a lot of
> these objects are named... That means you have to have some sort
> of atomic-access name table in shared memory.
Named? That means you use the VFS.
>> I understand that Wine has good reasons to use W32 interfaces internally,
>> but pushing them to Linux kernel seems bad for me.
>
> 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.
The sendfile() call is mandatory.
The real-time schedular and signals are mandatory.
The clone() call is mandatory.
The prctl() call is mandatory.
See a pattern here? System calls are not supposed to be modular.
We shouldn't have calls that appear and disappear on a whim.
Binary compatibility requires that system calls be available on
all Linux systems.
-
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:24 EST