Message-ID: <20060716194150.GB17172@flint.arm.linux.org.uk>
Date:	Sun, 16 Jul 2006 20:41:50 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	Kyle Moffett <mrmacman_g4@....com>, dwmw2@...radead.org,
	arjan@...radead.org, maillist@...55.com, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: 2.6.18 Headers - Long

On Sun, Jul 16, 2006 at 03:22:01PM -0400, Albert Cahalan wrote:
> On 7/16/06, Russell King <rmk+lkml@....linux.org.uk> wrote:
> >On Sun, Jul 16, 2006 at 02:38:45PM -0400, Albert Cahalan wrote:
> >> On 7/16/06, Kyle Moffett <mrmacman_g4@....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.
> 
> Again:
> 
> Plenty of headers are only exported for some architectures.

So?  I don't see the relevance of this statement.

> In other words, for all architectures where things work.

And this doesn't make sense (it doesn't contain a verb for a start.)

> >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.
> 
> Now you are really wrong. :-)

ARM is heavily embedded, and I've never ever had any requests concerning
"can we disable the scheduler from userspace" from anyone...

> >> 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.
> 
> No. The normal interfaces are dreadful.
> 
> App developers will just cut-and-paste the i386 kernel
> code if you take away the header files. They do that
> often enough already.

And by that statement you just agreed with the part of my mail that you
conveniently cut.

> So all you succeed in doing is eliminating any hope of portability
> to ppc and similar.  This is not an improvement.

I tend to disagree.  In reality folk work towards removing such
dependencies.  We saw it with the old minix tools - they're now fixed.
We've seen it with others, which also eventually got fixed.

The general trend has been to be to fix up these problems as they're
found.

Yes, there are some subborn userspace developers out there, but they'll
continue to be stubborn all the time that their way works.

And finally, bear in mind that we have almost 175 ARM platform designs
registered so far this year, most of them embedded.  So it's a _very_
active space.  Couple that with the lack of folk reporting the problem
you're alluding to... despite ARM atomic ops being protected by
__KERNEL__ and use of ARM kernel bitops in userspace would cause link
errors.

My experience has been obviously different from yours, and therefore I
hold different views.  I don't see the problem.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists