This is the mail archive of the ecos-discuss@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]

Re: chmod (crops up on YAFFS)


Andrew Lunn wrote:
On Sat, Nov 15, 2008 at 04:56:56PM +0100, Rutger Hofman wrote:
Good afternoon list,

I am making good progress with YAFFS on top of the eCos NAND Flash library; I can mkdir/rmdir, opendir/readdir, rename, open/creat/unlink, read/write files, and walk the directory tree on my NAND flash chip.

Now, one thing I am unhappy about is file/directory permissions. YAFFS has permissions (user/group/other a la POSIX), but eCos has no chmod() call. In old exchanges on this list I saw this crop up on FAT, but FAT's attributes are different from (POSIX) file permissions. Some guru back then advised an implementation of chmod() that calls cyg_fs_setinfo() with a FS_INFO_CHMOD tag. But this route was not taken: I see no chmod() anywhere.

Would it be a good idea that I add chmod() to file.cxx/fileio.h that does take the above route, and implement it by having it call cyg_fs_setinfo() with a tag FS_INFO_CHMOD? My guess is that this shouldn't break the other filesystems, they would return an error code on an unknown tag FS_INFO_CHMOD.

The problem with permissions is that they require a concept of a user identity. eCos does not have this. There is no uid to know if the user owns the file. There is no group of users to know if the group permissions are valid. So how do you decide which of the ugo bits to look at?

Without a concept of ugo, how is YAFFS even using the ugo permission?
I feel that in eCos chmod() is pointless...

Yes, certainly it's correct that ugo does not make very much sense in eCos.


But:

- my aim is that YAFFS filesystems can also be approached from u-boot, uCLinux, Linux, ..., even if they are created by eCos; Linux and friends do support ugo;
- even if there is no ugo, a permissions notion might make sense. So, if the mask is 000 there is no permission at all. 777 would allow everything;
- eCos has open()/creat() with permissions. It has stat() with permissions. It has access() with permissions. Ruling out chmod() because permissions don't make sense for chmod() seems not completely consistent;
- of course I can make an fs-private flag FS_YAFFS_INFO_CHMOD and call cyg_fs_setinfo() from the application. I do not feel attracted to that in comparison with having chmod(), because it makes the fs type manifest to the application.


Rutger

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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