From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Albert Cahalan <acahalan@gmail.com>
Cc: Kyle Moffett <mrmacman_g4@mac.com>,
dwmw2@infradead.org, arjan@infradead.org, maillist@jg555.com,
ralf@linux-mips.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
Subject: Re: 2.6.18 Headers - Long
Date: Sun, 16 Jul 2006 19:53:14 +0100 [thread overview]
Message-ID: <20060716185314.GA17172@flint.arm.linux.org.uk> (raw)
In-Reply-To: <787b0d920607161138l4b6dc25dycaeaaea5e948c769@mail.gmail.com>
On Sun, Jul 16, 2006 at 02:38:45PM -0400, Albert Cahalan wrote:
> On 7/16/06, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> >On Jul 15, 2006, at 17:09:28, Albert Cahalan wrote:
>
> >You realize that on a couple architectures it's fundamentally
> >impossible to get atomic ops completely in userspace, right?
>
> Sure. Those architectures don't need to drag down the rest.
> Plenty of headers are only exported for some architectures.
Wrong perspective. The problem is that they may _appear_ to work as
described, but not actually work in the intended way. That's a bug,
and it's a _hard_ bug to locate.
> (Well actually, such architectures could just give apps a
> writable flag to disable the scheduler -- this is acceptable
> for the embedded things these architectures are used for.
Cloud cuckoo land. In the embedded world, there are folk still want
to have the security aspects as well. Moreover, there are far more
folk who do _NOT_ want to have things like "disable the scheduler" -
think the realtime folk.
> It's not as if the app developers would care to support
> those architectures anyway.
That's actually more of a reason to take away the toys they shouldn't
be playing with in the first place - the only reason these (wrong)
interfaces are being used is because they're easily accessible. Had
they _never_ been visible to userspace, no one would've attempted to
use them in the first place.
So, take away the "easily accessible" bit on the common architectures
and they'll find different ways to meet their needs. Hopefully, that
will be some portable solution instead of one where racy code goes by
unnoticed. If it isn't, at least there will be build errors to tell
you something needs to be fixed (probably from the assembler!)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2006-07-16 18:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-15 21:09 2.6.18 Headers - Long Albert Cahalan
2006-07-15 21:19 ` Arjan van de Ven
2006-07-17 5:21 ` Ralf Baechle
2006-07-15 21:44 ` Adrian Bunk
2006-07-15 21:47 ` David Woodhouse
2006-07-16 6:18 ` Albert Cahalan
2006-07-16 6:26 ` Arjan van de Ven
2006-07-16 8:05 ` David Woodhouse
2006-07-16 8:20 ` Jakub Jelinek
2006-07-16 12:34 ` Kyle Moffett
2006-07-16 12:48 ` Russell King
2006-07-16 18:38 ` Albert Cahalan
2006-07-16 18:53 ` Russell King [this message]
2006-07-16 19:22 ` Albert Cahalan
2006-07-16 19:41 ` Russell King
2006-07-17 1:26 ` Arjan van de Ven
2006-07-17 1:23 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2006-07-12 0:35 Jim Gifford
2006-07-14 0:25 ` David Woodhouse
2006-07-14 2:18 ` Jim Gifford
2006-07-14 18:55 ` David Woodhouse
2006-07-14 19:28 ` Jim Gifford
2006-07-14 19:39 ` Arjan van de Ven
2006-07-14 20:16 ` David Woodhouse
2006-07-14 20:19 ` David Miller
2006-07-14 20:57 ` Jim Gifford
2006-07-15 4:33 ` Randy.Dunlap
2006-07-16 14:08 ` Nix
2006-07-15 7:19 ` David Woodhouse
2006-07-15 7:08 ` David Woodhouse
2006-07-14 19:57 ` David Woodhouse
2006-07-14 20:06 ` Erik Andersen
2006-07-14 20:19 ` Christoph Hellwig
2006-08-26 16:09 ` David Woodhouse
2006-08-29 12:25 ` Ralf Baechle
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=20060716185314.GA17172@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=acahalan@gmail.com \
--cc=arjan@infradead.org \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maillist@jg555.com \
--cc=mrmacman_g4@mac.com \
--cc=ralf@linux-mips.org \
/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