On Mon, Mar 07, 2016 at 03:37:24PM -0500, Kenneth Adam Miller wrote: > > > On Mon, Mar 7, 2016 at 3:29 PM, Greg KH <greg@xxxxxxxxx> 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@xxxxxxxxx> 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. Again, any pointers to your source code? > I have three processes, but I have to initialize them on startup with > a startup script. What does that have to do with the kernel code? > 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. The kernel creates the /dev/ entries, don't do it from userspace, if you expect things to work properly. > When a mmap call hits is when I need to know what specific file that > the mmap corresponds to. Again, open() is giving you this, why do you keep saying it isn't? And again, there are at least 3 different ways of determining this at open() time (5 total I think, last time I looked), each way depends on your driver structure and how your code needs to work, so I can't just say "do it this way", sorry. > 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. Why? > 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. All of the char drivers in the kernel kind of refute that excuse :) > I don't have anything in my open callback except a printk. Then fix that! > My mmap does all the work, and has to distinguish the right private > item to use with what device file. Again, set that in your open() callback, that's what it is there for! there is a whole kernel tree full of examples of how to do this, please use them for insight. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
