Hi,
I'm a member of the ALSA (Advanced Linux Sound Architecture)
professional team and I feel strong the need to discuss with
linux-kernel people an important problem concerning our drivers and
library.
To achieve the best performance and low latency possible (that you all
know perfectly how is important for multimedia application) we need to
read/write some kernel memory without entering the kernel and without
doing additional copies. In this way the application can (in most case)
read or write directly the memory written/read by audio card.
The natural solution that we've thought was to use mmap syscall (as OSS
does, and probably other char devices that need this).
mmap has all the feature we required:
- it's born for efficiency needs
- may be file descriptor related (as we need)
- may be differentiated with offset parameter for mapping different
things (take in account that an audio device has two buffer, one for
playback and one for capture)
Nevertheless mmap is *almost* what we need:
- when we mmap a file opened O_RDWR or O_WRONLY the application can read
and write to the area (if it asks so) and this is ok.
- when we mmap a file opened O_RDONLY the application can only read from
the area and here we have the problem.
A common (and AFAIK needed) trick used reading from an audio device is
to mark the buffer with a special pattern before the hardware fill it,
so to be aware of the work done when this is overwritten.
But if we cannot write to this area this become impossible.
The solution used by some OSS application is to open the file always
O_RDWR to be able to do the trick. This is IMO dirty and misleading as
we don't have any intention to write to the device (and opening in that
way it's impossible to use the same device for playback).
Current solution used in ALSA imply the open always with O_RDWR and the
abuse of flags parameter of open(2) to notify our real intention to
driver (using unused bits). We acknowledge that this solution is dirtier
than the other and we want to throw away it.
We have asked to Andrea and Alan some help and I resume the results:
- Alan propose to use different minor number for every possible
direction (O_RDWR, O_RDONLY, O_WRONLY) and to open always in O_RDWR.
We think that this bring to an excessive proliferation of device (take
in account that professional hardware has *many* audio channel) and that
the misleading open remain.
- Andrea propose to not ask in the mmap call for any or low right
(PROT_NONE or PROT_READ) and to achieve the needed right in f_ops->mmap
function in the device driver. The file now can be opened specifying the
wanted direction.
We think that this solution, also if does not require any kernel
changes, is very dirty and it works now but in future (if mmap
implementation changes) who know...
So, these solutions appears to us not convincing and we believe that
this problem worths a widen discussion.
Now, seen that this feature (use of mmap with char devices to achieve
very good performance) will be very useful for many device driver in
future (not only ALSA), we ask:
Sounds it unreasonable to extend slightly mmap semantics (the solutions
can be many: add a MAP_something flag, delegate the vma constraints to a
lower level, etc.) in a *clean* way, so to avoid dirty tricks in user or
kernel space?
This has already happened in the past (the adding of Linux MAP_other to
POSIX valid flags by example).
Another clean solution would be to add another syscall (or to use an
apposite ioctl in our drivers), but we strongly feel that to add code
that differ by mmap by a few lines it's a nonsense (also without taking
in account exported symbol problem).
Semantics for regular file would remain unaltered (as we understand
perfectly that to write to a shared read only true buffer is a
blasphemy).
We'll appreciate any comments, we don't ask anything better than you
educate us to do the *clean* thing.
-- Abramo Bagnara mailto:abramo@alsa-project.orgOpera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project is http://www.alsa-project.org sponsored by SuSE Linux http://www.suse.com
It sounds good!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/