tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: refine of the GSOC project

Hi Christos,

   I got the new list post below. Note that the second list is build with
-D_NETBSD_SOURCE -lpthread -lrt -lm
   and use netbsd-current, and disable compiler warnings. There are a lot
of errors that caused by linker flags,
compiler flags and kernel versions, but I guess we are not interested in
them. Also, I comment how do I fix them
for each of those errors. Let me know if you have questions.

*Errors that caused by feature missing*

   _SC_CPUTIME  (freebsd)
   _SC_THREAD_CPUTIME (freebsd)
   _SC_DELAYTIMER_MAX (freebsd)

   PTHREAD_PRIO_NONE   (freebsd)
   PTHREAD_STACK_MIN  (freebsd)
   pthread_barrierattr_getpshared  (freebsd)
   pthread_barrierattr_setpshared  (freebsd)
   pthread_mutexattr_setpshared  (freebsd)
   pthread_mutexattr_getpshared  (freebsd)
   pthread_condattr_setpshared (freebsd)
   pthread_condattr_getpshared (freebsd)
   pthread_condattr_getclock (freebsd)
   pthread_mutexattr_getprioceiling  (freebsd)
   pthread_mutexattr_setprioceiling  (freebsd)
   pthread_mutexattr_getprotocol (freebsd)
   pthread_mutexattr_setprotocol  (freebsd)
   pthread_rwlockattr_getpshared (freebsd)
   pthread_rwlockattr_setpshared  (freebsd)
   pthread_mutex_getprioceiling  (freebsd)
   pthread_mutex_timedlock (freebsd)

    SCHED_SPORADIC (linux)

    SIGPOLL (freebsd)
    SIGRTMIN (provided, but need to expose to userland)
    SIGRTMAX (provided, but need to expose to userland)
    _SC_REALTIME_SIGNALS (freebsd)
    _SC_SIGQUEUE_MAX  (freebsd)
    bsd_signal (linux)

    struct posix_typed_mem_info (linux)
    posix_mem_offset (linux)
    posix_typed_mem_get_info (linux)
    posix_typed_mem_open (linux)

    _SC_SEM_NSEMS_MAX  (freebsd)

*Errors that caused by usage*
(build with -D_NETBSD_SOURCE -lpthread -lrt -lm and disable compiler
warnings and use current)
struct rlimit (inlcude sys/resource.h)
setpgrp (netbsd needs to pass 2 parameters, but other systems, like like
linux does not)
struct sigaction sa (include signal.h)
sigfillset(&sa.sa_mask) (include signal.h)
sigaction(include signal.h)
SIGBUS (include signal.h)
sigfillset (include signal.h)
SIGSEGV (include signal.h)
PTHREAD_ONCE_INIT (need force the type to be pthread_once_t)
cpu_set_t (netbsd has its own implementation)
CPU_ZERO (netbsd has its own implementation)
CPU_SETSIZE (netbsd has its own implementation)
sched_setaffinity (netbsd has its own implementation)
pthread_setaffinity_np (caused by wrong parameters passed in, convert
parameter to be netbsd specific)
features.h (no features.h, actually netbsd does not need this file to be
correct, just removed)
SIGNAL (depends on macro which is not defined)
SIG_INVALID (depends on macro which is not defined)
SIGTOTEST  (depends on macro which is not defined)

2016-05-11 10:15 GMT-07:00 Charles Cui <>:

> Oh, yes, this sounds really reasonable to me.
> I will try to disable ACPI,  thanks!
> 2016-05-11 7:59 GMT-07:00 Christos Zoulas <>:
> > In article <CA+SXE9s48eSqzhSsZD1L8BO=Z7=
> > Charles Cui  <> wrote:
> >>some updates of building kernel.
> >>I spend some time these days to investigate the kernel compiling
> >>problem that I found earlier.
> >>I start from netbsd 7.0 -stable, and build a netbsd-current.
> >>After building tools, kernel modules, I found there are
> >>two folders, one is  /usr/<buildname>/tooldir.NetBSD-7.0_STABLE-i386,
> >>the other is /usr/<buildname>/tooldir.NetBSD-7.99.29-i386,
> >>after installing new kernels, when trying to install userland, it will
> >>report some binary tools cannot be found in the second folder, but
> >>these tools exist in the first folder. I copied the required tools
> >>over to the second folder, it install userland successfully.
> >>I guess in the new kernel, building tools again can also solve the
> problem.
> >>
> >>Although the kernel compiling problem is solved, I observed a kernel
> >>issue of netbsd-current.
> >>I used i386 arch on virtualbox, sometimes, it will tell me power
> >>button is pressed and the system is shutdown
> >>(I have attached the detailed info below). However, I never press the
> >>button. I experience this problem
> >>at least 10 times. To verify it is a netbsd-current problem, I
> >>installed a netbsd 7.0-stable kernel,
> >>and never experience this problem again.  So, I am wondering what's
> >>the kernel changes that cause this issue?
> >>This is not quite related to my projects, but definitely is good to
> >>let the community know.
> >
> > I have not seen exactly that, but I've seen recent versions of virtualbox
> > aggressively trying to shutdown my vm if the host has low battery. The
> > simple answer is to disable ACPI for now... It does not affect your tests
> > anyway. You can do this from the boot command line.
> >
> > christos
> >

Home | Main Index | Thread Index | Old Index