At Fri, 06 Feb 2015 16:33:04 +0000, Antti Kantee wrote: > > what hard (for myself) is to align current design of nuse > > with rumpserver. > > Please be explicit. Maybe we can adjust rumpserver to better suit your > needs.
I haven't come up with what it will be clearly. Just a guess from 1.5 month experience with rumpserver. I haven't spent much time to think about how to do it (even after long silence). I will get back here later. > Notably though, rump_server was designed to be a convenient way to do > testing. It wasn't meant for any high-performance use cases. noted. > > 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 academia people like to propose, but in open source we also have to do ;) ;) > I still think it's a worthwhile idea, though toolkit layers always add > extra work. Are you willing to drive the effort? again, not sure right now. i anyway will propose IF i got a nice shape. I agree that the extra layer makes extras, btw. > >>>> 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). > > Ok. If it's any condolence, I had to fix misuses of inline in NetBSD to > make it possible to abstract things. That said, I did have the > advantage of being able to change both the kernel and libc. ;) > Did you try asking the glibc people if they'd be willing remove the > inline syscalls? After the change-of-leadership, they might be willing > to comply with reasonable requests. I haven't yet. I wasn't aware of the new leadership of glibc so, it would be a nice chance. > Most inline goop is a remnant of the VAX where function calls were > relatively expensive ... understand. -- 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
