Re: Feeble attempt at using xattr gnu.translator
Jan Nieuwenhuizen, le lun. 11 mai 2020 10:53:58 +0200, a ecrit: > Samuel Thibault writes: > > > Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit: > >> > diskfs_S_file_set_translator (struct protid *cred, > >> > [...] > >> > if (passivelen && passive[passivelen - 1]) > >> > return EINVAL; > >> > > >> > hmm; so even when there are no arguments, VALUE must end with 0?! > >> > >> That > > > > That's a bit sad, but I'm not so surprised either. I don't remember if > > that was discussed at the time. > > At first glance it felt like a bug/non-finished thing; setttrans does > not require the user to resort to \0-hackery. It does not because settrans is supposed to *be* the user-visible interface. setfattr is not supposed to be. Samuel
Re: Feeble attempt at using xattr gnu.translator
Samuel Thibault writes: > Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit: >> > diskfs_S_file_set_translator (struct protid *cred, >> > [...] >> > if (passivelen && passive[passivelen - 1]) >> > return EINVAL; >> > >> > hmm; so even when there are no arguments, VALUE must end with 0?! >> >> That > > That's a bit sad, but I'm not so surprised either. I don't remember if > that was discussed at the time. At first glance it felt like a bug/non-finished thing; setttrans does not require the user to resort to \0-hackery. Of course, setfattr is a generic tool; so nothing can be done there to make this frienlier; I'm not sure if something could be done on the hurd side. Could be nice, not sure. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Feeble attempt at using xattr gnu.translator
Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit: > > diskfs_S_file_set_translator (struct protid *cred, > > [...] > > if (passivelen && passive[passivelen - 1]) > > return EINVAL; > > > > hmm; so even when there are no arguments, VALUE must end with 0?! > > That That's a bit sad, but I'm not so surprised either. I don't remember if that was discussed at the time. Samuel
Re: Feeble attempt at using xattr gnu.translator
Jan Nieuwenhuizen, le lun. 11 mai 2020 10:33:53 +0200, a ecrit: >gnu.translator empty if no passive translator > translator and arguments: "/hurd/foo\0arg1\0arg2\0" > > ah...so there's a nice hack (way??) to also pass arguments... ? It's not hack, it's how it's passed on the process main() stack anyway. > diskfs_S_file_set_translator (struct protid *cred, > [...] > if (passivelen && passive[passivelen - 1]) > return EINVAL; > > hmm; so even when there are no arguments, VALUE must end with 0?! That > root@debian:~# setfattr --name=gnu.translator --value='/hurd/pflocal\0' 1 > root@debian:~# showtrans 1 > /hurd/pflocal > --8<---cut here---end--->8--- > > ...so "something" works. Good :) > Sadly, this trick does not work on GNU/Linux. I'm afraid this hasn't > been upstreamed and we would have to debug linux and/or create a patch > for setxattr to accept "gnu." on "Hurd" type file systems. Thoughts? Well, this has to be done, yes, I don't know what else to add :) Samuel
Re: Feeble attempt at using xattr gnu.translator
Samuel Thibault writes: Hello Samuel, > Did you have a look at Shengyu Zhang's work on xattr? That's about > summer 2016. Ah, that's a helpful pointer. What I notice is that Shengyu's last message says "not merged yet", to which Richard Braun responds https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00095.html "we'll have more time in September to really dive into the code, finish the review and merge it." It got merged, but I'm not sure about the "finish" bit; Justus Winter disabled it by default (not a great sign), and GSoC 2017 mentions: "finishing the xattr work" https://lists.gnu.org/archive/html/bug-hurd/2017-01/msg00016.html I cannot find any more meta data, documentation or tests... > Also see glibc/sysdeps/mach/hurd/setxattr.c which > translates gnu attributes into RPC calls, and then again in the > translators's diskfs_set_translator. See for instance in > hurd/ext2fs/inode.c's diskfs_set_translator, it looks at > > if (EXT2_HAS_COMPAT_FEATURE (sblock, EXT2_FEATURE_COMPAT_EXT_ATTR) > && use_xattr_translator_records) I noticed the --x-xattr-translator-records before but after reading some more code, I got a little bit further glibc/hurd/xattr.c has gnu.translator empty if no passive translator translator and arguments: "/hurd/foo\0arg1\0arg2\0" ah...so there's a nice hack (way??) to also pass arguments...and then hurd/libdiskfs/file-set-trans.c has diskfs_S_file_set_translator (struct protid *cred, [...] if (passivelen && passive[passivelen - 1]) return EINVAL; hmm; so even when there are no arguments, VALUE must end with 0?! Okay... --8<---cut here---start->8--- root@debian:~# touch 1 root@debian:~# setfattr --name=gnu.translator --value=/hurd/pflocal 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.translator --value='/hurd/pflocal\0' 1 root@debian:~# showtrans 1 /hurd/pflocal --8<---cut here---end--->8--- ...so "something" works. Sadly, this trick does not work on GNU/Linux. I'm afraid this hasn't been upstreamed and we would have to debug linux and/or create a patch for setxattr to accept "gnu." on "Hurd" type file systems. Thoughts? Also, some other things also don't work --8<---cut here---start->8--- root@debian:~# getfattr --name=gnu.translator 1 1: gnu.translator: Operation not supported root@debian:~# setfattr --name=gnu.translator --value='/geert/pflocal\0' 1 setfattr: 1: Operation not supported root@debian:~# setfattr --remove=gnu.translator 1 setfattr: 1: Operation not supported --8<---cut here---end--->8--- Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Feeble attempt at using xattr gnu.translator
Hello, Did you have a look at Shengyu Zhang's work on xattr? That's about summer 2016. Also see glibc/sysdeps/mach/hurd/setxattr.c which translates gnu attributes into RPC calls, and then again in the translators's diskfs_set_translator. See for instance in hurd/ext2fs/inode.c's diskfs_set_translator, it looks at if (EXT2_HAS_COMPAT_FEATURE (sblock, EXT2_FEATURE_COMPAT_EXT_ATTR) && use_xattr_translator_records) Samuel
Feeble attempt at using xattr gnu.translator
Hello, As part of the effort of creating vm-images for the Hurd using Guix, it would be nice to use extended file attributes to set passive translators. In particular, it would be helpful if we could use setfattr --name=gnu.translator --value=/hurd/pfinet 1 That would allow us to boot right into Guile and skip a Bash script to only to run settrans -c /servers/socket/1 /hurd/pflocal Whether on GNU/Linux or on the Hurd (booted with --x-xattr-translator-records and x-xattr-translator-records option in fstab); almost nothing works. The Hurd root@debian:~# cat /etc/fstab # /etc/fstab: static file system information. # # /dev/hd0s2 / ext2defaults,x-xattr-translator-records 0 1 /dev/hd0s1 noneswapsw 0 0 /dev/hd2/media/cdrom0 iso9660 noauto 0 0 root@debian:~# fsysopts / ext2fs --writable --no-inherit-dir-group --x-xattr-translator-records --store-type=typed device:hd0s2 root@debian:~# ps -ef --width=1000 | grep ext2 - 5 2 - 0:02.98 ext2fs --readonly --multiboot-command-line=root=device:hd0s2 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s2 --x-xattr-translator-records so that seems OK? Still, nothing seems to work root@debian:~# touch 1 root@debian:~# mknod 2 c 0 0 root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 2 setfattr: 2: Invalid argument root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 2 setfattr: 2: Invalid argument root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not supported On GNU/Linux, I only managed to set user.X, not gnu.translator root@dundal ~# touch 1 root@dundal ~# mknod 2 c 0 0 root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not supported root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 2 setfattr: 2: Operation not supported root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 1 root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not permitted only one command succeeds, but that's next to useless (well, it suggests touch could work and we don't need mknod). This https://lists.gnu.org/archive/html/bug-hurd/2004-02/msg00108.html is the only interesting piece of information I found; down the thread there is a suggestion to try upstreaming. I looked at the Linux sources They seem to suggest that only a couple of namespaces are allowed (and "gnu" is not one of them) but find them hard to read. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
