Alexander Viro <[EMAIL PROTECTED]> wrote:
> Then these apps are non-portable to other Unices and either get fixed or
> get rm'd. Period.
Definitely.
> In case you've missed that, Win32 is misdesigned crap. It's one thing
> to add binary compatibility _if_ it doesn't affect the native stuff, but
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
> Well, if this isn't worth doing right... Patch size is just something
> you have to deal with. Hopefully you can get an early-2.5.x merge.
I wouldn't like to bet on it.
> Why limit it? If the existing poll method needs extension, do it.
I suppos
On Mon, 25 Sep 2000, Albert D. Cahalan wrote:
> If you'd like to live without all /proc-using tools, much of /sbin,
> the X server, inetd, anything that uses sendfile(), and anything
> that uses RT-signals for IO events... go right ahead. You can give
> up on VFS enhancements too, since anythin
Alexander Viro writes:
> On Mon, 25 Sep 2000, Albert D. Cahalan wrote:
>> The list would be NULL most of the time. If Linux apps start
>> using this feature a lot, then it can be optimized.
>
> Then these apps are non-portable to other Unices and either get fixed or
> get rm'd. Period.
If you'd
On Mon, 25 Sep 2000, Albert D. Cahalan wrote:
> > * Win32 access/share flags would have to be retained in the file
> > struct, and the inode struct would have to maintain a list of these.
>
> OK. Problem?
>
> The list would be NULL most of the time. If Linux apps start
> using this feat
David Howells writes:
> I'm still not keen on the idea, though... One of the things I'm trying to
> avoid is having to maintain a large patch to the kernel. I've done it before
Well, if this isn't worth doing right... Patch size is just something
you have to deal with. Hopefully you can get an e
Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> Well, I was thinking in the following way: we keep wineserver almost as
> now, only put some mutexes (semaphores) inside. We duplicate parts
> of wineserver code in the clients. We divide wineserver requests into
> two sets fast (easy) ones and slow.
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
> #define HANDLE_TO_FD(x) ((x)>>2)
> #define FD_TO_HANDLE(x) ((x)<<2)
(not quite as simple as that since fd 0 is valid and handle 0 is not, but
that's a very minor issue.)
I'm still not keen on the idea, though... One of the things I'm trying to
a
David Howells writes:
> [EMAIL PROTECTED] (Albert D. Cahalan) 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 -> /de
[EMAIL PROTECTED] (Albert D. Cahalan) 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 acah
"Albert D. Cahalan" <[EMAIL PROTECTED]> 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 ac
David Howells writes:
> Waldek Hebisch <[EMAIL PROTECTED]> 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 sh
Waldek Hebisch <[EMAIL PROTECTED]> wrote:
> > (2) the struct file+struct dentry+struct inode complex is incredibly heavy
> > for most of what I want to do (though does have advantages);
> Well, all (ok most) of this complexity is to support Unix semantics.
> Adding structures with differen
> Reiserfs would make a fine registry.
Interesting idea... Have a Linux-style registry hive file mounted as a
reiserfs filesystem.
However, I'd prefer to be able to use Windows-style registry hive files if
possible.
> > (3) Linux file structures do not hold enough information to support
> >
David Howells writes:
> Daniel Pittman <[EMAIL PROTECTED]> wrote:
>>> Thirdly, registry functions should issue system handles, as is done on
>>> Windows. If system handles move into the kernel, then registry handles
>>> should do too. This also means registry change notifications can be
>>> imple
Daniel Pittman <[EMAIL PROTECTED]> wrote:
> *blink* I confess that I can't see that much of a requirement for the
> ptrace stuff, but I take your word for it. :)
I was under the impression that the wineserver used ptrace() to retrieve
argument data to requests such as CreateFile(), but thinking
On Tue, 19 Sep 2000, David Howells <[EMAIL PROTECTED]> wrote:
> Daniel Pittman <[EMAIL PROTECTED]> wrote:
[...]
>> Anyway, why did you see the need for the registry stubs in this case,
>> if I may ask?
>
> Firstly, in wine the registry is handled by the wineserver process.
> This means it can
Daniel Pittman <[EMAIL PROTECTED]> wrote:
> Hrm. It would seem more sensible to me that the registry, like the GDI,
> live outside the kernel. This would have some cost in terms of
> performance, I admit, but I don't think it's significant enough to care.
>
> This is, I confess, based on my pers
Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > * file-change notification
> this is interesting for other stuff too, i think irix has an interface for
> that, i think its an ioctl?
Someone did a file-change notification patch for Linux. I'm not sure exactly
what became of it, but it'd be n
In article <[EMAIL PROTECTED]> you wrote:
> (1) An in-kernel resident lump, providing very basic services:
> * file-change notification
this is interesting for other stuff too, i think irix has an interface for
that, i think its an ioctl?
> * unicode string handling/conversion (ste
> > At the moment, the Win32 syscalls I implement require an fd to be
> > attached to a particular proc file. This fd holds the Win32 handle map.
>
> Huh?
Each process needs a handle map... To avoid playing with the task structure,
fork, exec, exit, signals, etc., I used an fd attached to a proc
Hi!
> David Howells <[EMAIL PROTECTED]> wrote:
> >
> >Oliver Neukum <[EMAIL PROTECTED]> wrote:
> >> > (3) Even if it was... just filling in the syscall slot from a module means
> >> > that it is possible for the module to be unloaded whilst the syscall is in
> >> > use.
>
> Note that al
In article <[EMAIL PROTECTED]>,
David Howells <[EMAIL PROTECTED]> wrote:
>
>Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> > (3) Even if it was... just filling in the syscall slot from a module means
>> > that it is possible for the module to be unloaded whilst the syscall is in
>> > use.
N
At the moment, the Win32 syscalls I implement require an fd to be attached to
a particular proc file. This fd holds the Win32 handle map.
The VFS provides auto-refcounting on modules that provide file operations,
thus the syscall stub only needs to check that the fd provided has the correct
set o
On Tue, 12 Sep 2000, David Woodhouse wrote:
> [snip]
>
> Code your win32 support module to register the PER_WIN32 personality, and
> set the sys_win32_handler pointer appropriately. Probably not in that order.
>
>
Could this be a solution for modules that intercept system calls from
"
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
> You don't need to make this code a module. If somebody else
> really wants a module, let them give you a patch.
I really want a module... At least while I'm writing the code. I don't want to
have to reboot every time I make a change.
> The actual
David Woodhouse <[EMAIL PROTECTED]> wrote:
> Aha. It's a device node provided by the same module? But what happens when
> the syscall is invoked with a fd which _isn't_ correct?
Well, a /proc file actually... but as part of registering the syscall handler,
you also pass a pointer to the file_ope
[EMAIL PROTECTED] said:
> I didn't know how to get hold of a "struct pt_regs*" till someone sent
> me a message this morning
Ah. I didn't realise you wanted the struct pt_regs for any purpose other
than to pass to the lcall7 handler - and I was no longer using the lcall7
handler in the sys_win
David Woodhouse <[EMAIL PROTECTED]> wrote:
> The code I posted yesterday is a bit of an abuse of the personality
> mechanism, but ought to work nonetheless. Didn't you like it?
I didn't know how to get hold of a "struct pt_regs*" till someone sent me a
message this morning (it was obvious reall
Well, I implemented the syscall last night... I decided it was too hard to do
a generic syscall handler without writing lots of non-portable assembly to do
one of the following (to deal with module reference counting):
(1) have a function that concocts a syscall 'thunk'
- needs to eit
In article <[EMAIL PROTECTED]> you wrote:
> #ifdef CONFIG_MODULES
> int dynamic_syscall_in_modules_helper(int syscall, struct module *mod)
> {
> /* blah, blah, blah */
> }
> EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
> #endif
> The whole function would depend on CONFIG_MODULES, n
> David Howells <[EMAIL PROTECTED]> wrote:
> > Now there's an idea... have the kernel autoload modules based on a
> > particular syscall number being handled in that module. Madness
> > *grin*.
[EMAIL PROTECTED] said:
> No more madness than kmod loading a module called char-major-10-135
> for /d
On Tue, 12 Sep 2000 14:54:29 +0100,
David Howells <[EMAIL PROTECTED]> wrote:
>Oliver Neukum <[EMAIL PROTECTED]> wrote:
>> This seems to me the best idea. However I would argue against dynamically
>> allocating syscalls. Reserving numbers makes for better code and allows you
>> to do autoloading.
[EMAIL PROTECTED] said:
> But where do I get the other argument (struct pt_regs *) from? A
> normal Linux syscall does not appear to have access to such a beast...
With difficulty. A normal syscall wouldn't generally go through the lcall7
handler. Some of the ABI/iBCS code gets access to the s
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > I think now that I'm probably best providing a generic pluggable syscall
> > handler, one that is very careful to make sure the syscall can't be entered
> > whilst the module is being unloaded.
>
> This seems to me the best idea. However I would argue
David Woodhouse <[EMAIL PROTECTED]> wrote:
> You don't need to add another handler. I already overloaded the lcall7
> handler by passing an extra int into it to tell it the type of call which is
> causing it to be invoked. Values which are already used are 7 for iBCS calls
> (lcall7) and 0x27 for
[EMAIL PROTECTED] said:
> Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in
> general, which'd be okay - obviously, if module support is disabled,
> you can't load a module anyway.
Well actually, that's not strictly true. But it is fair to say that if
you're hacking new code
Richard Guenther <[EMAIL PROTECTED]> wrote:
> Whats the problem with just not allowing the module to unload at all?
> Whats the point in unloading a module anyways. Ok, I know - debugging,
> etc. - but for a "release" version this is not important. Also upgrading -
> but for desktop boxes (for wh
On Tue, 12 Sep 2000, David Howells wrote:
>
> I think now that I'm probably best providing a generic pluggable syscall
> handler, one that is very careful to make sure the syscall can't be entered
> whilst the module is being unloaded.
>
Whats the problem with just not allowing the module to u
David Woodhouse <[EMAIL PROTECTED]> wrote:
> Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should
> not contain any code which is dependent on CONFIG_*_MODULE options.
>
> Therefore, stuff like...
>
> #ifdef CONFIG_WIN32_MODULE
> EXPORT_SYMBOL(my_win32_helper_func);
On Tue, 12 Sep 2000 12:40:45 +0200 (CEST),
[EMAIL PROTECTED] (Arjan van de Ven) wrote:
>In article <[EMAIL PROTECTED]> you wrote:
>> #ifdef CONFIG_MODULES
>> EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
>> #endif
>
>I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if
>m
In article <[EMAIL PROTECTED]> you wrote:
> #ifdef CONFIG_MODULES
> EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
> #endif
I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if
modules are turned off, as there is no use for it.
Greetings,
Arjan van de Ven
-
To unsubs
On Tue, 12 Sep 2000 10:25:16 +0100,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should
>not contain any code which is dependent on CONFIG_*_MODULE options.
>
>Therefore, stuff like...
>
>#ifdef CONFIG_WIN32_MODULE
> EXPORT
[EMAIL PROTECTED] said:
> I have to admit, the thought hadn't occurred to me to do that. It
> almost sounds like a good idea... after all the stub can't be used if
> no modules can be loaded. Are you thinking, then, that the stub can't
> be used by compiled in (ie non-module) code? Or am I misu
David Woodhouse <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] said:
> > The best solution is to have a stub which is always resident that
> > does the inc/dec of the module count. This stub can reserve the
> > syscall number as well.
>
> _Please_ don't have a stub in the kernel which is cond
David Howells wrote:
>
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > I see two possible solutions.
> >
> > Either you make that function available to user space by your syscall.
>
> Not a good idea... the whole point is to make sure no one is in a syscall when
> the module is unloaded. If you d
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> I see two possible solutions.
>
> Either you make that function available to user space by your syscall.
Not a good idea... the whole point is to make sure no one is in a syscall when
the module is unloaded. If you do it this way, the tail end of this
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
> The system call is needed of course, since that lets Linux executables
> (perhaps ones being ported from Win32) use the new features.
It also means that non-i386 and non-wine use these services if they want to.
> You might as well also handle int
David Howells writes:
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>> We already handle doing iBCS and Solaris syscalls by trapping int 7 and
>> int 0x27 insns and using a dedicated syscall handler - it doesn't go
>> anywhere near the original Linux syscall table.
>
> I was planning on having u
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Alright, let me ask that a different way: If I provide such a function in
> > the module, _what_ calls it from the main kernel?
>
> Nothing. It is called from userspace, or to be specific from wine.
> I would on second thought not limit this call to ro
David Woodhouse <[EMAIL PROTECTED]> wrote:
> We already handle doing iBCS and Solaris syscalls by trapping int 7 and
> int 0x27 insns and using a dedicated syscall handler - it doesn't go
> anywhere near the original Linux syscall table.
I was planning on having using a Linux syscall rather th
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > How does handle_unload_preparation() get invoked? And does lock_kernel()
>
> Explicitly, or via proc or sysctl.
Alright, let me ask that a different way: If I provide such a function in the
module, _what_ calls it from the main kernel?
David Howells
David Woodhouse <[EMAIL PROTECTED]> wrote:
> > How does handle_unload_preparation() get invoked? And does
> > lock_kernel() suppress syscall access?
>
> Do it with personalities. Only a binary with the Win32 personality can make
> a Win32 syscall. The module load/unload issues have already be
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > (3) Even if it was... just filling in the syscall slot from a module means
> > that it is possible for the module to be unloaded whilst the syscall is in
> > use.
> >
> > David Howells
>
> The following scheme might work:
>
> On module load:
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> So ask Linus for one. The streams group got one. Why shouldn't yo ?
Well, that's up to Linus... but from his email on this subject, he might well.
> Having a static syscall should be more efficient, too.
A little... otherwise it's a matter once per pr
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> What is the difference to get one reserved syscall and multiplex it ?
This is what I'd like to be able to do... that way the checks that ioctl()
performs can be avoided.
However, there are problems with doing this:
(1) There's currently no definitive
Dan Maas <[EMAIL PROTECTED]> wrote:
> This is done all the time -- with ioctl(). It's perfectly normal to create a
> special character device that just responds to an ioctl for each operation
> you want to perform. See eg any sound card driver...
Yes, that's how I'm doing it at the moment. Howev
"J. Robert von Behren" <[EMAIL PROTECTED]> wrote:
> Since at least two of us agree that having dynamically allocated syscall
> table entries would be handy, perhaps that is worth pursuing. I suppose
> the one issue (as you mention below) is that you might need a large
> number of these free entr
Hey David -
Since at least two of us agree that having dynamically allocated syscall
table entries would be handy, perhaps that is worth pursuing. I suppose
the one issue (as you mention below) is that you might need a large
number of these free entries. Does anyone know if there would be any
On Thu, Sep 07, 2000 at 10:46:58AM +0200, Martin Dalecki wrote:
> > I've done an implementation of some of the Win32 "system calls" in a kernel
> > module in an attempt to speed up Wine.
>
> Please by no way don't include this patch into the official tree.
> It's insane due to the following:
>
>
"J. Robert von Behren" <[EMAIL PROTECTED]> wrote:
> FWIW, this can be done with relatively low overhead by creating a
> miscelaneous character device, and just using write() to write in the
> arguments. This is a bit worse than passing things through registers,
> but doesn't seem all that bad.
David Howells wrote:
> (2) Some sort of support for (dynamically allocated) system calls implemented
> in modules.
FWIW, this can be done with relatively low overhead by creating a
miscelaneous character device, and just using write() to write in the
arguments. This is a bit worse than pa
On Fri, Sep 08, 2000 at 02:12:09PM +0100, David Howells wrote:
>
> (1) A death-knell callback list to be placed in the task structure. Each
> function so listed (if any) would be invoked upon exit, signal-death or
> execve.
The SGI accounting project (and other accouting projects whic
[EMAIL PROTECTED] (Linus Torvalds) wrote:
> >I've done an implementation of some of the Win32 "system calls" in a kernel
> >module in an attempt to speed up Wine.
> Hmm.. I have this feeling that it would be much nicer to just implement
> the NT system calls directly.
Yes, perhaps, but as far as
[EMAIL PROTECTED] said:
> We used to have the iBCS2 project, and I was actually considering
> making it part of the standard kernel when it started becoming a
> non-issue simply because there started to be more native Linux
> programs than iBCS2 programs.
Actually, you seemed to be considering
Horst von Brand <[EMAIL PROTECTED]> wrote:
> Lost me there. If after releasing the mutex it is free, the release was
> sucessful AFAIAC. If two threads try to do it at the same time, so what?
> Releasing an already free mutex is broken, OK. But two threads owning the
> mutex at the same time is m
In article <[EMAIL PROTECTED]>,
David Howells <[EMAIL PROTECTED]> wrote:
>
>I've done an implementation of some of the Win32 "system calls" in a kernel
>module in an attempt to speed up Wine.
Hmm.. I have this feeling that it would be much nicer to just implement
the NT system calls directly.
W
David Howells <[EMAIL PROTECTED]> said:
[...]
> Anyway, I though I could get away with it, but on reflection, perhaps
> not... If two threads of the same process try and issue ReleaseMutex()
> simultaneously on one mutex, then theoretically, one should succeed and the
> other fail, but given the
Andi Kleen <[EMAIL PROTECTED]> wrote:
> This is far from a single CPU instruction between the test_bit and the
> set_bit. Even with a single CPU instruction you would need a cmpxchg with
> retry BTW, to handle the case of multiple CPUs entering the instruction at
> the same time. The easiest fi
David Howells writes:
> I've done an implementation of some of the Win32 "system calls"
> in a kernel module in an attempt to speed up Wine.
Oh my. How dare you! I like it. :-)
> The preliminary benchmarks that I made, while not very real-world
> since I don't think I have managed to implement
David Howells <[EMAIL PROTECTED]> schrieb / wrote am / at : 07.09.2000
16:25:29
>
> Hold on a moment... You said "between the test bit and set bit"... this is a
> single CPU instruction! With the lock prefix, there should be no between.
>
> Also, a quote from asm/bitops.h:
> - /*
> - * These hav
On Thu, Sep 07, 2000 at 04:25:29PM +0100, David Howells wrote:
>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > But that's not race free on SMP. Two CPUs can set the bit in parallel
> > and you'll never notice. You would need at least a protecting spinlock
> > between the test bit and set bit (or a
Andi Kleen <[EMAIL PROTECTED]> wrote:
> But that's not race free on SMP. Two CPUs can set the bit in parallel
> and you'll never notice. You would need at least a protecting spinlock
> between the test bit and set bit (or a cmpxchg on x86)
Are you sure? I understood that the "lock" prefix on a
On Thu, Sep 07, 2000 at 02:44:26PM +0100, David Howells wrote:
>
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I did not see the lock. Where is it ?
>
> Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
> inserts an appopriate locking instruction into the assembly.
But that
Andi Kleen <[EMAIL PROTECTED]> wrote:
> I did not see the lock. Where is it ?
Well, on the bit functions set_bit() and test_and_clear_bit(), the macro
inserts an appopriate locking instruction into the assembly.
On the wait queue, the wait_queue structure includes
> I don't know too much abou
On Thu, Sep 07, 2000 at 02:28:36PM +0100, David Howells wrote:
> > I looked a bit over the code. Your Mutex classes do not look very SMP safe,
> > have they been tested with SMP ?
>
> Look carefully... It uses the atomic bit set/clear functions to modify the
> state, and the wait-queue carries it
Andi Kleen <[EMAIL PROTECTED]> wrote:
> It could use a read-only-to-clients shared memory with some locking tricks.
You still have to be able to emulate WaitForMultipleObjects() which I think is
quite difficult from userspace. It can perhaps be done with signals, but that
then incurs costs in inv
Simon Richter wrote:
>
> On Thu, 7 Sep 2000, Martin Dalecki wrote:
>
> > > I've done an implementation of some of the Win32 "system calls" in a kernel
> > > module in an attempt to speed up Wine.
>
> > 1. Linux is UNIX not NT... (in terms of API)
>
> What about a Win32 personality?
>
> > 2. W
On Thu, 7 Sep 2000, Martin Dalecki wrote:
> > I've done an implementation of some of the Win32 "system calls" in a kernel
> > module in an attempt to speed up Wine.
> 1. Linux is UNIX not NT... (in terms of API)
What about a Win32 personality?
> 2. WINE in itself is barely usefull - even in fa
On Thu, 7 Sep 2000, Martin Dalecki wrote:
> 2. WINE in itself is barely usefull - even in fact non existant, since
> there is no official stable release out there.
Speak for yourself. Many people find it extremely useful; some depend on
it.
-Dan
-
To unsubscribe from this list: send the line "u
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
> how about the classical standard way of "getting to kernel space", i.e.
> plain system calls? Unless you really need a huge number of new system
> calls,
Just the one... this'll take a parameter specifying the Win32 call to make:
int win32(int f
> Please by no way don't include this patch into the official tree.
I wasn't intending to put it up for inclusion into the main kernel tree... I
think it is far better that it stays as a module, especially as it doesn't
require any changes to the main tree to be used, it can just be loaded when
Hi David,
> I'm also interested in finding a better way of getting to kernel space from
> user space... Currently, this involves the client process opening a proc file
> and doing ioctl's on it to request Win32 operations (easy to do from a kernel
> module).
how about the classical standard way
David Howells wrote:
>
> I've done an implementation of some of the Win32 "system calls" in a kernel
> module in an attempt to speed up Wine.
Please by no way don't include this patch into the official tree.
It's insane due to the following:
1. Linux is UNIX not NT... (in terms of API)
2. WINE
I've done an implementation of some of the Win32 "system calls" in a kernel
module in an attempt to speed up Wine.
The preliminary benchmarks that I made, while not very real-world since I
don't think I have managed to implement enough for that yet, seem to indicate
that in some tests, I can bea
85 matches
Mail list logo
