From: Arnd Bergmann <arnd@arndb.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Pavel Machek <pavel@ucw.cz>,
linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH 7/8] ppc64: SPU file system
Date: Sun, 15 May 2005 14:33:09 +0200 [thread overview]
Message-ID: <200505151433.11108.arnd@arndb.de> (raw)
In-Reply-To: <1116158548.5095.17.camel@gaston>
On Sünndag 15 Mai 2005 14:02, Benjamin Herrenschmidt wrote:
>
> > That's even more evil than ioctl()... Try doing 32-vs-64bit conversion
> > on write...
>
> I don't see the problem ... if you are passing a structure, you have to
> convert it anyway, and it's bad practice. I was thinking about passing
> ascii so it can be controlled by shell scripts.
Parsing multi-value ascii data is error prone. in kernel space, I would
not want to do anything more complex than a simple_strtoul(), if only
for the reason of not giving bad examples.
When passing binary structures, there is a significant difference between
passing it through ioctl or read/write: We already have a rather complicated
method of detecting if whether and how to convert them (f_op->compat_ioctl,
hash lookup and the deprecated dynamic registration).
For read/write, there is no way to tell if you need to do the conversion,
even if the file operation is aware of the actual data layout of both
variants. Moreover, a good implementation of a read/write file operation
should be able to deal with resuming partial transfers.
Regarding the shell scripting possibility, I don't really see the point.
The only code that should actually use the kernel interfaces is something
like an /lib/ld-spu.so interpreter and that is better implemented in C
anyway because it needs to parse ELF structures and such.
Arnd <><
next prev parent reply other threads:[~2005-05-15 12:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 19:31 [PATCH 0/8] ppc64: Introduce Cell/BPA platform, v2 Arnd Bergmann
2005-05-13 19:21 ` [PATCH 1/8] ppc64: split out generic rtas code from pSeries_pci.c Arnd Bergmann
2005-05-13 19:23 ` [PATCH 2/8] ppc64: add a minimal nvram driver Arnd Bergmann
2005-05-13 19:24 ` [PATCH 3/8] ppc64: add a watchdog driver for rtas Arnd Bergmann
2005-05-17 20:40 ` Nathan Lynch
2005-05-18 7:14 ` Arnd Bergmann
2005-05-18 14:45 ` Nathan Lynch
2005-05-18 14:39 ` Arnd Bergmann
2005-05-13 19:25 ` [PATCH 4/8] ppc64: add BPA platform type Arnd Bergmann
2005-05-17 7:01 ` Paul Mackerras
2005-05-17 11:05 ` Arnd Bergmann
2005-05-13 19:26 ` [PATCH 5/8] ppc64: Add driver for BPA interrupt controllers Arnd Bergmann
2005-05-13 19:27 ` [PATCH 6/8] ppc64: Add driver for BPA iommu Arnd Bergmann
2005-05-13 19:29 ` [PATCH 7/8] ppc64: SPU file system Arnd Bergmann
2005-05-13 23:31 ` Benjamin Herrenschmidt
2005-05-15 9:07 ` Pavel Machek
2005-05-15 12:02 ` Benjamin Herrenschmidt
2005-05-15 12:33 ` Arnd Bergmann [this message]
2005-05-14 7:45 ` Greg KH
2005-05-14 13:05 ` Arnd Bergmann
2005-05-15 6:29 ` Benjamin Herrenschmidt
2005-05-15 10:08 ` Arnd Bergmann
2005-05-15 11:50 ` Arnd Bergmann
2005-05-16 20:58 ` Greg KH
2005-05-16 22:01 ` Arnd Bergmann
2005-05-16 22:27 ` Greg KH
2005-05-16 22:22 ` Arnd Bergmann
2005-05-16 22:49 ` Greg KH
2005-05-15 11:24 ` Andi Kleen
2005-05-16 20:14 ` Roland Dreier
2005-05-16 20:53 ` Greg KH
2005-05-18 12:40 ` [PATCH] libfs: add simple attribute files Arnd Bergmann
2005-05-18 20:24 ` Greg KH
2005-05-19 8:29 ` Arnd Bergmann
2005-05-19 9:18 ` 2.4 Kernel threads linux
2005-06-10 4:33 ` [PATCH] libfs: add simple attribute files Greg KH
2005-05-13 19:32 ` [PATCH 8/8] ppc64: add spufs user library Arnd Bergmann
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=200505151433.11108.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=pavel@ucw.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.