Messages in this thread | | | Date | Sat, 10 Jun 2006 08:24:43 +0200 | From | Stefan Richter <> | Subject | Re: [RFC] Slimming down struct inode |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |