Subject: Re: mmap() of device
To: Robert Black <firstname.lastname@example.org>
From: Stefan Grefen <email@example.com>
Date: 08/07/1997 10:20:17
In message <9708061302.ZM13207@picasso.me.ic.ac.uk> "Robert Black" wrote:
> 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).
I've a usefull application for this too (mapping a buffers into userspace, beats a
copy anyday ...)
> Anyway, the sort of thing I was thinking about was:
> mmap ioctl():
[...] ioctl interface delted
> 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).
Just invalidate the page(s) and the next page-fault will call mmap again and you
can supply a different page. I just haven't checked how well the mmap interface
would handle a invalid page here ....
There maybe some gotchas there, but i think this will be the most stable and portable
approach. (over revisions and architectures)
Stefan Grefen Tandem Computers Europe Inc.
firstname.lastname@example.org High Performance Research Center
If a group of N persons implements a COBOL compiler, there will be N-1
passes. Someone in the group has to be the manager.
-- T. Cheatham