Andi Kleen <[email protected]> writes:
>> Well the other alternative looks like having a second file per par
>> bar. Say resource0_wc to support the write-combining mode, possibly
>
> The intention was to support memory not in bars, but give a generic
> IOMMU mapped memory interface for user space e.g. for the X server.
> But that needs a way to return the bus address for the mmap mapping
> and ioctl was the best I came up with for that.
> Given it was never finished.
Ok that part wasn't obvious. The only thing we mmap in sysfs today
are the bars.
Taking normal memory and iommu mapping it to a device and then having
a user space accessible version is a bit different. We need a special
interface to allocate it and map it through the iommu to user space.
This needs to be a driver or a support subsystem like DRM. Once
we have gone that far then we can map those address to user space.
I expect from the sysfs perspective those per device regions should look
a lot like bars showing contiguous chunks of memory RAM from the devices
perspective. At which point having two files instead of just one can
solve the problem without an ioctl.
For contiguous to device memory we also have some permission issues
so I'm not yet certain that it make sense to expose it through sysfs.
Regardless that seems to be solving a completely new aspect of the problem,
and we can solve that problem separately.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
