How to stack libtrivfs-based translators
Hello,
I have written a libtrivfs-based translator (the source code is
supplied in the attachment), however I have problems with stacking it
upon itself. I compile it using the following command:
gcc -Wall -g -ltrivfs -lfshelp mangle.c -o mangle -DDEBUG -DMANGLE
Then I stack it upon an untranslated node foo, which is a text file
containing the text: 'Hello'. I use the following command:
settrans -a foo mangle
If I now try to stack mangle upon foo again, using the command:
settrans -L foo mangle
I receive the following error message:
settrans: foo: Operation not supported
I also tried settrans -aL foo mangle (not sure if this matters), but I
obtain the same result. When I try fsysopts on the translated node foo
in the following way:
fsysopts foo
I get a similar error:
fsysopts: foo: Operation not supported
As you can see from mangle.c, I print a message in a log file
whenever any of libtrivfs callbacks is called. After the two
invocations of settrans, this file still contains the greeting message
only (i.e. Log session started).
Could you please tell me what I am doing wrong?
scolobb
/**/
/*mangle.c*/
/**/
/*A simple translator which mangles the underlying file*/
/**/
/*Copyright (C) 2001, 2002, 2005 Free Software Foundation, Inc.
Written by Sergiu Ivanov [EMAIL PROTECTED].
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
License, or * (at your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA.*/
/**/
/**/
#define _GNU_SOURCE 1
/**/
#include hurd/trivfs.h
#include stdlib.h
#include error.h
#include fcntl.h
#include sys/mman.h
#include unistd.h
#include stdio.h
/**/
/**/
/*Macros--*/
#ifdef DEBUG
# define LOG_MSG(msg, args...) {fprintf(fDbg, msg\n, ##args); fflush(fDbg);}
#else
# define LOG_MSG(msg, args...)
#endif
/**/
/**/
/*Global Variables*/
/*The type of this server*/
int trivfs_fstype = FSTYPE_MISC; /*generic trivfs server*/
/**/
/*The ID of the current filesystem*/
int trivfs_fsid = 0;
/**/
/*Type of access published by the translator*/
int trivfs_allow_open = O_READ;
/**/
/*Actually supported access modes*/
int trivfs_support_read = 1;
int trivfs_support_write = 0;
int trivfs_support_exec = 0;
/**/
/*The port to the underlying node of the translator*/
mach_port_t underlying;
/**/
#ifdef DEBUG
/*The file for debug ouput*/
FILE * fDbg;
#endif
/**/
/**/
/*Functions---*/
/*Modifies the stat information of the underlying node*/
void
trivfs_modify_stat
(
struct trivfs_protid * cred,
io_statbuf_t * st
)
{
LOG_MSG(trivfs_modify_stat);
error_t err;
/*Stat the underlying node and return the result*/
err = io_stat(underlying, st);
}/*trivfs_modify_stat*/
/**/
/*Frees the resources*/
error_t
trivfs_goaway
(
struct trivfs_control * cntl,
int flags
)
{
LOG_MSG(trivfs_goaway);
/*Close the debug file*/
#ifdef DEBUG
fclose(fDbg);
#endif
/*Die peacefully*/
Re: How to stack libtrivfs-based translators
Hello, That's probably one of the functions of libtrivfs that just always return EOPNOTSUP Samuel
Re: How to stack libtrivfs-based translators
On Tue, Jul 15, 2008 at 6:16 PM, Samuel Thibault [EMAIL PROTECTED] wrote: That's probably one of the functions of libtrivfs that just always return EOPNOTSUP Do you mean that one cannot stack libtrivfs-based translators? scolobb
Re: How to stack libtrivfs-based translators
Sergiu Ivanov, le Tue 15 Jul 2008 18:20:16 +0300, a écrit : On Tue, Jul 15, 2008 at 6:16 PM, Samuel Thibault [EMAIL PROTECTED] wrote: That's probably one of the functions of libtrivfs that just always return EOPNOTSUP Do you mean that one cannot stack libtrivfs-based translators? Possibly, or that you need to provide another hook for that. Samuel
New clean-up patch for gnumach
Hi folks, I've been lazy and useless for months now so I thought I'd do some more gnumach clean-up. Here is a patch to fix several implicit declaration of function warnings. Let me know what you think. Thanks, Barry gnumach_cleanup7.diff.gz Description: GNU Zip compressed data
Another clean-up (printf format warnings)
Here is another clean up patch. This one is for all of the format foo expects type bar.. warnings. I'm not sure if this is the preferred method of fixing (by casting the vars) or if the format should be changed? Thanks, Barry gnumach_cleanup8.diff.gz Description: GNU Zip compressed data
Re: New clean-up patch for gnumach
Hello, You forgot to include the hook that adds chario.h ;) Samuel
Re: New clean-up patch for gnumach
Samuel Thibault, le Wed 16 Jul 2008 00:21:42 +0100, a écrit : You forgot to include the hook that adds chario.h ;) Same for model_dep.h Samuel
wiki stability (was: GSoC meeting / wiki copyright assignment)
Hi, On Mon, Jul 14, 2008 at 01:21:44AM +0200, Arne Babenhauserheide wrote: It seems that I can't push my changes. People are working now on making it more stable... (Or actually, making it easier to kick it when necessary ;-) ) -antrik-
Re: codeswarm videos for GNU/Hurd and gnumach
Hi, On Mon, Jul 14, 2008 at 02:19:45AM +0200, Arne Babenhauserheide wrote: And for the wiki: - http://draketo.de/filme/cc-nc-sa/hurd_wiki.avi I think the wiki started only 2002, when there is the first surge of activity. Before that, it's just imported stuff from the static web pages, which is probably better to omit -- not very interesting to look at :-) Also, with the start of the new wiki in late 2007, the commit address becomes rather meaningless, as all commits done through the web interface end up with the same name... Would it be possible to extract the actual users from the web commits somehow? -antrik-
Re: How to stack libtrivfs-based translators
Hi,
On Tue, Jul 15, 2008 at 06:10:02PM +0300, Sergiu Ivanov wrote:
I have written a libtrivfs-based translator (the source code is
supplied in the attachment), however I have problems with stacking it
upon itself.
[...]
If I now try to stack mangle upon foo again, using the command:
settrans -L foo mangle
I receive the following error message:
settrans: foo: Operation not supported
This requires certain RPCs in fs.defs (and probably fsys.defs) to be
implemented, most notably file_set_translator. A quick look at
file-set-translator.c from libtrivfs shows us that
trivfs_S_file_set_translator() is implemented as
{ return EOPNOTSUPP; }
i.e. it's not implemented at all.
In other words, libtrivfs doesn't seem to support setting further
translators on the translated node out of the box. (I think you could
implement it manually, though...)
I must admit that this surprises me quite a bit. I wonder whether there
is any good reason for that...
When I try fsysopts on the translated node foo in the following way:
fsysopts foo
I get a similar error:
fsysopts: foo: Operation not supported
You need to implement the trivfs_append_args() callback -- see the hello
translator for a trivial example, or others like pfinet for more complex
ones.
-antrik-
Re: New clean-up patch for gnumach
Hi, On Tue, Jul 15, 2008 at 12:27:02PM -0400, Barry deFreese wrote: Here is a patch to fix several implicit declaration of function warnings. +extern void cninit(); If a function does not take any parameters, I think it's better to always state it explicitely in the prototype, i.e. extern void cninit(void); Otherwise the compiler thinks that the paremeters are just not stated in the prototype, and won't warn if the function is wrongly called with parameters... (Note that in the function *definition*, where the function is actually implemented, () is equivalent to (void), but in the prototype it's not!) -antrik-
Re: New clean-up patch for gnumach
Samuel Thibault, le Wed 16 Jul 2008 00:21:42 +0100, a écrit : You forgot to include the hook that adds chario.h ;) Same for mach_port.h Samuel
Re: Another clean-up (printf format warnings)
Barry deFreese wrote: Here is another clean up patch. This one is for all of the format foo expects type bar.. warnings. I'm not sure if this is the preferred method of fixing (by casting the vars) or if the format should be changed? Thanks, Barry Here is an improved patch that fixes the format strings rather than casting the variables. Thanks, Barry deFreese gnumach_cleanup8v2.diff.gz Description: GNU Zip compressed data
