Hi Antti,
I hope I'm not belated ;)
At Fri, 09 Jan 2015 01:59:11 +0000,
Antti Kantee wrote:
>
> 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.
thanks, i fully agree.
since NUSE also implemented with a simple scheduler (of
course we must have), the implementation of
hyp.hyp_schedule() itself would be not big matter.
what hard (for myself) is to align current design of nuse
with rumpserver.
> >> 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)
agreed too. if my progress applying to NUSE is going to a
reasonable design (i mean maintainable for a long term),
then i would propose such a toolkit with a repository.
> >>> 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?
__socket is finally expanded into an inline assembly, as
Justin mentioned. that is explained as 'Assembly syscalls'
in the above glibc wiki page (sorry for the confusion).
so __socket used by if_nametoindex() has no chance to hijack
as-is.
> 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).
i'm gonna mad ;)
> >> 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.
nuse is still babyish. i wish the follower will play well
with the frontiers' experience ;)
> >> 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".
okay, will see.
> >> 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 ;)
I concur ;)
-- Hajime
------------------------------------------------------------------------------
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
