mkfs.jffs2 not compiling, which acl.h?

mkfs.jffs2 not compiling, which acl.h?

[Glen Johnson]

Linux-mtd,
First off I am using uClinux-dist 2006-08-03 source code with the
m68k-uclinux-tools-20060615 cross compiler.  What I am trying to do is
compile the latest version of the mtd-utils.  I used git to retrieve the
latest version of the mtd-utils and put those files into
uClinux-dist/user/mtd-utils directory.  When I run make the compile
stops complaining that it can't find <sys/acl.h> and then gives errors
like listed below.
mkfs.jffs2.c:1093: error: 'ACL_MASK' undeclared (first use in this function)
mkfs.jffs2.c:1094: error: 'ACL_OTHER' undeclared (first use in this
function)
mkfs.jffs2.c:1100: error: 'ACL_USER' undeclared (first use in this function)
mkfs.jffs2.c:1101: error: 'ACL_GROUP' undeclared (first use in this
function)

I ran find uClinux-dist/ -name acl.h and got this list of files.
./linux-2.6.x/include/config/fs/posix/acl.h
./linux-2.6.x/fs/ext3/acl.h
./linux-2.6.x/fs/ext2/acl.h
./user/asterisk/include/asterisk/acl.h
./user/bind/lib/dns/include/dns/acl.h

After checking each of these files I found that ACL_* were not defined
in any of them.  I then ran grep -r ACL_MASK ./ and found ACL_MASK was
defined in the header file <linux/posix_acl.h> .  I tried #include
<linux/posix_acl.h> in place of <sys/acl.h> and got warnings about not
other info.  If I #include <asm-m68knommu/atomic.h> all the warnings and
errors dissappear.

Do I really have to include both <asm-m68knommu/atomic.h> and
<linux/posix_acl.h> in place of <sys/acl.h>?  By the way I never found
sys/acl.h anywhere in uClinux-dist.  What is the proper way to handle this?
Thank you,
Glen Johnson

Re: mkfs.jffs2 not compiling, which acl.h?

[Ricard Wanderlof]

On Wed, 6 Dec 2006, Glen Johnson wrote:

> <linux/posix_acl.h> in place of <sys/acl.h>?  By the way I never found
> sys/acl.h anywhere in uClinux-dist.  What is the proper way to handle this?

There was a patch posted a week or two ago on this list which enables you 
to compile mkfs.jffs2 on systems where acl.h (and the features it 
supports) are missing. Check the archives.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: mkfs.jffs2 not compiling, which acl.h?

[Glen Johnson]

Ricard Wanderlof wrote:
> There was a patch posted a week or two ago on this list which enables you 
> to compile mkfs.jffs2 on systems where acl.h (and the features it 
> supports) are missing. Check the archives.
>   
Mr Wanderlof,
You are absolutely right.  I did find the patch just as you stated.  I
downloaded the patch and to my surprise my code already had the patch in
it.  I did see along with the patch that I am to cd mtd-utils/ and then
make WITHOUT_XATTR=1.  This works great however, when I cd into
uClinux-dist/ and run make, WITHOUT_XATTR=1 never gets passed to the
makefile in the mtd-utils directory. 
1. Do I need to change something in the uClinux-dist/user/Makefile so
that it will pass WITHOUT_XATTR=1 to the mtd-utils/makefile?

2. Do I need to add something to a config file under the vendors directory?

Thank you,
Glen Johnson

Re: mkfs.jffs2 not compiling, which acl.h?

[Ricard Wanderlof]

On Wed, 6 Dec 2006, Glen Johnson wrote:

> make WITHOUT_XATTR=1.  This works great however, when I cd into 
> uClinux-dist/ and run make, WITHOUT_XATTR=1 never gets passed to the 
> makefile in the mtd-utils directory.

1. Do I need to change something in
> the uClinux-dist/user/Makefile so that it will pass WITHOUT_XATTR=1 to 
> the mtd-utils/makefile?

I don't know much about uClinux, but somehow you have to set 
WITHOUT_XATTR=1 when making mtd utils. The easiest is probably to hard 
edit the mtd-utils makefile and put

WITHOUT_XATTR = 1

somewhere at the beginning of the file.

