Re: [Tinycc-devel] Added virtual io to tinycc

[Jared Maddox]

> Date: Sat, 12 Jan 2013 23:33:48 +0100
> From: grischka <address@hidden>
> To: address@hidden
> Subject: Re: [Tinycc-devel] Added virtual io to tinycc
> Message-ID: <address@hidden>
> 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.