lkml.org 
[lkml]   [2006]   [Jun]   [10]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 10 Jun 2006 08:24:43 +0200
FromStefan Richter <>
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 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/
\
 
 \ /
  Last update: 2006-06-10 08:30    [from the cache]
©2003-2008