Driver duplicate?

[Kenneth Adam Miller]

Actually, I just realized that there is probably a way to look up the
character device name with the file* that is passed in with the mmap call.
Can anybody say how?

On Mon, Mar 7, 2016 at 3:00 PM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> I have a driver that manages three sets of identical data structures that
> differ only in address values. Currently, I pray that the device file to
> which I have callbacks mapped for the driver gets called sequentially,
> because there are pairs of mmap's that need to be made. I know that this
> isn't the most ideal way to do it, so I'm searching for a better way rather
> than to swap out the values on each method call.
>
> There are several things I am aware of but for each one I have questions:
> 1) there are kernel module parameters
> If I use kernel module parameters, I need to be able to insert the kernel
> module three times in order to have each one have a distinct set of global
> memory and mapped callbacks to distinct files. Can that be done? Second, I
> will need to compile the driver statically later. How can I pass those
> parameters that would otherwise be on the command line in statically?
>
> 2) I can compile the driver in three times with a compile time flag. This
> is the simplest and easiest, but it requires some buildroot and makefile
> foo that I think is a dirty hack.
>
> 3) I could have the init function create three separate files, since it is
> on init that I discover what my values are. But then I have to also
> associate identical functions that reference global variables in the kernel
> object. Duplicating the code would be worse that compiling the same code
> three times with a kernel parameter, even though that would help me solve
> my distinct globals problem. So how could I parameterisze a char device
> with data specific to the instance?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160307/c7d7cf94/attachment.html