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;
}
> > 6) Separate out those elements which are only used if the inode is open
> > into a separate data structure (call it "struct inode_state" for
> > the sake of argument):
> >
> > i_flock, i_mapping, i_data, i_dnotify_mask, i_dnotify,
> > inotify_watches, inotify_sem, i_state, dirtied_when,
> > i_size_seqcount, i_mutex, i_alloc_sem
> >
>
> It is not safe e.g. for ->i_mutex, since that puppy is used not only when
> there's an opened file over this inode (or, in fact, before any method
> had been called for this inode).
>
> It is _certainly_ not safe for ->i_state (take a look at fs/inode.c).
>
> It is not safe for ->i_data, unless you are willing to dispose of page
> cache on close (even leaving aside such things as directories).
>
> No comments on idiotify fields - IIRC, they can also be used before any
> ->open() on the inode in question.
You're right, I added some fields which can't be moved out of struct
inode, but the basic point remains; it should be possible to shrink
struct inode by moving fields to an inode_state structure.
As far as i/dnotify fields are concerned, yes, they can be used on an
unopened inode, but we could also simply consider a file that is being
watched by i/dnotify as one that is "opened" from the point of view of
needing a inode_state structure to be allocated. Depending on how
many files a typical GUI desktop is going to watch, this might or
might not be good idea.
Regards,
- Ted
-
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]
