tech-userlevel archive

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

Re: refine of the GSOC project

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.

   _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)

2016-05-08 19:19 GMT-07:00 Thor Lancelot Simon <>:
> 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 command with the old
>> > tooldir name or make a symlink from the old tooldir name to the new one.
>> >
>> Why not just " tools" to regenerate the tools for the new
>> kernel version?  Or USETOOLS=NO if it is something quick and dirty...
> Why not " 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

Home | Main Index | Thread Index | Old Index