From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antti Kantee Subject: Re: Error when Glib cross compiled into Mini-OS without the support of "_POSIX_THREADS" Date: Thu, 25 Sep 2014 15:41:14 +0000 Message-ID: <5424379A.5010308@iki.fi> References: <1411642565.16473.18.camel@kazak.uk.xensource.com> <1451d253.d45e.148acdce46e.Coremail.lelema.zh@gmail.com> <1411649722.2053.5.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1411649722.2053.5.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Lele MA Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 25/09/14 12:55, Ian Campbell wrote: > On Thu, 2014-09-25 at 20:50 +0800, Lele MA wrote: >> >>> AFAIK mini-os doesn't supply a POSIX thread API, correct. >>> >>> I don't think anything else in the current stubdom infra (e.g. newlib) >>> supplies one either. >>> >>>> If so, can I still use the glib in the Mini-OS without the support of >>>> "_POSIX_THREADS"? >>> >>> That would be a question for the glib maintainers. At a minimum I'd >>> expect you would need to port glib to the mini-os thread API. >>> >>> But, before you go down that route I think you should consider the new >>> rumpkernels work which is going on. >>> >>> rumpkernels run on a mini-os/Xen and provide a BSD derived POSIX like >>> environment, which I expect will include pthreads. Depending on your >>> application it may well be very worthwhile to start from that (I think >>> it most likely would be, but I don't know what you are actually doing). Yes, there's support for pthreads with rump kernels on Xen (uses unmodified NetBSD libpthread). >> Thank you so much! >> >> My ultimate goal is to use libvmi in mini-os. And libvmi needs glib's support. So I needs to cross-compile glib into mini-os firstly. >> >> The mini-os kernel is essential for our project, > > Note that rumpkernels use mini-os (or at least large parts of it) under > the hood. I'd strongly recommend you investigate rumpkernels before > embarking on any direct porting work. Yes, it uses minios in a sort of "firmware" sense. You can still access the underlying minios from applications running as part of rumprun-xen ... though generally speaking it's better to access things through one API instead of multiple. The application-side interfaces (POSIX, TCP/IP, etc.) offered by rumprun-xen are complete enough that off-the-internet applications have a good chance of "just working" without any porting. >> so I probably have to port the glib to mini-os thread API. Can you >> give me some tips on how to port a thread API ? > > I've no idea what it actually looks like, sorry. You'll probably need to > dize into the code. > >> I am a newbie to mini-os thread >> API, any help would appreciated. Thank you! If you really want to roll your own, you can check how libpthread for rumprun-xen is integrated: https://github.com/rumpkernel/rumprun-xen/blob/92b81fde24beb5dfaec1c2eec3960a61cc6dd5e0/lib/_lwp.c Note: the above implements the _lwp API of NetBSD, which is what NetBSD libpthread uses to control the kernel threads it manages. The integration points to minios should be quite clear, nonetheless: create_thread(), block(), wake(), schedule(), ... - antti