Driver duplicate?

[Kenneth Adam Miller]

On Mon, Mar 7, 2016 at 3:29 PM, Greg KH <greg at kroah.com> wrote:

> On Mon, Mar 07, 2016 at 03:21:44PM -0500, Kenneth Adam Miller wrote:
> >
> >
> > On Mon, Mar 7, 2016 at 3:17 PM, Greg KH <greg at kroah.com> wrote:
> >
> >     On Mon, Mar 07, 2016 at 03:00:50PM -0500, Kenneth Adam Miller 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?
> >
> >     Never use kernel module parameters for a driver, nor for any other
> >     kernel module you create.  They are global and don't work for
> >     device-specific issues.
> >
> >     > 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.
> >
> >     It's also never accepted, don't do that.
> >
> >     > 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?
> >
> >     open() gives you the hook to do so, please just do that.  There's a
> >     whole kernel tree full of examples of how to do this, take a look at
> >     existing code please.
> >
> >
> > After I had the idea in the second email, I think that using the kernel
> api to
> > distinguish which char device a callback maps to in order to utilize the
> > corresponding data is the best way.
> >
> > If I could do something along the lines of retrieving the file name, as
> in a
> > char *,
>
> There is no such "thing" in the kernel (think of symlinks, or different
> names for the same major:minor pair).
>
> > from the file * that is passed in with the callback, or distinguish any
> > one of these:
> >
> > static dev_t LSKSMM_dev;
> > static struct cdev LSKSMM_cdev;
> > static struct class *LSKSMM_class;
> > static struct device *LSKSMM_device;
>
> Those are all different things, none of them get passed into open().
>
> I don't think you have thought this through very far, where is your
> source code to take a look at it?
>
> > which are also created on module init, it would really make things
> convenient
> > and easy. I'm currently digging around in the kernel headers, but I think
> > probably somebody somewhere knows what I'm looking for. Some unique
> field that
> > I can retain on init that I can get back in my mmap/ioctl call to
> recognize
> > what data to use.
>
> Again, it's all provided directly to you in your open() call, what's
> wrong with that?
>

Currently, my kernel driver is opened twice and mmap'd twice by each
process. I have three processes, but I have to initialize them on startup
with a startup script. So they come up as daemons, racing, which is a
problem. I know that on init I can create three entries in /dev/,
distinguished by a number or something that makes the device unique. When a
mmap call hits is when I need to know what specific file that the mmap
corresponds to. I have to identify it associatively by name or by the
identifiers that the kernel consumes for it's internal class and/or device
entry. I don't know that I could do that with what I'm given in open,
because while I'm sure that provides some information, it doesn't provide
the the information when I need it. I don't have anything in my open
callback except a printk. My mmap does all the work, and has to distinguish
the right private item to use with what device file.

I don't know the layout of the structure or the api so well that I could do
that off the top of my head.


>
> thanks,
>
> greg k-h
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160307/d95c74b1/attachment.html