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,
"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
"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 suppose
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
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
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
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
"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
"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
avoid is
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 feature a
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
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 like to
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 ->
[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
[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 acahalan
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 - /dev/pts/4
"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
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
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
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 different
"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 acahalan
> 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
>>>
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
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
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
implemented by
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
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
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 nice
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 personal
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
> > 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
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
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 file
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
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 all this is not the
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.
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
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
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
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
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
[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
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
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
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 really).
[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
> 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
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
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
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
[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
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
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
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
>
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
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
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
>
[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
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
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 conditionally
[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
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
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
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
modules are
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);
#endif
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
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 which
[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
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
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 against
[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
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.
Now
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
"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
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
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
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
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.
"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
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. However,
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
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
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 using a
"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 0x2e
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
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
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
[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
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
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 much
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 which
1 - 100 of 125 matches
Mail list logo