Or, you could find the 'make -C mtd-utils' (or similar) line in 
uClinux-dist/user/Makefile, and add WIHTOUT_XATTR=1 to that line. Don't 
know how the uClinux build system is laid out so it could well be more 
convoluted than this.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

Re: mkfs.jffs2 not compiling, which acl.h?

[David Woodhouse]

On Wed, 2006-12-06 at 08:56 -0500, Glen Johnson wrote:
> I tried #include <linux/posix_acl.h> in place of <sys/acl.h> and got
> warnings about not other info.  If I #include <asm-m68knommu/atomic.h>
> all the warnings and errors dissappear. 

There is something broken about your toolchain if _either_
<linux/posix_acl.h> or <asm/atomic.h> exist. Those are _not_ headers
which the kernel exports when you run 'make headers_install' to generate
the headers for userspace to use. Please make sure you report this
problem to whoever generated your toolchain.

The acl.h which you should be using comes from libacl -- although we
only use about 6 #defines from it and don't link against the library.
Perhaps we should just copy those instead of requiring the header?

Actually, I'm not entirely sure what this code is doing at all -- isn't
it interpreting on-disk xattrs representing ACLs assuming that they're
in the same format as ext3 uses? If you use mkfs.jffs2 on a big-endian
system, actually reading _from_ a jffs2 filesystem, does it do the right
thing? What about from other file systems?

KaiGai-san?

-- 
dwmw2

Re: mkfs.jffs2 not compiling, which acl.h?

[Glen Johnson]

David Woodhouse wrote:
> There is something broken about your toolchain if _either_
> <linux/posix_acl.h> or <asm/atomic.h> exist. Those are _not_ headers
> which the kernel exports when you run 'make headers_install' to generate
> the headers for userspace to use. Please make sure you report this
> problem to whoever generated your toolchain.
>   
I am using m68k-uclinux-tools-20060615 used with the uClinux
distribution for embedded systems. 
> Actually, I'm not entirely sure what this code is doing at all -- isn't
> it interpreting on-disk xattrs representing ACLs assuming that they're
> in the same format as ext3 uses? 
I was pointed to this link to answer why ACL is used in mkfs.jffs2.

http://thread.gmane.org/gmane.linux.drivers.mtd/16740/focus=16745

This is an excerpt from the above link.
"The access control list(ACL) enables higher flexible access control
based on UNIX users and groups than traditional user/group/others model.
'--with-xattr' or '--with-posix-acl' options on mkfs.jffs2 enables to
copy the ACLs associated with any files in host environment into jffs2
image file.
The purpose of this feature is improvement of security in embedded region."

This link also describes the compile flag WITHOUT_XATTR=1 which will disable this code.

Re: mkfs.jffs2 not compiling, which acl.h?

[KaiGai Kohei]

I'm sorry for delayed responding.

> Actually, I'm not entirely sure what this code is doing at all -- isn't
> it interpreting on-disk xattrs representing ACLs assuming that they're
> in the same format as ext3 uses? If you use mkfs.jffs2 on a big-endian
> system, actually reading _from_ a jffs2 filesystem, does it do the right
> thing? What about from other file systems?

Because the on-disk xattr representation which holds any ACLs is
interpreted into _common_ format in the kernel, the user space
application including mkfs.jffs2 does not need to be conscious
the differences between filesystems or endians.

See, fs/xattr_acl.c in the kernel.
Any filesystem (excluding xfs) calls posix_acl_to_xattr() to interpret
the in-kernel representation of ACLs before returning it into userspace.

The common format is defined as a leading 'posix_acl_xattr_header' and
an array of 'posix_acl_xattr_entry'. All of them are represented in
little-endian ordering.

Thus, we can assume the same format as ext3 (and any filesystem) uses.
Is it OK?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: mkfs.jffs2 not compiling, which acl.h?

[David Woodhouse]

On Sun, 2006-12-10 at 01:40 +0900, KaiGai Kohei wrote:
> The common format is defined as a leading 'posix_acl_xattr_header' and
> an array of 'posix_acl_xattr_entry'. All of them are represented in
> little-endian ordering.
> 
> Thus, we can assume the same format as ext3 (and any filesystem) uses.
> Is it OK? 

That's fine then -- I just wanted to check. Thanks.

-- 
dwmw2