On Tue, Aug 18, 2009 at 10:56, Maxim Kuvyrkov<maxim@xxxxxxxxxxxxxxxx> wrote:
Andreas Schwab wrote:
Maxim Kuvyrkov <maxim@xxxxxxxxxxxxxxxx> writes:
The need would be (a) use numbers that are very unlikely to used for
normal syscalls,
I don't understand. These are normal syscalls.
and (b) using -1..-4 for the syscall numbers works out quite nicely
for the code in entry.S. It adds just a couple of instructions to the
execution path.
Those additional instructions are totally unnecessary.
Hm, I though it would be preferable to keep syscalls that are specific to
m68k (in the sense that no other target requires them) separate from the
ones implementing standard unix/linux functionality.
If the consensus is that the new syscalls should received 331..334 numbers,
that would only simplify the implementation.
I prefer to just add them at the bottom of the list.
(slowly recovering from my backlog) I noticed some new syscalls got
added recently:
| <stdin>:1515:2: warning: #warning syscall rt_tgsigqueueinfo not implemented
| <stdin>:1519:2: warning: #warning syscall perf_counter_open not implemented
Probably I should wire those up first (for 2.6.31, if still possible).
Next I should reserve 333..336 for you?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
