At Sun, 22 Nov 2015 17:46:01 +0000,
Antti Kantee wrote:
>
> On 22/11/15 17:24, Hajime Tazaki wrote:
> > I submitted 2 pull requests on github, to rumprun and
> > buildrump.sh, to build Linux kernel as a replacement of
> > NetBSD rump kernel.
> >
> > https://github.com/rumpkernel/rumprun/pull/65
> > https://github.com/rumpkernel/buildrump.sh/pull/78
>
> Thanks. Does this mean that the Linux backend is now a real rump
> kernel, i.e. runs exclusively on top of the rump kernel hypercall interface?
I have tested rumpuser_pth (pthread), rumpfiber (ucontext),
bmk_rumpuser (hw/amd64). those are _partially_ working fine
without any patch to the rump kernel hypercall (i.e.,
rumpuser_xxx): some linux specific code like CONFIG_XFS_FS
hung during the boot (currently my rump-hypcall branch
disabled those options).'
fiber (ucontext) sometimes got hung, which I may need to
investigate more. xen, other arch hw are not tested yet.
so, I would say it is still a baby, but it's going to be a
rump kernel.
I will ask for a review for the particular commit of Linux
rump hyper call upper part (i.e., struct rumpuser_hyperup
and related stuffs) when I'll be ready.
> Do you really get much benefit from buildrump.sh? Without thinking too
> much about it, I'd guess it's mostly NetBSD-specific.
indeed.
my personal goal is to not wasting times for doing similar
stuffs (I mean, reusing existing code as much as possible),
I started to craft buildrump.sh as a small start. Having
Linux-version's buildrump.sh would be an option but I don't
see much benefit to introduce it.
> I don't like how Linux is patched in as a second-class citizen. If
> we're going to be offering alternatives, they should all be available at
> the same level, instead of one being the default and others being hidden
> in flags. The -k flag of buildrump.sh is a good example of how to not
> do things ...
agree too if you don't mind to break the current default
buildrump.sh behavior to build netbsd kernel.
maybe we can split OS specific scripts from buildrump.sh,
put into buildrump-netbsd.sh and buildrump-linux.sh (for
instance) and provide same functions, and import them from
a switch in buildrump.sh.
if ${opt_netbsd} ; then . buildrump-netbsd.sh ;
elif ${opt_linux} ; then . buildrump-linux.sh ;
fi
I can work on this way if you guys see benefits.
-- Hajime
