On 4/8/22 07:45, Sathya Prakash Veerichetty wrote:
We can submit another patchset where we will move only structures
which are used both by applications and drivers into the include/uapi
and keep the remaining ones which are not used in the app into the
older mpi3mr/mpi folder. However, I have a generic question on why
we need to move the headers into uapi because the driver provides the
transfer mechanism already in the uapi through app.h and the
information transferred in through that is blob from the driver
perspective and that goes to the controller directly and processed by
the controller, only for specific cases like NVMe encapsulated
command, to set up the DMA address the driver parse through the
command. Wouldn't it make sense to keep all of the
controller/firmware related structures along with the driver and
expose only the transport mechanism in the uapi?
Hi Sathya,
Please reply below the original email instead of above. From
https://en.wikipedia.org/wiki/Posting_style:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Regarding the question in your email: the convention in the Linux kernel
is to define data structures that are needed by user space applications
(and only those data structures) under the include/uapi directory. These
data structures are not only exported to user space apps but also used
by the kernel code that implements the user space API. This guarantees
the correctness of these header files.
I can't find the app.h header file anywhere in the kernel tree. Hence my
request to move the user space data structures and constant definitions
into a header file under the include/uapi/ directory.
Thanks,
Bart.
