All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Driver duplicate?
Date: Mon, 7 Mar 2016 12:29:28 -0800	[thread overview]
Message-ID: <20160307202928.GA27045@kroah.com> (raw)
In-Reply-To: <CAK7rcp-NNkH35ChOEQGHWRgAqaBHSn9svCReh-MznqK=3bDdcQ@mail.gmail.com>

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@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?

thanks,

greg k-h

  reply	other threads:[~2016-03-07 20:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07 20:00 Driver duplicate? Kenneth Adam Miller
2016-03-07 20:05 ` Kenneth Adam Miller
2016-03-07 20:15   ` Greg KH
2016-03-07 20:17 ` Greg KH
2016-03-07 20:21   ` Kenneth Adam Miller
2016-03-07 20:29     ` Greg KH [this message]
2016-03-07 20:37       ` Kenneth Adam Miller
2016-03-07 20:53         ` Greg KH
2016-03-07 21:08           ` Kenneth Adam Miller
2016-03-07 21:27             ` Greg KH
2016-03-07 21:49             ` Valdis.Kletnieks at vt.edu
2016-03-07 22:04               ` Kenneth Adam Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160307202928.GA27045@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.