* [ECOS] ROMFS in anoncvs
@ 2001-07-12 11:38 Andrew Lunn
2001-07-12 15:05 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2001-07-12 11:38 UTC (permalink / raw)
To: eCos Disuss
Hi Folks
Does the ROMFS code in anoncvs work? I think not?
It appears that the mk_romfs program uses the node.mode with what
linux returns in stat. This means the root directory i just made has
mode 042770, which is drwxrws---. But the eCos IS_DIR macro has a
different idea of what the mode should be. It expects the lower bytes
to contain the file type.
<sys/stat.h>:
#define __stat_mode_DIR (1<<0)
#define S_ISDIR(__mode) ((__mode) & __stat_mode_DIR )
Hence all open() calls fail.
Has something changed here recently? Has anyone run the test program
that comes with the romfs package.
Thanks
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [ECOS] ROMFS in anoncvs
2001-07-12 11:38 [ECOS] ROMFS in anoncvs Andrew Lunn
@ 2001-07-12 15:05 ` Gary Thomas
2001-07-13 0:14 ` Andrew Lunn
0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2001-07-12 15:05 UTC (permalink / raw)
To: Andrew Lunn; +Cc: eCos Disuss
On 12-Jul-2001 Andrew Lunn wrote:
> Hi Folks
>
> Does the ROMFS code in anoncvs work? I think not?
Absolutely! It's a big part of our iPAQ demo.
>
> It appears that the mk_romfs program uses the node.mode with what
> linux returns in stat. This means the root directory i just made has
> mode 042770, which is drwxrws---. But the eCos IS_DIR macro has a
> different idea of what the mode should be. It expects the lower bytes
> to contain the file type.
>
> <sys/stat.h>:
>
>#define __stat_mode_DIR (1<<0)
>
>#define S_ISDIR(__mode) ((__mode) & __stat_mode_DIR )
>
> Hence all open() calls fail.
A little harsh; perhaps open() calls for nested paths fail.
It does look like you are correct about the mode stuff.
>
> Has something changed here recently? Has anyone run the test program
> that comes with the romfs package.
Actually I never ran it since it can't really be run stand-alone (you need
to build an adequate ROMfs separately and have it installed).
This particular package was contributed and while it does work, at least
for the limited uses we've tried, it may have errors in it. The two things
I see to be done are:
* Change 'mk_romfs' to perform some mapping from the host file system modes
to those used by eCos.
* Improve the test program so that it can be run automatically, thus allowing
it to be tested more thoroughly by our test farm.
At this time, I can't say when the eCos team might have time/resources available
to make these improvements.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ROMFS in anoncvs
2001-07-12 15:05 ` Gary Thomas
@ 2001-07-13 0:14 ` Andrew Lunn
2001-07-13 2:55 ` Richard Panton
2001-07-13 4:32 ` Gary Thomas
0 siblings, 2 replies; 6+ messages in thread
From: Andrew Lunn @ 2001-07-13 0:14 UTC (permalink / raw)
To: Gary Thomas; +Cc: Andrew Lunn, eCos Disuss
On Thu, Jul 12, 2001 at 04:05:23PM -0600, Gary Thomas wrote:
> A little harsh; perhaps open() calls for nested paths fail.
>
> It does look like you are correct about the mode stuff.
The filesystems root directory, is not a directory, and so it fails
imeadiatly with my test program.
> The two things
> I see to be done are:
> * Change 'mk_romfs' to perform some mapping from the host file system modes
> to those used by eCos.
I sent a patch to Jifl last night.
> * Improve the test program so that it can be run automatically, thus
> allowing it to be tested more thoroughly by our test farm.
I've got some test code embedded in a synthetic application. I will
try to hack it into a standalone test.
Thanks
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ROMFS in anoncvs
2001-07-13 0:14 ` Andrew Lunn
@ 2001-07-13 2:55 ` Richard Panton
2001-07-13 13:38 ` Jonathan Larmour
2001-07-13 4:32 ` Gary Thomas
1 sibling, 1 reply; 6+ messages in thread
From: Richard Panton @ 2001-07-13 2:55 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Gary Thomas, eCos Disuss
Indeed, the defintions for the modes have changed in eCos since I
initially wrote the ROMFS code. I don't quite see how it is possible for
the ipaq demo to work, given the changes...
However, the following changes to mk_romfs.c will fix the incompatibility.
It would be good if there were some way to include the eCos sys/stat.h so
that any change in the future could be taken care of, but that seems
impossible...
Index: mk_romfs.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/rom/current/support/mk_romfs.c,v
retrieving revision 1.1
diff -r1.1 mk_romfs.c
151c151
< mode_t mode; // Type and permissions
---
> mode_t st_mode; // Type and permissions
251a252,275
> // Damn it. When did these definitions change??? The modes were
identical when
> // I initially wrote this code, but changed sometime.
> static unsigned long ConvertMode( unsigned long posix_mode ) {
> unsigned long result = 0;
> if ( S_ISDIR( posix_mode ) ) result |= 1<<0;
> if ( S_ISCHR( posix_mode ) ) result |= 1<<1;
> if ( S_ISBLK( posix_mode ) ) result |= 1<<2;
> if ( S_ISREG( posix_mode ) ) result |= 1<<3;
> if ( S_ISFIFO(posix_mode ) ) result |= 1<<4;
> // We cannot create MQ, SEM, or SHM entries here
> if ( posix_mode & S_IRUSR ) result |= 1<<8;
> if ( posix_mode & S_IWUSR ) result |= 1<<9;
> if ( posix_mode & S_IXUSR ) result |= 1<<10;
> if ( posix_mode & S_IRGRP ) result |= 1<<11;
> if ( posix_mode & S_IWGRP ) result |= 1<<12;
> if ( posix_mode & S_IXGRP ) result |= 1<<13;
> if ( posix_mode & S_IROTH ) result |= 1<<14;
> if ( posix_mode & S_IWOTH ) result |= 1<<15;
> if ( posix_mode & S_IXOTH ) result |= 1<<16;
> if ( posix_mode & S_ISUID ) result |= 1<<17;
> if ( posix_mode & S_ISGID ) result |= 1<<18;
> return result;
> }
>
316c340
< node->mode = stbuff.st_mode;
---
> node->st_mode = stbuff.st_mode;
377c401
< if ( IS_DIRECTORY( th->mode ) ) {
---
> if ( IS_DIRECTORY( th->st_mode ) ) {
388c412
< if ( IS_DIRECTORY( np->mode ) ) {
---
> if ( IS_DIRECTORY( np->st_mode ) ) {
406c430
< if ( IS_DIRECTORY( np->mode ) && np->child )
---
> if ( IS_DIRECTORY( np->st_mode ) && np->child )
420c444
< if ( IS_DATAFILE( np->mode ) || IS_SYMLINK( np->mode ) ) {
---
> if ( IS_DATAFILE( np->st_mode ) || IS_SYMLINK( np->st_mode ) ) {
436c460
< if ( IS_DIRECTORY( np->mode ) ) {
---
> if ( IS_DIRECTORY( np->st_mode ) ) {
449c473
< if ( IS_EXECUTABLE( np->mode ) ) {
---
> if ( IS_EXECUTABLE( np->st_mode ) ) {
465c489
< if ( IS_DIRECTORY( np->mode ) ) {
---
> if ( IS_DIRECTORY( np->st_mode ) ) {
474c498
< outputlong( (char*) &anode.mode, np->mode );
---
> outputlong( (char*) &anode.mode, ConvertMode( np->st_mode ) );
498c522
< if ( IS_DIRECTORY( np->mode ) && np->child ) {
---
> if ( IS_DIRECTORY( np->st_mode ) && np->child ) {
527c551
< if ( IS_SYMLINK( np->mode ) ) {
---
> if ( IS_SYMLINK( np->st_mode ) ) {
572c596
< if ( IS_DIRECTORY( first->mode ) ) {
---
> if ( IS_DIRECTORY( first->st_mode ) ) {
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ROMFS in anoncvs
2001-07-13 0:14 ` Andrew Lunn
2001-07-13 2:55 ` Richard Panton
@ 2001-07-13 4:32 ` Gary Thomas
1 sibling, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2001-07-13 4:32 UTC (permalink / raw)
To: Andrew Lunn; +Cc: eCos Disuss
On 13-Jul-2001 Andrew Lunn wrote:
> On Thu, Jul 12, 2001 at 04:05:23PM -0600, Gary Thomas wrote:
>> A little harsh; perhaps open() calls for nested paths fail.
>>
>> It does look like you are correct about the mode stuff.
>
> The filesystems root directory, is not a directory, and so it fails
> imeadiatly with my test program.
>
Odd - these definitions have been current in the tree for a year.
Perhaps my iPAQ demo works because it doesn't use pathname separators
(i.e. all the files are in the topmost directory and I just use the name)
>> The two things
>> I see to be done are:
>> * Change 'mk_romfs' to perform some mapping from the host file system modes
>> to those used by eCos.
>
> I sent a patch to Jifl last night.
We also got a patch from Richard Panton, the original contributor.
>
>> * Improve the test program so that it can be run automatically, thus
>> allowing it to be tested more thoroughly by our test farm.
>
> I've got some test code embedded in a synthetic application. I will
> try to hack it into a standalone test.
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] ROMFS in anoncvs
2001-07-13 2:55 ` Richard Panton
@ 2001-07-13 13:38 ` Jonathan Larmour
0 siblings, 0 replies; 6+ messages in thread
From: Jonathan Larmour @ 2001-07-13 13:38 UTC (permalink / raw)
To: Richard Panton; +Cc: Andrew Lunn, eCos Disuss
Richard Panton wrote:
>
> Indeed, the defintions for the modes have changed in eCos since I
> initially wrote the ROMFS code. I don't quite see how it is possible for
> the ipaq demo to work, given the changes...
>
> However, the following changes to mk_romfs.c will fix the incompatibility.
I slightly prefer this version to Andrew's as it isn't Linux specific. I'll
check this in.
> It would be good if there were some way to include the eCos sys/stat.h so
> that any change in the future could be taken care of, but that seems
> impossible...
Changes shouldn't happen gratuitously. Looking at the cvs log of
sys/stat.h, it hasn't changed since it was initially made public.
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-07-13 13:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-12 11:38 [ECOS] ROMFS in anoncvs Andrew Lunn
2001-07-12 15:05 ` Gary Thomas
2001-07-13 0:14 ` Andrew Lunn
2001-07-13 2:55 ` Richard Panton
2001-07-13 13:38 ` Jonathan Larmour
2001-07-13 4:32 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).