[PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Jonas Bonn]

From: Jonas Bonn <jonas@southpole.se>

This enables the syscall for architectures, like OpenRISC, that use the
generic asm headers.

Signed-off-by: Jonas Bonn <jonas@southpole.se>
---
 include/asm-generic/unistd.h |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
index 6b5bfb5..e4c7366 100644
--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -681,9 +681,11 @@ __SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
 __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
 #define __NR_syncfs 267
 __SYSCALL(__NR_syncfs, sys_syncfs)
+#define __NR_sendmmsg 268
+__SC_COMP(__NR_sendmmsg, sys_sendmmsg, compat_sys_sendmmsg)
 
 #undef __NR_syscalls
-#define __NR_syscalls 268
+#define __NR_syscalls 269
 
 /*
  * All syscalls below here should go away really,
-- 
1.7.4.1

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Arnd Bergmann]

On Saturday 28 May 2011 22:19:29 Jonas Bonn wrote:
> 
> From: Jonas Bonn <jonas@southpole.se>
> 
> This enables the syscall for architectures, like OpenRISC, that use the
> generic asm headers.
> 
> Signed-off-by: Jonas Bonn <jonas@southpole.se>

Thanks, looks good.

I just saw your git tree for the OpenRISC architecture port and it
looks really really nice, mostly by virtue of being very small, but
also by not copying all the things that new architecture ports normally
get wrong at the time when they show up on my radar.

Do you plan to submit it upstream any time soon?

There are four other new architectures that I expect to see soon (c6x,
nios2, lm32, plus one more), and I'd really like to have one architecture
serve as a good example that I can point the others to. unicore32 and
tile are the best ones we have, but neither is a really good example:
unicore32 has a few remaining bits unnecessarily copied from ARM, and
Tile is for a much more complex hardware than I want. Also, they
both don't use a flattened device tree to describe SoC parts.

Your OpenRISC port is much better in each of these regards, so that
it would be great to have that ready for inclusion in the next merge
window. There are obviously a few details to fix, but I can see nothing
in there that would require a significant amount of work.

	Arnd

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Jonas Bonn]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Sat, 2011-05-28 at 23:24 +0200, Arnd Bergmann wrote:
> I just saw your git tree for the OpenRISC architecture port and it
> looks really really nice, mostly by virtue of being very small, but
> also by not copying all the things that new architecture ports normally
> get wrong at the time when they show up on my radar.

> Do you plan to submit it upstream any time soon?

Yes, it's pretty much ready for submission.  There are a couple of areas
that I'm aware of that still need some work and there are some cleanups
to do, but everything that faces userspace (ABI) has settled so it's
stuff that could be done even after merging upstream.

What would be the best approach to request review?  I saw that the
unicore32 architecture was posted in 'functional/subsystem' chunks... is
that the best way to do it?  Shall I do the same, or do you have a
suggestion for a better way to do it?

/Jonas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Arnd Bergmann]

On Saturday 28 May 2011 23:55:46 Jonas Bonn wrote:
> On Sat, 2011-05-28 at 23:24 +0200, Arnd Bergmann wrote:
> > I just saw your git tree for the OpenRISC architecture port and it
> > looks really really nice, mostly by virtue of being very small, but
> > also by not copying all the things that new architecture ports normally
> > get wrong at the time when they show up on my radar.
> 
> > Do you plan to submit it upstream any time soon?
> 
> Yes, it's pretty much ready for submission.  There are a couple of areas
> that I'm aware of that still need some work and there are some cleanups
> to do, but everything that faces userspace (ABI) has settled so it's
> stuff that could be done even after merging upstream.

Ok, great! Please submit them as soon as possible, while there is time
before the next merge window.

> What would be the best approach to request review?  I saw that the
> unicore32 architecture was posted in 'functional/subsystem' chunks... is
> that the best way to do it?  Shall I do the same, or do you have a
> suggestion for a better way to do it?

Yes, that is the best way. At first, leave out any device driver changes,
and submit only the code you need to have something that boots. Split
that up into around 15 patches, e.g.

* boot code
* memory management
* user interface
* platform support
* ptrace
* signal handling
* ...

It's ok if these are of very different size, the most important point
in the split is to do it in a way that most reviewers only need to
look at the few patches that they are interested in.

You can simultaneously start submitting device driver changes to the
respective subsystem mailing lists (netdev, spi, ...), those do not
need to be posted to linux-arch.

When you submit the patches, use git-send-email --no-chain-reply --thread
and put a good summary in the introductory mail, describing any changes
you still plan to do, and changes you have done since the previous
submission.

A few minor things that you might still want to do (or list them as TODO)
are:

* fold the board/config.c file into kernel/setup.c.

* replace trivial files in openrisc/include/asm/ with "generic-y += foo.h"
  entries in asm/Kbuild

* use CONFIG_GENERIC_CSUM instead of providing your own implementation

* remove all __ARCH_WANT_* from asm/unistd.h and use the generic glibc
  implementation.

* Figure out what the dma-mapping implementation should look like.
  It seems to me that you just copied from microblaze but didn't
  completely understand what you need. We can definitely help you here
  if you can explain how DMA works on openrisc. In doubt, don't
  set CONFIG_HAS_DMA and use asm-generic/dma-mapping-broken.h.

	Arnd

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Jonas Bonn]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On Sun, 2011-05-29 at 20:27 +0200, Arnd Bergmann wrote:
> Yes, that is the best way. At first, leave out any device driver changes,
> and submit only the code you need to have something that boots. Split
> that up into around 15 patches, e.g.
> 
>  <snip>

Thanks for the thorough instructions... much appreciated.
I'll see if I can get this sorted out during this week.

> 
> * remove all __ARCH_WANT_* from asm/unistd.h and use the generic glibc
>   implementation.

I tried this earlier but ran into issues with uClibc, which is the only
libc port that we currently have.  Is uClibc known to be compatible with
the reduced set of syscalls?

A good compromise here may be to submit the patch upstream with the
reduced set of syscalls but to maintain a separate tree locally that
reenables these for use with our current uClibc port until we can get it
straightened out.  It would be good to know, however, what's known to be
working for others in this area...

> 
> * Figure out what the dma-mapping implementation should look like.
>   It seems to me that you just copied from microblaze but didn't
>   completely understand what you need. We can definitely help you here
>   if you can explain how DMA works on openrisc. In doubt, don't
>   set CONFIG_HAS_DMA and use asm-generic/dma-mapping-broken.h.
> 

Yes, exactly... this was on the TODO list of cleanups.  I'll admit that
I was confused by this code so I may be asking for some help in this
area.

/Jonas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Arnd Bergmann]

On Sunday 29 May 2011 23:30:24 Jonas Bonn wrote:
> > * remove all __ARCH_WANT_* from asm/unistd.h and use the generic glibc
> >   implementation.
> 
> I tried this earlier but ran into issues with uClibc, which is the only
> libc port that we currently have.  Is uClibc known to be compatible with
> the reduced set of syscalls?
> 
> A good compromise here may be to submit the patch upstream with the
> reduced set of syscalls but to maintain a separate tree locally that
> reenables these for use with our current uClibc port until we can get it
> straightened out.  It would be good to know, however, what's known to be
> working for others in this area...

I don't think that there is a port today, but you can maybe Chris Metcalf,
Guan Xuetao or Linas Vepstas know more about this, as they have all
worked on the glibc support for the generic syscall interface.

Right now, you set these five ones:

#define __ARCH_WANT_SYSCALL_NO_AT
#define __ARCH_WANT_SYSCALL_NO_FLAGS
#define __ARCH_WANT_SYSCALL_OFF_T
#define __ARCH_WANT_SYSCALL_DEPRECATED
#define __ARCH_WANT_IPC_PARSE_VERSION

I suggest that you try to get rid of them in reverse order, the last
two are the really important ones and should not cause a lot of
trouble at all. The interface impacted by this have long ago been
deprecated, so it should basically work without them, except for
possible bugs in uClibc.

__ARCH_WANT_SYSCALL_OFF_T is about the 32 bit off_t syscalls.
I don't know if they are supported in uClibc, but I would expect
that you can lose this if you hardcode uClibc to do 64 bit
off_t, but it could be a lot of work if it's not that easy.

The other three are for system calls that have been replaced by
new ones much more recently, so supporting them definitely requires
writing new libc code. You might be able to reuse the code that
Chris Metcalf wrote for glibc here.

As an intermediate solution, you can keep a private patch that
adds the hacks back in, while submitting the clean unistd.h
version without them for upstream inclusion. Just remember to
actually do the work for removing them eventually.

	Arnd

Re: [PATCH 1/1] Add new syscall sys_sendmmsg to generic unistd

[Chris Metcalf]

On 5/29/2011 5:57 PM, Arnd Bergmann wrote:
> On Sunday 29 May 2011 23:30:24 Jonas Bonn wrote:
>>> * remove all __ARCH_WANT_* from asm/unistd.h and use the generic glibc
>>>   implementation.
>>
>> I tried this earlier but ran into issues with uClibc, which is the only
>> libc port that we currently have.  Is uClibc known to be compatible with
>> the reduced set of syscalls?
>>
>> A good compromise here may be to submit the patch upstream with the
>> reduced set of syscalls but to maintain a separate tree locally that
>> reenables these for use with our current uClibc port until we can get it
>> straightened out.  It would be good to know, however, what's known to be
>> working for others in this area...
> 
> I don't think that there is a port today, but you can maybe Chris Metcalf,
> Guan Xuetao or Linas Vepstas know more about this, as they have all
> worked on the glibc support for the generic syscall interface.

The arch/tile glibc port works with none of the "extra" syscalls.  It has
not yet been pushed back to the community (although we just got our FSF
paperwork complete), but you can grab our version from
http://www.tilera.com/scm/ .  I tried to extract the asm-generic aspects
into a sysdeps/unix/sysv/linux/generic/ hierarchy as distinct from the
actual tile-specific code.

We hacked up uclibc to handle our architecture, too, but then discontinued
support for it, and the code was a pretty gnarly set of hacks on top of the
old nptl branch (long since merged into the uclibc trunk).

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com