Garrett D'Amore wrote:
On Mon, 2010-07-12 at 22:58 +0100, J. J. Farrell wrote:
The mmap(2) system call has an 'offset' parameter which appears to be
passed into the driver's segmap() entry point and hence to its devmap()
entry point. Does the system itself interpret this value or use it in
any way when the request is directed to a driver, or is it left to the
driver to interpret as it pleases? The documentation for mmap(2) says
this parameter must be a multiple of page size.
I'm wondering if this parameter can effectively be used as a command to
the driver to indicate which resource should be mapped. Consider a
driver which wants to map out different parts of its memory for
different purposes, or which controls multiple register sets which it
wants to map out individually. Can a driver define a contract such as:
- 'offset = 0' requests a shared memory block
- 'offset = pagesize' requests the 'frooble' registers
- 'offset = pagesize * 2' requests the 'wibble' registers
and so on?
This usage sounds quite reasonable to me.
Suppose in this example the 'frooble' register set were bigger than
pagesize. If it's purely up to the driver to interpret this parameter
that should cause no problem; but if the system interprets it I could
imagine confusion about its overlapping 'wibble'.
I believe the driver is free to apply your interpretation. However, I'd
have to check the source to be 100% correct. But of course, you can do
that as well... the browseable/searchable source is at
src.opensolaris.org. :-)
I *think* the system *may* assume that your addresses are page aligned
and whole chunks of pages. If a userland process asks for a mapping
that is not so aligned, then there might be some confusion. But I see
no reason why you could not have three regions, say separated by 1MB of
virtual address space, for these three different purposes.
- Garrett
Thanks Garrett, greatly appreciated as ever. I'll use this
conservatively to avoid risk of problems; "magic numbers" for the offset
parameter will be multiples of pagesize, and none will be defined within
areas between another magic number and the size of its associated region.
Digging in the source can lead to answers about the current
implementation rather than the architectural intent and guarantees; if
there's someone around with the knowledge and willingness to share it,
that can be safer. I'll certainly do my own digging if necessary, though
pointers in the right direction can be helpful then ;).
Many thanks for your time.
Regards,
jjf
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
