Hi Genodians
I'm trying to use a Terminal session to provide access to a character device (TPM) under base-linux. The reason I'm not using a vfs it that implementing a File_system session server in my lx_chardev component would be unnessecarily complicated for this usage.
The problem I encountered it that the vfs_terminal even in raw mode buffers read data thereby issuing longer reads than requested by the application. While this is fine for other more terminal-like usages it doesn't play well inbetween a character device and it's driver.
I would suggest either not buffering reads in raw mode or adding an additional "unbuffered" config option. Which would be the preferred option? Whould such a change have the potential to be accepted upstream?
Kind regards Stefan
Hello Stefan,
On Wed, Dec 04, 2024 at 11:01:48 CET, Stefan Thöni via users wrote:
I'm trying to use a Terminal session to provide access to a character device (TPM) under base-linux. The reason I'm not using a vfs it that implementing a File_system session server in my lx_chardev component would be unnessecarily complicated for this usage.
The Terminal session (as well as the Connection and Client objects) indeed support your use case of character-exact (resp. unbuffered) operation mode.
The problem I encountered it that the vfs_terminal even in raw mode buffers read data thereby issuing longer reads than requested by the application. While this is fine for other more terminal-like usages it doesn't play well inbetween a character device and it's driver.
Admittedly, the vfs_terminal ont the other does not address the requirements of your operation as it completely decouples reading into the buffer (incl. read-avail signal handling) from the VFS API for read(). I'd expect your desired adaption of the implementation would be more like driving a wedge into all functions with 'if (unbufferd)' clauses all over the code.
I would suggest either not buffering reads in raw mode or adding an additional "unbuffered" config option. Which would be the preferred option? Whould such a change have the potential to be accepted upstream?
From my current understanding of the vfs_terminal plugin, I'd suggest to start with a dedicated vfs_chardev implementation for your specific use case and check for similarities to vfs_terminal later.
Regards