[uClinux-dev] problems writing a driver

NZG ngustavson at emacinc.com
Tue Jan 31 10:17:14 EST 2006


> I don't agree.
> It does at least maintain a list of used addresses. The caller therefore
> gets informed if he wants to use an address already in use.
A kernel call that requests the same memory region will notify you, but if the 
memory space is just dereferenced (or modified with an assembly instruction) 
on an MMUless system without a system call, will it catch that? 

> And, more, importand,  I wouldn't care about the limitations of uClinux.
> May driver should run without changes on every Linux incarnation.
I see the point your trying to make, that there is still an advantage to using 
request_mem region. I agree with that.
But the question was specifically asking if he could implement some form of 
memory protection on a 5272, which can only run MMUless Linux and doesn't 
have any kind of hardware memory protection, so I don't see how it's 
possible.

> And more to the point using request_mem_region() even on a VM
> system doesn't preclude others from using a region. 
> Any other driver
> can still ioremap a region and access it - if they choose not to
> use request_mem_region(), or ignore what it reports.
I was not aware of that, but I suppose it makes sense, if you going to allow 
people to load strange drivers on your system, security is pretty much out 
the window. 

Also some things to note, are that, yes, you could get around a memory mapping 
with a ioremap in a driver on a VM system, but on an MMUless system you don't 
need the ioremap at all, and in fact could get to the memory directly from 
user space. 

The only thing request_mem_region is going to do is make a note of what was 
allocated that you can read out of proc and report to you a problem if you 
try to use request_mem_region to access it again.

Technically it is correct to use it for portability reasons, but I don't see 
what advantage it is really offering you in this situation.

NZG




More information about the uClinux-dev mailing list