On Sunday, September 21, 2014 3:33:04 PM UTC-4, [email protected] wrote: > > On Mon, Sep 8, 2014 at 1:30 PM, Freddie Chopin <[email protected] > <javascript:>> wrote: > >> W dniu 2014-09-08 19:22, Chris Johnson pisze: >> >>> TUP looks great. I've a fairly large and ever growing project (500 >>> source files, 150 directories) I need to frequently build. >>> >>> But having to install FUSE is a major problem. On Mac OSX, it appears >>> to require a kernel extension. On FreeBSD, there are other problems. >>> >> > When I switched from using LD_PRELOAD to FUSE, I was hoping that FreeBSD > support would be much easier (the LD_PRELOAD mechanism doesn't work well > there since so many of the core binaries are statically linked). I haven't > looked at FreeBSD much recently, but if FUSE is causing problems there, I > would guess we'd need an OS-specific dependency detection mechanism for > that platform. > > We can go back to LD_PRELOAD on OSX, which is something I had mostly > working a few months ago. I haven't had time to finish it though :(. > > >> >>> It's a clever idea using a filesystem to intercept the compiler, but >>> ultimately, a complexity which makes Tup an unworkable solution for some >>> people. >>> >> > The idea isn't my own, but IMO it is a core requirement for any build > system. I find that using a build system without automated dependency > detection & checking is much more unworkable. Unfortunately sandboxing & > file access detection aren't built-in to OSes, which is why we have to > implement it in tup itself. > > Note this doesn't necessarily mean that the detection has to be done at > the filesystem level, as with FUSE. But other levels have their own > problems (ie: LD_PRELOAD to capture the libc layer can be skipped from > statically linked binaries, ptrace to capture the syscall layer is slow & > machine specific). There could very well be a better solution, but it is > unlikely that it would be cross-platform. >
I recently found the 'mbox <http://pdos.csail.mit.edu/mbox/>' sandboxing software. It uses a combination of seccomp and strace to sandbox processes. The advantage of using seccomp is that one can create a filter for the subset of syscalls of interest, and the filtering is done in kernel. In particular, one can avoid tracing the read and write system calls, which are also very slow on the FUSE layer. Such a technique could alleviate the slowness of ptrace. On the other hand, it would not help the portability problem. Gus. > >> >> Recentyl I was thinking whether it would be possible to make tup work on >> Linux and other systems in the way it works on Windows - that is by hooking >> all system calls that are used to access file (open, close, read, write, >> ...). If such hooks are possible on other systems, then this appears to be >> simpler and less problematic than FUSE... On Windows it "just works" (apart >> from the lacking 64-bit support and no support for variants). >> > > As mentioned above, tup originally used LD_PRELOAD, which is conceptually > very similar to the DLL injection used on Windows. However, many people > complained that it didn't work with static binaries (eg: the Go toolchain, > or everything on FreeBSD), so I looked into alternatives and ended up with > the current FUSE setup. > > -Mike > -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
