On Aug 5,  4:46pm, Chris G. Demetriou wrote:
> Subject: Re: mmap() of device
> > I need to map some physical pages controlled by a device driver into user
> > space. The obvious way to do this is to use the mmap entry point, however I
> > need to be able to forcibly change this mapping (to a different area of
memory)
> > from the driver at a later time. The mmap interface does not seem to be
> > flexible enough to achieve this so I guess I am going to have to use an
ioctl.
> >
> > Any comments/suggestions?
>
> The first thing that comes to mind is the old standby: Why do you
> think you want to do this?
>
> Other ports have used ioctls which map device space in the past, and
> over time they've only caused problems.  What is your so-special
> application that it needs to change user mappings under their noses?

What I want is to take a device which can be mmapped into userland and appears
as a chunk of memory and split it into multiple virtual devices. I have several
devices in mind but take for example a virtual terminal driver (as that is
something most people are familiar with - another example is a removable
non-volatile memory card). The important thing here is that a userland process
should not be able to read/write the wrong virtual device (ie the wrong virtual
terminal or memory card). This requires changing the mapping to something more
suitable when the status of the device changes (mapping backing-store for a
virtual terminal when the terminal is switched or removing read/write access
for the memory card when the memory card is removed).


Anyway, the sort of thing I was thinking about was:

mmap ioctl():

- add process to list of processes allowed to use the mmap interface to the
device

- call syscall_mmap() to do mapping (using a call to the device's mmap
entry-point).

- remove process from the access list.

- return the address of the mapping (keeping a copy).

interrupt:

- do interrupt pre-processing

- post a 1-tick timeout

timeout (or memory card eject ioctl):

- change mapping (need to check whether the current mmap interface needs
curproc)

- do other necessary processing

If you know of any problems I am likely to run into doing this I'd be glad to
hear them. The other way of doing it that I can think of is to write a new MI
pager to handle this sort of thing in a generalised way (it might be possible
to just extend the device pager to add a few extra control hooks).

Cheers

Rob