Skip to contentSkip to conversation

mkfs.jffs2 not compiling, which acl.h?

DISCUSSION Glen Johnson 4 participants 8 messages Dec 6, 2006 – Dec 10, 2006 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 2 lines · Glen Johnson

<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

#2 lore raw
Quoted 4 lines · Ricard Wanderlof

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

#3 lore raw
Quoted 1 line · Glen Johnson

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

Quoted 1 line

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

#4 lore raw
In reply to Glen Johnson
Quoted 3 lines · Glen Johnson

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?

Signature · 1 line
dwmw2
#5 lore raw
Quoted 6 lines · David Woodhouse

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.

Quoted 3 lines

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.

#6 lore raw
In reply to David Woodhouse

I'm sorry for delayed responding.

Quoted 5 lines

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,

Signature · 1 line
KaiGai Kohei <[email protected]>
#7 lore raw
Quoted 6 lines · KaiGai Kohei

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.

Signature · 1 line
dwmw2