Accessing a block-device from kernel-mode

Why do you think you need to do this in Kernel mode in your driver itself ?

IMHO the better way is to do a driver that accesses your propriety hardware (supposedly that is why you need to do a driver at all) and do the rest in a user mode program that is going to run in a realtime priority and thus is scheduled before all other user programs (with no less priority than a kernel module). Remember that even the GUI "driver" (Xfree) is running in user mode.

Debugging in user mode is _much_ easier !

Another problem I see is scheduling the access between your low level disk access and the file system's activity. You can very easily destroy the file system on the disk when this is not done correctly. (I have no idea how it can be done.)

-Michael

Performance was my main concern.

Could be a good option, but I'm afraid it will be slow because of all the extra data transfers between kernel- and user-space and back that this may require. (But maybe I can find a way to leave the data in kernel-space, and still pass it on to the higher HDD-driver levels, using some mmap code..)

Thanks for the suggestion!

In my system this will be no problem. There will be no concurrent access. So 'all' I have to do is a flush of all data and lock the disk (umount should do fine) for my driver for, indeed, my propriety hardware.

Regards,

Armin

I don't think that doing it in the Kernel helps regarding performance. There once was a Kernel mode webserver. The project was abandoned because a user mode webserver outperformed it.

Moving many small blocks of data between user and kernel mode might be noticeably slow. I don't think that it harms for big blocks. I think, the standard method really _copies_ the data between kernel and user space. For high performance with large blocks I'm sure that there is a method to do the appropriate memory mapping using the MMU, but I did not look into this.

That would be having the Kernel use the MMU to map it into user space. Maybe the easiest way is to allocate the memory in user space, use the standard file API do inform the kernel driver about the user mode address and use some API to find out the kernel mode address. Of course there could be multiple kernel-mode fragments in a user mode memory block. I seem to remember that Linux v2.6 provides some new means to prevent it. In earlier versions there is a method to allocate a contiguous block when starting the system.

-Michael

I did some checking. Since the data-transfers will be large, copying is no option.

However, by using the raw-interface I should be able to access the block-device as a raw-device. Since kernel 2.4.x, one can finally mmap raw-devices, so it should then be possible to have an application mmap both the raw-device as my own, and do a straight copy (although alligned at certain boundaries).

That should do fine.

Thanks for the hints. I'll look into them.

Regards,

Armin

I would be happy having prevented you from going into too much Kernel mode debugging hassle. If you need to nonetheless: I just learned that v2.6 offers an easy way to start a second kernel in user mode. This is supposed to simplify Kernel debugging greatly.

Another goody of 2.6 might be a new feature of the block device driver that allows queuing accesses and not force the caller to wait for the access to be completed.

Please let me know what you find. Some time ago I started a research on using a large area of RAM in Kernel- and in user- mode (to write the data in user-mode and to do bus-master DMA in a Kernel-mode driver to move data out to some propriety hardware). I stopped the research as soon as I found it _is_ possible, as the project is delayed for other reasons. But I think I'm going to start with that again later this year using Kernel 2.6.

-Michael