allow mmap()ing devices

[pulkomandy]

This is a feature of Linux (and likely other POSIX OS, even if it's not part of POSIX itself). mmap()ing a disk device gets you read and write access to the sectors. On linux, you can also mmap() the framebuffer device to draw on the screen. There are other uses for this, likely.

I can see that with the current device drivers, this is not possible. We likely need to change the device API, unless the mmap'ed area can be filled in with regular read and flushed with regular write calls (possibly with some caching).

Thoughts ?

[bonefish]

Mapping the frame buffer is a bit of a special case. It really is physical memory and there are already interfaces to map it into an application address space (BWindowScreen/BDirectWindow). It probably wouldn't be hard to map it also via mmap(), but I don't really see the point.

Regarding disk devices, that is more interesting (and involved) and has already been discussed, though from a different angle. One problem Haiku's kernel currently has is the block cache. It uses the slab to store block data, which uses (virtual) kernel address space. Kernel address space, however, is relatively limited on a 32 bit system. Moreover, using the slab while the file cache uses physical memory causes an imbalance in favor of the block cache.

What has been discussed is a unification of the cache architecture. Like the file cache, the block cache would use physical memory directly (organized in a VMCache object). This would also allow to easily layer caches, since VMCache already supports such a mechanism. So one could have a cache for the whole device and caches on top of it for the partitions which would replace the current block caches. The device cache would be located at the I/O scheduler level -- either integrated or on top of it (in fact for CDs/DVDs a similar thing does already exist: IOCache, a special IOScheduler, already uses a VMCache to cache the disk contents).

As a side effect the devices (and partitions) can easily be made mmap()able. The reason is that an area just maps a VMCache to an address range in some address space.

Long story short, this is all very nice and desirable. Unfortunately it is also quite a bit of work and has several details that need to be worked out. Like how to implement transaction support (which the block cache requires), how to deal with block size != page size, etc. It would probably be a good idea to kick start such a development during a coding sprint, so that two or three people can work on it together.