Theodore Tso wrote at lkml:
[saving space in the numerously instantiated struct inode]
On Sat, Jun 10, 2006 at 02:27:57AM +0100, Al Viro wrote:
5) Nuke i_cindex. This is only used by ieee1394's
ieee_file_to_instance. There must be another place where we can
store this --- say, in a ieee1394-specific field in struct file? Or
maybe it can be derived some other way, but to chew up 4 bytes in
i_cindex for all inodes just for ieee1394's benefit seems like the
Wrong Thing(tm).
No, it's actually the right thing for _all_ char devices. And it's used
before we get a struct file. If anything, ->i_rdev should go long-term...
i_cindex is set by fs/char_dev.h, and the only user of that field (I
grepped the entire sources) is ./drivers/ieee1394/ieee1394_core.h:
/* return the index (within a minor number block) of a file */
static inline unsigned char ieee1394_file_to_instance(struct file *file)
{
return file->f_dentry->d_inode->i_cindex;
}
...
Also, the places where ieee1394_file_to_instance() is used appear not to
be fast paths. (It's the struct file_operations.open() hook of two
protocol drivers.) I.e. there is no harm in replacing it by whatever
more expensive lookup method.
Dv1394 calls ieee1394_file_to_instance() from within spin_lock_irqsave()
/unlock_irqrestore(), but it can easily moved out of it if need be.
--
Stefan Richter
-=====-=-==- -==- -=-=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
