Constrained file descriptors

Johannes Kliemann kliemann at ...543...
Fri Jan 5 10:09:42 CET 2018


Hi Norman,

> As another principle idea - at least for handing out MMIO mappings for
> PCI resources, you may have a look at the pseudo files under
> /sys/devices. Here you can find all memory-mapped PCI resources as
> files, which could be mapped in user space via 'mmap'. E.g., the
> following command lists the available resources (with their file size
> corresponding to the information given by 'lspci -v'):
> 
>   ls -l `find /sys/devices/pci0000\:00 -name "resource*"`
> 
> However, this approach has some caveats:
> 
> * Core's IO_MEM service hands out resources based on their physical
>   address. You would need to search /sys/devices for the matching PCI
>   resource.
> 
> * A user-level device driver may request just a window of a PCI
>   resource. So the dataspace handed out by core would need to carry the
>   information about its offset from the beginning of the underlying
> file. We are somehow back at the start of the discussion. :-/
> 
> * It only works for the (arguably most prominent) case of PCI
>   resources but not for other mappings. I am in particular thinking
>   of the mapping of the PCI config space, which we will need to
>   run the platform driver once the issue "RFC platform_drv/x86:
>   Switch to ECAM/MMCONF" [1] is closed. I guess that we would need
>   to have a Linux-specific platform driver then.
> 
> [1] https://github.com/genodelabs/genode/pull/2547
> 
> That said, in my opinion the tinkering with the files at /sys/ is not
> very attractive. If you are prepared to develop a generic kernel module
> for solving this problem at a lower level (and allowing us to reuse our
> existing platform driver on Linux), this should be the way to go.

We also thought about these options and came to the same conclusions.
Furthermore sysfs is something we probably want to remove in the future
so we don't want to depend on it anyway. Also at the implementation of
interrupts we will need a kernel module/patch anyway since we didn't
find any way to get them into the userspace (except polling
/proc/interrupts which is a really bad hack).

About the specific PCI memory spaces, as far as I know PCI is mainly
available on X86. Since the use of the Linux kernel is intended for
exotic platforms without a supported micro kernel (on X86 we can stay
with NOVA) where PCI most probably isn't available we definitely want to
create a generic solution to access MMIO space.

Thanks for your thoughts and regards,
Johannes




More information about the users mailing list