Thanks guys for all your advices! I will try the methods proposed by
you guys and let you know once I have new results.
Right now, my way (install kernel and userland together) works (It
takes kernel and libc updates and generate expected results.) This is
the updated list (much shorter than before) that I need to contribute
to. I have make an annotation for each feature. (freebsd) means
freebsd implements it, but we did not. (linux) means freebsd and
netbsd do not implement, but linux implements.
timers:
_SC_CPUTIME (freebsd)
_SC_THREAD_CPUTIME (freebsd)
_SC_DELAYTIMER_MAX (freebsd)
pthreads:
PTHREAD_PRIO_INHERIT (freebsd)
PTHREAD_PRIO_NONE (freebsd)
PTHREAD_PRIO_PROTECT (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)
scheduler:
SCHED_SPORADIC (linux)
signals:
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)
mmap:
POSIX_TYPED_MEM_ALLOCATE (linux)
POSIX_TYPED_MEM_ALLOCATE_CONTIG (linux)
POSIX_TYPED_MEM_MAP_ALLOCATABLE (linux)
struct posix_typed_mem_info (linux)
posix_mem_offset (linux)
posix_typed_mem_get_info (linux)
posix_typed_mem_open (linux)
semaphore
_SC_SEM_NSEMS_MAX (freebsd)
2016-05-08 19:19 GMT-07:00 Thor Lancelot Simon <t...@panix.com>:
> On Mon, May 09, 2016 at 10:58:50AM +0930, Brett Lymn wrote:
>> On Mon, May 09, 2016 at 12:53:02AM +0000, Christos Zoulas wrote:
>> >
>> > Heh that's funny. He should then run the build.sh command with the old
>> > tooldir name or make a symlink from the old tooldir name to the new one.
>> >
>>
>> Why not just "build.sh tools" to regenerate the tools for the new
>> kernel version? Or USETOOLS=NO if it is something quick and dirty...
>
> Why not "build.sh release", followed by installing the kernel, rebooting,
> and extracting the already made sets files (all but etc.tgz) using tar with
> -p or pax with -p e, followed by postinstall -s etc.tgz fix? Is there any
> reason to do this in a less simple, less sane way?
>
> Thor
