lkml.org 
[lkml]   [1999]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: user space writel() etc. in 2.2.2

> Sender: owner-linux-kernel@vger.rutgers.edu
> From: Vassili Leonov <vleo@linuxmedialabs.com>
> Date: Fri, 5 Mar 1999 11:11:11 -0700 (MST)
> To: Jes Sorensen <Jes.Sorensen@cern.ch>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.rutgers.edu
> Subject: Re: user space writel() etc. in 2.2.2
> -----
> On 5 Mar 1999, Jes Sorensen wrote:
>
> > Alan> thats really going to work well from user space. The moment you
> > Alan> go digging into devices directly from user space you lose
> > Alan> portability.
> You loose portability because there is no writel() defined in 2.2 (since
> 2.13). Somehow that was not the case under 2.0. I think this needs to be
> addressed. The simple way is to add writel() etc. to <asm/io.h>.
>
> Besides, why i386/io.h does not know anything about writel() in non
> __KERNEL__ , whereas alpha/io.h declares them as extern. That sure is
> inconsitent.
>
> On the other hand - WHY one loses portability doing IO memory access on
> different architectures? Sure enough that PCI memory would be present on
> any architecture that has that PCI plugged in, and registers would be the
> same (though ordering might differ, and that is the responsibility of
> writel() etc. to handle it.

X servers talking directly to frame buffers generally use code that is
generated directly from some very "interesting" macros, that is carefull
about alignment issues in the first place. The portable X frame buffer
code is one of the more interesting pieces of code around, particularly
once you realize the same source file generates a bunch of other .c files
that actually do the work. They certainly do not do function calls (or
even invoke other macros) to "do the right thing".

> >
> > Hmmm, good point - I wonder how the XFree people solved this for the
> > Alpha X servers.
> Well, how does this fit with the point that user space IO memeory access
> is bad? Sure enough X11 is all based on this "bad" concept.

Lesser of several evils; putting all the graphics code required in a window
system into the kernel is much worse (particularly due to the schedular
problems it would generate; a bit blit of a large area of the screen is
not something you want to do without pre-emption). People went there
in the 1980's, tried it, and didn't like it... The graphics performance
requirements are also very high; the system call boundary is a problem.

I've never seen it as a real problem from an architecture point of view
that certain hardware may be mapped where user space programs can access
it directly, presuming the hardware itself is not going to compromise the
integrity of the system (certainly true for alot of graphics hardware).
But then again, I'm biased...

- Jim Gettys


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.414 / U:0.676 seconds]
©2003-2014 Jasper Spaans. hosted at Digital Ocean