Writing data in a linux driver, with an additional parameter

I am not really familiar with driver deve开发者_如何学运维lopment, but I have to perform a simple driver adaptation and I am not sure about the way to go. I am not looking for detailed explanations (that I can check up in a book), but more about what are the "best practices" that show me the starting point of my knowledge gathering.

The problem is the following:

Initially, we had a very simple char driver performing this operation:

User       "write"         driver copies
Space ==== packets  =====> the data
Code       to open fd      from user space
           of the driver   and passes it to 
                           a hw controller

The simple adaptation to perform is that, now, the hw controller needs an additional numeric tag to identify the type of packet. Normally, this tag should be specified together with every written packet.

What is more sensible to do?

• create a separated ioctl call to provide this tag, and then perform the "write" call of the real packet data (and then use "ioctl" and "write" in user space).
• create an ioctl call to pass simultaneously the tag and the packet data (and then use this "ioctl" call in user space)
• create an additional structure (shared between user space and driver), containing the tag and the pointer to the buffer, and then "write" this structure in user space (thus, copying twice from user space: one for the struct and a second one for the packet data).
• ...?

Any hint/comment/suggestion is more than welcome.

---

The first and third options are practicably the same performance wise (two calls into kernel and back) but using write is prettier then ioctl.

The second option save you a context switch into the kernel and back, but is ugly.

I would define a structure with a first byte of packet type and rest a buffer with packet data but will user writev() rather then write() to send it to the kernel.

Not only does it saves you the extra context switch, it actually allows you to send several packets (and their types) in a single call to kernel, if available.

Some would say there is no difference between my suggestion and your second one. Perhaps they are right :-)