Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: whoisterence on August 22, 2012, 12:54:33 AM
-
Tried to compile LiveDFS which is a variant of the ext3 filesystem.
get errors like the following:
/xattr.c:108: error: ‘ext3_xattr_user_handler’ undeclared here (not in a function)
these are found in file LiveDFS/xattr.h:
#include <linux/xattr.h>
extern struct xattr_handler ext3_xattr_user_handler;
Couldn't find this in /usr/local/src/linux-headers-2.6.33.3-tinycore/include/linux/xattr.h?
I am using tinycore_3.4 do I need a higher kernel version?
-
The current version of TC is 4.5 with kernel 3.0.21.
Version 3.x is unmaintained.
-
Hi whoisterence
I just looked in /usr/local/src/linux-headers-3.0.3-tinycore/include/linux/xattr.h and it does have
struct xattr_handler defined, so maybe you do need a newer kernel.
-
Hi whoisterence
I just took a look at the LiveDFS tarball and ext3_xattr_user_handler is defined in xattr_user.c which also exists
in the full kernel sources under fs/ext3. The Makefile contains a couple of commented out references to a 2.6.32
kernel so you may not need a newer kernel after all. Maybe someone who knows about compiling kernel
modules can provide some insight.
-
There have been no updates to this package since the initial release a year ago.
-
I tried to contact the maintainer but no response.
The code is definitely out of sync with linux, when I tried to compile with tinycore-4.5.6 (linux 3.0.21 I think) and I got error about smp_lock.h missing (related to BLK lock_kernel() which has since been depreciated).
Since I believe the code is a mod of the ext3 code, I tried to compile by combining it with the latest ext3 src from kernel.org. I got a few more ddfs_*.o (there some minor modification needed) , but still getting stuck like before. Seems like I am still having trouble compiling xattr.c which is from linux src.
make[1]: Entering directory `/usr/local/src/linux-headers-3.0.21-tinycore'
CC [M] /mnt/sda1/backup/liveDFS/LiveDFS/xattr.o
LiveDFS/xattr.c:108:35: error: 'ext3_xattr_user_handler' undeclared here (not in a function)
LiveDFS/xattr.c:113:37: error: 'ext3_xattr_trusted_handler' undeclared here (not in a function)
LiveDFS/xattr.c:119:29: error: expected identifier or '(' before 'void'
LiveDFS/xattr.c:119:29: error: expected ')' before numeric constant
LiveDFS/xattr.c:319:1: error: conflicting types for 'ext3_xattr_get'
LiveDFS/xattr.h:84:1: note: previous definition of 'ext3_xattr_get' was here
LiveDFS/xattr.c: In function 'ext3_xattr_get':
...
I also found the comments about linux-headers-2.6.32.15+drm33.5-ddfs, seems like some sort of custom built.
-
I think I found the problem in linux/xattr.h
# ifdef CONFIG_EXT3_FS_XATTR
extern const struct xattr_handler ext3_xattr_user_handler;
extern const struct xattr_handler ext3_xattr_trusted_handler;
extern const struct xattr_handler ext3_xattr_acl_access_handler;
extern const struct xattr_handler ext3_xattr_acl_default_handler;
extern const struct xattr_handler ext3_xattr_security_handler;
but in the .config CONFIG_EXT3_FS_XATTR is not defined
there was a thread about xattr in the forum before http://forum.tinycorelinux.net/index.php/topic,6444.msg34229.html#msg34229
So I guess xattr is not compiled in.
-
Hi whoisterence
So I guess xattr is not compiled in.
Neither are EXT2 or EXT3, though something called CONFIG_EXT4_USE_FOR_EXT23 is enabled. But EXT4
xattr is not enabled.
but in the .config CONFIG_EXT3_FS_XATTR is not defined
I think that's because EXT3 is not enabled. If you enable it using one of the config utilities, it will probably show
up as an option, but now you are also taking about compiling a custom kernel.
-
Is it possible to compile xattr as a kernel module?
-
Looks like no, must be compiled in to the kernel:
cp /usr/local/src/linux-headers-2.6.33.3-tinycore/.config .
make oldconfig
The Extended 4 (ext4) filesystem (EXT4_FS) [Y/n/m/?] y
Use ext4 for ext2/ext3 file systems (EXT4_USE_FOR_EXT23) [Y/n/?] y
Ext4 extended attributes (EXT4_FS_XATTR) [Y/n/?] (NEW) y
Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [N/y/?] (NEW) y
Ext4 Security Labels (EXT4_FS_SECURITY) [N/y/?] (NEW) y
no "m" loadable module option...
-
Hi whoisterence
Even if it were possible to compile as a module, you would still have to compile a kernel with xattr enabled.
-
Finally able to compile LiveDFS.
I figured that extended attributes is probably not used directly by LiveDFS, so I patched the LiveDFS/Makefile as follows so that only if these kernel options are available then will xattr and acl be compiled in.
diff old/LiveDFS/Makefile new/LiveDFS/Makefile
10,12c10,12
< ldfs-y += xattr.o xattr_user.o xattr_trusted.o
< ldfs-y += acl.o
< ldfs-y += xattr_security.o
---
> ldfs-$(CONFIG_EXT3_FS_XATTR) += xattr.o xattr_user.o xattr_trusted.o
> ldfs-$(CONFIG_EXT3_FS_POSIX_ACL) += acl.o
> ldfs-$(CONFIG_EXT3_FS_SECURITY) += xattr_security.o
I guess xattr is used in mainstream distributions like Ubuntu, so LiveDFS decided to compile it in. I did a quick scan thur their codes ldfs-*.c and they doesn't seem to make direct calls to xattr.
I suppose the question is since xattr/acl is not loadable as a module, whether it is a trend to have xattr in core? Would including it increase the core size significantly?
-
For reference, to get LiveDFS loaded I also needed to compile jbd (journal system used by ext3) as well, which is not included in core base.
download linux source
modified linux-2.6.33.3/fs/jbd/Makefile
diff Makefile.old Makefile
< obj-$(CONFIG_JBD) += jbd.o
---
> obj-m += jbd.o
7a8,10
>
> all:
> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
make
sudo insmod jbd.ko
cd LiveDFS
sudo insmod ldfs.ko
-
I suppose the question is since xattr/acl is not loadable as a module, whether it is a trend to have xattr in core? Would including it increase the core size significantly?
Xattrs is mainly used for the heavyweight security frameworks (selinux), the acl for NTFS-style permissions. Neither has much use among our users, so they would bloat the kernel for everyone but be of use to a small minority.
As for how much exactly, that I don't know.
-
I agree, that's what I like about Core, keeping things minimal. On the other hand, seems to me non-loadable modules makes the kernel fall behind in terms of mainstream features; with no solutions other than a kernel recompile (can't just load a tce).
It's a tough balance I suppose, I wonder what is Core's principle regarding what non-loadable modules to omit?
Just a data point, I turned on the following which seems to be used by most new filesystem these days (e.g. native ZFS) and recompiled the 2.6.33.3 kernel:
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y (this might not be needed)
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
Before:
2294848 bzImage
After:
2469536 bzImage
about 7% difference.
-
It's a tough balance I suppose, I wonder what is Core's principle regarding what non-loadable modules to omit?
Indeed. There's no set percentage, but I'd wager if something like 95% or 99% do not use some non-module-able feature, it's gone.
We don't make it difficult to run with one's own kernels, TC runs on vanilla kernels fine. So if some advanced user shows up with such a need, they can easily build a custom kernel with that feature. Many custom installs can also benefit from the cutting of unused parts such can bring.