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
>
> Confirmation/correction/clarification would be very welcome.
>
> Many Thanks,
> jjf
> _______________________________________________
> driver-discuss mailing list
> driver-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
