The driver structure is contained in the struct file (filep->struct
file->inode->u.file_operations. The operation of many file systems,
drivers, etc. depend on the additional in these other structures.
The driver interface is given by file_operations. Notice that each
method requires an instance of struct file as the "this" pointer to
allow driver access to the whole operating context.
Please don't do anything differently. Consistency is a virtue; creative
inconsistency is destructive to the integrity of the OS. Please do not
go the naive way that you are considering. That kind of change would
certainly be rejected (I hope).
On 10/1/2024 7:33 AM, Matteo Golin wrote:
Thank you for the help everyone! I have some follow-up questions:
You should use the struct file instance to access the driver, not the raw
driver interface.
Greg, can you clarify what you mean? My understanding is that it would be
preferred that I use `file_open()` to get the
struct file instance to access the driver this way, instead of doing something
like this example of an I2C device driver
startup that gets the raw driver interface:
https://github.com/apache/nuttx/blob/master/boards/arm/rp2040/common/src/rp2040_bmp280.c#L90
To clarify, I was not suggesting that the LoRa driver contain any architecture
specific code; I would like to be generic
over a serial interface. The pattern that I am familiar with from my knowledge
of sensor drivers on NuttX is that the
device's `register` function takes a reference to the underlying interface
driver (I2C, SPI, etc.). However, that
reference comes from somewhere.
For the RP2040, the reference is obtained like in link above. This method of
obtaining a reference to the I2C driver
does not register it as part of the path name space, it returns the struct
reference only. I was not able to find an
analogous function for UART interface drivers on any platform except the STM32
example I gave in my previous email. The
`file_open` call works, but if I'm understanding correctly, requires first that
the UART interface be registered in the
pathname space.
I am mainly wondering, if I implement this driver as generic over a UART
interface (`uart_dev_s`) like how sensor
drivers are generic over an I2C/SPI interface, would it be permissible to
implement something analogous to the
`rp2040_i2cbus_initialize()` but for UART interfaces on the platform startup
code where I want to initialize the driver?
And if I make the driver generic over the UART interface, is it suitable to
require the platform specific startup code
to access the underlying `uart_dev_s` struct within the file struct returned by
`file_open()` (i.e. cast what is stored
in file->f_priv)?
Thanks,
Matteo
