On 19 Jul 2003, rahul patil wrote:
>
> hi,
> I want build an application that requires the exact memory address
> (for LCD display). I use ioremap to achieve that. However, when i
> try to compile the file, i get the following error.
>
> implicit declaration of ioremap
> and hence
> unreferenced ioremap
>
> I assume that this is becuase I can use ioremap only in kernel
> mode. I have tried using ioperm and iopl, but these work only on
> intel architecure and my platform does not support this. Nor do i
> have the device file /dev/port for my platform.
>
> Is there are any way, I can access and set the memory directly in
> the user(application) mode ? I do want to avoid building a driver
> and recompiling with the kernel.
>
> The source code is as simple as
> #include<asm/io.h>
> void main()
> {
> ioremap(0x10000,100);
> }
>
> Thanks and regards,
> Rahul Patil
Well, Rahul, I gotta tell ya... I don't respond to many posts - still not
a Wizard with Linux yet. But your post just stung somehow.
...Mmmmm... OK, I should first disclaim: On Red Hat Linux: I have no idea.
Magic is _always_ possible.
That said, I think your idea of trying to access a specific address and
_not_ having a driver do it is just crazy.
So you have some reason to listen, I offer a few keystrokes of resume
summary: ...Way back in the late '70's, I wrote an entire operating
system, by myself, in assembler/machine language that's still in use
today controlling pipelines, ships and chemical refineries. Since then,
I've been a magus at several operating systems and fully deserve the title
Wizard in more than a few venues...
The specific concept of accessing a particular address is _deeply_ embeded
in the larger concept of what an operating system is all about. By
accessing a specific hardware register accessible at some memory address
you are by definition writing a device driver. The question is; will yours
either cause problems for other aspects of the system, or other aspects of
the system cause you problems? The usual answer is: hell yes! That's what
device drivers are for: they protect what you're doing and protect other
aspects of the system from you, they permit proper inturrupt handling
and context changes, which are absolutly critical in most cases, and in
most cases they also help with allocation of memory that's not swapped
out, or otherwise disturbed. And, there can be other benefits, such as
process priority, depending on the system...
...It sounds like you're working for a hardware vendor. It sounds like you
don't care about concurrency issues and so forth because you have a
specific, "canned" application. Well, I gotta "remind you" - as perhaps
you've not been around long enough to have learned it the first time: "The
year 2000 bug" (remember that?) was all about ancient code that hung
around so long and had never been rewritten when "management had allowed
sloppy coding practices" and never anticipated the longevity code. My
point to you is: Get a clue and do it right the first time. That way your
code _can_ be around twenty or more years like some of mine... If you
avoid doing it right when you know what the right thing to do is, usually
you're headed for pain later on. The only difference is whether you care
or not. Either that, or it's the mark of incompetence, obviously something
_I_ can't know in this case, but _you_ should.
Best of luck,
Richard
--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@xxxxxxxxxxxxxxxx, 510-567-9957, http://ScienceTools.com/
_______________________________________________
Redhat-devel-list mailing list
Redhat-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/redhat-devel-list
