On Tue, Aug 18, 2009 at 10:56, Maxim Kuvyrkov<[email protected]> wrote:
> Andreas Schwab wrote:
>> Maxim Kuvyrkov <[email protected]> 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 -- [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
