Alexander:
Thanks for this little discussion. It turns out that the inode does not really give
me what I want anyway. What I want is for my driver to allocate instance structures
keyed to the major/minor of the device (character driver). I notice that if I do
mknode deva c 100 1; mknode devb c 100 1 that deva and devb get unique inode
numbers. I assume that if a program opened deva and devb that the driver's open
routine would see two distinct inode structures. In that case I still want just one
instance structure pointed to by both files.
Conclusion: I will use the file->private_data and resolve the uniqueness at file
open time.
I had overlooked this fine point for quite some time (years), and our little
discussion has cleared it up for me.
Thanks,
Dave
Alexander Viro wrote:
> On Tue, 11 Jan 2000, David Grothe wrote:
>
> > Alexander Viro wrote:
> >
> > > _All_ ->u is off-limits for any device code. It
> > > belongs to hosting filesystem and to nobody else.
> >
> > If a driver needs to have a private structure that associates with each "real"
> > file (inode instance) then what is the recommended technique? Private hash
> > table on major/minor? What is the officially recommended technique here.
> >
> > I obviously misunderstood that the generic_ip was like a private structure
> > pointer in a number of other kernel control structures, such as net_device.
>
> Hold on. Inode is not a good thing here - if (_big_ if) you need per-file
> data - refer to it from struct file (that is, if you really need it on
> per-opener basis; _very_ rare situation). If you need it on per-device -
> keep it in the driver. Inode gives either too coarse or too fine
> granularity here - there may be a lot of independent openers of inode and
> there may be many inodes pointing to your device. In effect, device inode
> acts as a sort of symlink - just that it points into other namespace.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:20 EST