[lkml]   [2006]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 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
-=====-=-==- -==- -=-=-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-10 08:30    [W:0.043 / U:4.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site