From: Michal Simek <monstr@seznam.cz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Will Newton <will.newton@gmail.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-arch@vger.kernel.org, git@xilinx.com,
microblaze-uclinux@itee.uq.edu.au
Subject: Re: microblaze syscall list
Date: Thu, 24 Apr 2008 20:42:44 +0200 [thread overview]
Message-ID: <4810D4A4.7050900@seznam.cz> (raw)
In-Reply-To: <200804241311.09881.arnd@arndb.de>
Hi Arnd,
>> I would like to fix syscalls in Microblaze repo. Can you give me a hint how to
>> do it?
>
> I think we need to do it on a case-by-case basis, best here on the
> linux-arch mailing list. I'm sure there are some controversial ones,
> but most should be pretty clear.
>
>> I look at Blackfin arch and I compared files with microblaze. There are some
>> differences but not so much.
>> Can you tell me how to test it which syscall is necessary for platform.
>> I have never found any documentation about.
>
> Hopefully we can get to this kind of documentation by the end of this
> discussion. scripts/checksyscalls.sh is some part of the documentation,
> and we can refine that.
:-)
> Maybe we can even have an asm-generic/unistd.h that defines all the
> still relevant syscalls, plus a per-architecture range that you can
> use for microblaze-specific calls in your own unistd.h.
That will be really useful. Good idea.
>> In my syscall_table.S (on some arch in entry.S) is one big jump table with
>> reference to syscalls. In unistd.h is definition.
>>
>> Is there any convention which syscalls are use for all archs and which are
>> architecture specific?
>
> Not really. There are very few syscalls that are needed only on certain
> architectures. The more common case is that a syscall has been replaced
> by a more complex interface, and a new architecture only needs one of the
> two, while older architectures still need both.
>
> Let me just comment on your syscall table as it is today:
>
>> ENTRY(sys_call_table)
>> .long sys_restart_syscall /* 0 - old "setup()" system call,
>> * used for restarting */
>
> The comment is irrelevant and misleading -- microblaze never had sys_setup.
I removed this comment.
>> .long sys_exit
>> .long sys_ni_syscall /* was fork */
>
> it might be useful to renumber your calls once all the irrelevant ones
> have been removed, so you can get rid of all the sys_ni_syscalls here.
I'll delete all sys_ni_syscall from syscall_table.S and I'll remove it from
unistd.h too. I hope I'll keep the same call numbers.
>> .long sys_read
>> .long sys_write
>> .long sys_open /* 5 */
>
> Since we have all the new sys_*at calls like openat, we don't really
> need the old versions any more. The kernel implementation of sys_open
> basically calls openat. You could do the same in libc instead.
> Don't know if that's worth it though, opinions?
I looked at it and there are the different arguments for open and openat
syscalls. Implementation is almost the same. I keep it now.
>> .long sys_close
>> .long sys_waitpid
>
> waitpid and wait4 can be replaced with waitid
Can I keep number of syscall(unistd.h) and only add reference to waitid in
syscall_table? or just remove?
>> .long sys_creat
>> .long sys_link
>> .long sys_unlink /* 10 */
>> .long sys_execve_wrapper
>
> having an execve_wrapper instead of execve looks like a strange convention,
> though I guess you had a good reason for it, could you explain?
>
> This one looks architecture specific, so you may want to rename it
> microblaze_execve_wrapper instead of sys_execve_wrapper.
I looked at it and the same of style is used in arm
(arch/arm/kernel/entry-common.S) and some others arch. This wrapper only set one
parameter to correct pointer to stack.
I'll comment the rest later. I need time to look at it.
Thanks for your big help. I really appreciate this.
Michal
next prev parent reply other threads:[~2008-04-24 18:41 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 12:13 [RFC] Introduce __ARCH_WANT_SYS_SYSFS Will Newton
2008-04-22 13:15 ` Arnd Bergmann
2008-04-23 21:16 ` Michal Simek
2008-04-23 21:38 ` Mike Frysinger
2008-04-24 11:11 ` microblaze syscall list Arnd Bergmann
2008-04-24 18:42 ` Michal Simek [this message]
2008-04-24 21:21 ` Arnd Bergmann
2008-04-25 9:36 ` [microblaze-uclinux] " John Williams
2008-04-25 10:06 ` Matthew Wilcox
2008-04-25 11:32 ` Geert Uytterhoeven
2008-04-27 2:04 ` John Williams
2008-04-27 15:52 ` Michal Simek
2008-04-27 16:50 ` Alan Cox
2008-04-27 20:15 ` Arnd Bergmann
2008-04-28 0:15 ` John Williams
2008-04-28 12:31 ` Arnd Bergmann
2008-05-01 19:17 ` Arnd Bergmann
2008-05-02 5:38 ` John Williams
2008-05-02 8:18 ` Michal Simek
2008-05-03 3:49 ` John Williams
2008-05-03 9:16 ` Arnd Bergmann
2008-05-03 15:56 ` Ulrich Drepper
2008-05-03 21:14 ` Arnd Bergmann
2008-05-05 1:09 ` John Williams
2008-05-05 14:08 ` Arnd Bergmann
2008-05-03 21:57 ` Arnd Bergmann
2008-05-04 9:12 ` Michal Simek
2008-05-04 19:37 ` Arnd Bergmann
2008-05-05 6:18 ` Michal Simek
2008-05-04 22:09 ` H. Peter Anvin
2008-05-04 22:54 ` Arnd Bergmann
2008-05-04 22:53 ` H. Peter Anvin
2008-05-06 8:33 ` Michal Simek
2008-04-24 20:51 ` Michal Simek
2008-04-24 21:37 ` Arnd Bergmann
2008-04-22 15:12 ` [RFC] Introduce __ARCH_WANT_SYS_SYSFS Randy Dunlap
2008-04-22 15:16 ` Will Newton
2008-04-22 15:24 ` Kyle McMartin
2008-04-22 15:34 ` Will Newton
2008-04-22 15:38 ` Kyle McMartin
2008-04-23 14:36 ` Will Newton
2008-04-23 14:59 ` Arnd Bergmann
2008-04-23 15:40 ` Kyle McMartin
2008-04-23 15:50 ` Will Newton
2008-04-23 16:05 ` Mike Frysinger
2008-04-23 17:59 ` Mike Frysinger
2008-04-24 9:18 ` Will Newton
2008-04-23 18:44 ` Sam Ravnborg
2008-04-24 14:51 ` Adrian Bunk
2008-04-22 15:21 ` Kyle McMartin
2008-04-22 15:38 ` Arnd Bergmann
2008-04-22 15:42 ` Kyle McMartin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4810D4A4.7050900@seznam.cz \
--to=monstr@seznam.cz \
--cc=arnd@arndb.de \
--cc=git@xilinx.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=will.newton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®