You've got the idea and the possibilities it allow.
As you can see I've tried a balance between simplicity and functionality,
and found that with a small change on "int fds" to "struct fds" I could
achieve what I was looking at first place with minimal complications.
On Mon, Jan 14, 2013 at 2:54 AM, Jared Maddox <absinthdr...@gmail.com>wrote:
> > Date: Sat, 12 Jan 2013 23:33:48 +0100
> > From: grischka <gris...@gmx.de>
> > To: tinycc-devel@nongnu.org
> > Subject: Re: [Tinycc-devel] Added virtual io to tinycc
> > Message-ID: <50f1e4cc.6000...@gmx.de>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> >
> > Domingo Alvarez Duarte wrote:
> >> Let's see if I can explain it better.
> >>
> >> The modifications I did was replace:
> >> "fd" -> "fd or fd->fd depending on the context"
> >> [...]
> >
> > Indeed switching tinycc to cope with "struct fd" was a bad decision
> > to begin with. Under any circumstances I'd recommend to switch your
> > wrappers to "int fd" instead and thus to the same prototypes as
> > the original functions. Not a big deal, really.
> >
> > And the question (or suggestion, if you prefer) still is:
> >
> >> Can you make this work with all your extra files put in a
> >> subdirectory
> >>
> >> "contrib/<choose your name>"
> >>
> >> and with only the most minimal required change to our existing
> files?
> >>
> >> I suppose it could be three lines such as
> >>
> >> #ifdef TCC_CONTRIB_<WHATEVER>
> >> # include "contrib/<whatever>/some.h"
> >> #endif
> >>
> >> or maybe even less.
> >>
> >> --- grischka
> >
>
> I think that Domingo sees that as a problem because his modification
> doesn't currently use the same function prototypes. By switching the
> fds to ints that correspond to an element in an array or tree (I can
> donate a tree implementation if desired, though the balancing is still
> off) it should be possible to mostly use the same prototypes. However,
> there may be some reason why he's giving extra arguments to open
> (perhaps he wants to enable TCCState-level customizations), so there
> would be at least one prototype change regardless.
>
> Though, honestly, it should be possible to do a five line
> conventional-input converter if the "int fd" change goes through, so I
> think that it makes sense. The change will definitely affect all of
> the file i/o calls, but only by one added argument, and changing all
> of the struct fds to ints.
>
>
>
> Now on to the actual capability. Note that what I'm suggesting WOULD
> belong in something like "contrib/virtual_fs/vfs.h". From my
> perspective a full file and "mount" system should be provided by
> anything like this. I won't say that it's zero-effort, but it isn't
> too bad either. Basically you take a virtual filesystem (I can
> describe how this sort of thing works if you need some help with it:
> I've looked at writing them before), extend it's file/folder structure
> to support overrides (thereby allowing you to "mount" another virtual
> filesystem at arbitrary points without un-linking the previous data
> there), and if you just don't find a file or folder then the code
> resorts to the "fallback" that the current virtual filesystem
> structure is configured with (which could be yet another virtual
> filesystem or a "file not found" error). If you want access to the
> real filesystem then you just write an appropriate wrapper and mount
> it in the right place. If you want to overlay a real or a virtual
> filesystem on each other then you decide which you prefer to get your
> files from, and set the other as the fallback. Here's an example of
> how the structures might look:
>
> typedef struct vfs vfs;
> typedef struct vnode vnode;
>
> struct vfs {
> size_t elements;
> char **names;
> vnode *nodes;
> vfs *fallback;
> /* You might try "int (*node_open)( void*, const char**, int, vfs** )",
> for a recursion-free "try again" style. */
> int (*node_open)( void*, const char*, int );
> };
> struct vnode {
> enum {
> vnode_file = 1,
> vnode_directory = 2
> } type;
> vfs *dirmount;
> void *nodemount_data; int (*nodemount_open)( void*, const char*, int );
> void *node_data;
> };
>
> The main nuisance is that searching for the right file will be slow.
> If you want speed AND flexibility, then you want to write a
> string-table implementation so that your file/folder searches go
> faster. Really, most of the complexity is in making it go faster, not
> in making it work.
>
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
