On 08/01/15 12:38, Hajime Tazaki wrote:
> my current implementation of hyp.hyp_schedule() is NOP,
> which I haven't investigated what I (i.e. Linux) should
> care.
>
> probably later on, I will start to work on this more deeply:
> since system calls used by configuration command (i.e.,
> netlink and ioctl) to the kernel works fine so far, I don't
> face any issues at this moment. more code reading and
> hacking (and playing) required.
Scheduling will matter when you start stressing the code enough to start
hitting places where synchronization matters. For example, if you have
two threads running on the same smp_processor_id() at the same time, or
use the same task_struct as the current task in many places at the same
time, you will get corruption, and debugging that is not fun. I really
encourage you to very carefully think about all levels of scheduling and
synchronization early on, it will save a lot of time later.
> # if this forum prefers to paste raw (inline) patchset, I
> will follow your policy.
I think it's easier if reasonably small patches are attached to the
mail. If you have several gigabytes of patches, then links may be better.
> right now, I have no reason to upstream my code (of
> src-netbsd changes) because it's really a gimmick. see my
> above diffs of src-netbsd, which uses thread local storage
> (horrible..) to store spc_client instance.
Ok. I will let you decide when you think you have changes which are
upstreamable and propose them for integration.
>> Are you saying that the toolkit should consist of
>> librump{user,hijack,client} and rumpuser.h? That's not a bad idea for
>> something to investigate.
>
> something like that.
> if someone tries to apply the rumpkernel idea with their own
> OSs (as I'm doing), such toolkit will be helpful.
Perhaps. The bulk of the work is in the OS codebase itself, though, so
a toolkit is not going to help _much_, and putting a lot of effort into
generalizing a toolkit would IMHO be spent in the wrong place. That's
not so say we shouldn't use the same code, just that we shouldn't put
much design into what other systems might hypothetically need.
(data point: my prototypes for Linux and FreeBSD did use the exact same
rumpuser implementation as for NetBSD, so in that sense I agree with you
that there should be code sharing)
>>> in hijack.c, system calls are intercepted by LD_PRELOAD, as
>>> NUSE does. in Linux glibc, some of the functions are using
>>> strong alias (I guess: need to investigate more) which we
>>> cannot hijack by LD_PRELOAD. for example, if_nametoindex(3)
>>> uses '__socket' symbol, which results in inline system calls (we
>>> can't replace it by our own?). does NetBSD glibc have such a
>>> system call ? if yes, does librumphijack take a special care?
>>
>> What's an "inline system call"? I tried to read the glibc sources, but
>> not sure what that means, looks like __socket is a symbol just like
>> anything else, except that it's the libc internal name.
>
> I guess Justin said all.
>
> for more information.
>
> https://sourceware.org/glibc/wiki/SyscallWrappers
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/sysdep.h;h=3dbd7d2be4e0ca261592e7e15993ffaebb61b9bd;hb=HEAD#l234
I don't see any showstoppers there (at least unless __socket is a
"bespoke" syscall). Can you be explicit?
The whole hijack model works on the principle that things just
chaotically happen to work. If you try to make it perfect, you will go
mad (or you will start building your own libc ... or both).
>> On NetBSD, librumphijack hijacks some internal libc symbols, e.g. it
>> hijacks _sys_write, not write. That just works. I didn't do very much
>> testing with glibc when I was on that some years ago, so it's possible
>> that things will just not work.
>
> I envy you ;)
Don't worry, I'm sure things will also just work for you after 4 years
and ~5000 commits to various layers.
>> If you want to know more about ptrace in a similar scenario, I'd suggest
>> looking at what ViewOS is doing with ptrace and utrace.
>
> thanks.
> I already looked a bit on UML, another ptrace user.
UML is different, because it's a fully virtualized OS. ViewOS is close
to your use case, because it's built around a principle of "let the
application use an alternative implementation for subsystem x".
>> Yes, it should be possible (and even sensible in high-performance
>> cases), but nobody just got around to doing it. Note that rumprun-posix
>> also provide a sort of "local hijacking", except that it doesn't do
>> hijacking (hope that makes sense ;).
>
> I'm a bit puzzled ;)
> I will look at code of rumprun-posix. objcopy ? (now I
> glanced the code)
Most of the build goop in rumprun-posix is dealing with the complexity
of running a full userspace namespace inside an already existing full
userspace namespace. So in addition to having to run the kernel in an
unknown namespace (what UML solves with -Dfoo=kernel_foo and the rump
kernel with objcopy), rumprun-posix also has to deal with running
userspace in a userspace without conflicting. It's sort of a headache
generator, which is why I prefer to let Justin work on it ;)
- antti
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
