This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1000538] add a d_type field to struct dirent in fileio


http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000538





--- Comment #9 from yxinghua <eCos@sunnorth.com.cn>  2008-04-09 04:10:41 ---
(In reply to comment #6)
(In reply to comment #8)
Thanks for the new patch.
What I want to discuss here is mainly concerned with the ideas of Nick. One of
my colleague and me discuss for a long time, we both think that maybe the best
method is to add another cdl option, and this cdl option is active if
CYGPKG_FILEIO_DIRENT_DTYPE is enabled. The purpose of using this new cdl option
is to control whether a filesystem's xxx_fo_dirread function should set d_type
to an entry's mode(i.e. a file or a directory) or should set d_type to
zero(means "unknow"), so that the users of the certain filesystem could be able
to balance the cost between return a d_type and calling stat. 
If this thought was correct, then there are two ways to implement this method.
One is to set this cdl option in fileio(suppose to be
CYGPKG_FILEIO_RET_DIRENT_DTYPE), however, it affects all the filesystem. As a
result of fileio's global option CYGPKG_FILEIO_RET_DIRENT_DTYPE, all the
filesystem will need to set d_type to proper mode or set d_type to zero at the
same time. It seems not so good.
The other method is to set the cdl option for each filesystem(i.e. fatfs,
jffs2, ram, rom, suppose to be CYGPKG_FS_XXX_RET_DIRENT_DTYPE), then each
single filesystem could be able to select. If this cdl option
CYGPKG_FS_XXX_RET_DIRENT_DTYPE is enabled, then the filesystem itself tries to
set d_type, otherwise, it sets the d_type to zero and stat function should be
called to get the entry's mode. We both agree that this is a better method but
we are not sure whether we are totally right? 

By the way, Andrew is right, former patch for jffs does have erros, and I will
correct the errors. As follow
#ifdef CYGPKG_FILEIO_DIRENT_DTYPE
        mode_t *ntype = &ent->d_type;
#endif
        ...
#ifdef CYGPKG_FILEIO_DIRENT_DTYPE

        struct _inode *c_ino;
        c_ino = ilookup(inode->i_sb, fd->ino);  // here use ilookup to find the
entry's node structure, is it ok?
        if(NULL != c_ino)
            *ntype = c_ino->i_mode;
        else
            *ntype = 0;
#endif
        filldir(nbuf, nlen, fd->name, strlen((char *)fd->name));
        goto out_sem;
and this has been tested for smdk2410. However, ilookup need to search each
inode, and it costs. But it may argue that cost of comparing inode is less than
comparing string which is used by stat, right? We want to do the same thing to
ram & rom filesystem but we havent't started yet.

Then add the cdl option described as above.
        ...
#ifdef CYGPKG_FILEIO_DIRENT_DTYPE
#ifdef CYGPKG_FS_XXX_RET_DIRENT_DTYPE
        //*ntype = (mode_t)fd->type;
        struct _inode *c_ino;
        c_ino = ilookup(inode->i_sb, fd->ino);  // here use ilookup to find the
entry's node structure
        if(NULL != c_ino)
            *ntype = c_ino->i_mode;
        else
            *ntype = 0;
#else
        *ntype = 0;
#endif
#endif
        filldir(nbuf, nlen, fd->name, strlen((char *)fd->name));
        goto out_sem;

Should we submit another patch?


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]