tech-kern archive

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

updating COMPAT_LINUX for linux 2.6.x support.



hi folks,

I've started looking at what it would take to update COMPAT_LINUX
to allow changing the emulated linux kernel version to 2.6.x.
my goal is to allow us to upgrade pkgsrc to newer versions of the
linux libraries and flash plugin that don't have all the security
problems that the current pkgsrc versions have.
I have several questions about all this:

(1) what linux distribution do we want in the pkgsrc packages?
    the tradition has been SUSE, so I assume we'll want to use SUSE 11.x?
    (tonio@ has volunteered to do the pkgsrc work if no one else wants to,
    once there's agreement on what to do.)

(2) what linux kernel version do we want to claim to be in uname?
    it would be good for this to be at least as recent as the
    kernel matching what we choose in (1).  but it would good to avoid
    going too wild with this, to keep the amount of new emul code
    that's needed to a minimum.

(3) what all needs to be done in COMPAT_LINUX to support the choice for (2)?
    my understanding is that the biggest problem area in general is
    pthread support.

    I tried running the netbsd libpthread regression tests on i386
    (built under fedora 12 and run with matching shared libs) and found
    several problems already:

    (a) mutex2 hangs.
        pthread_join() doesn't return even though the thread exits.
        I already checked in a fix for this (the arguments to
        linux_sys_clone() were wrong).  COMPAT_LINUX32 needs this
        as well, though I didn't check that in yet.

    (b) sigalarm and sleep1 hang.
        the signal and itimer state needs to be shared between linux threads.
        this is described in PR 37437.

    (c) siglongjmp1 hangs.
        the signal handler function isn't actually entered,
        instead the process goes into an infinite loop taking SIGSEGVs
        in the runtime linker.  the problem is that we don't mainain
        the per-thread %gs register correctly.

    (d) sem2, sigmask2 and sigmask3 dump core.
        this is caused by the same underlying problem as (c).


    then I tried running the pthread tests in LTP (which are really
    from http://posixtest.sourceforge.net/), and this shows more problems
    (which I haven't analyzed as much as yet).

    I tried following the suggestion in PR 37437 (moving the ps_sigignore
    and ps_sigcatch fields from struct sigctx to struct sigacts, which is
    shared between linux threads), and I moved p_sigpend from struct proc
    to struct sigacts as well.  this, together with other fixes allows
    all of the netbsd libpthread regression tests to pass (except the one
    that also fails natively on linux), and gives much improved results
    on the LTP/posixtest tests.  I put my current diff (still larded with
    debug stuff and with linux stuff hardcoded instead of called through
    new emul callbacks) in:
        ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl.4

    before continuing down this path, I was wondering if it would be
    possible to move from the current way of supporting linux threads
    (each linux thread is a separate netbsd process, with extra sharing
    happening behind the scenes) to the native netbsd way (1 process with
    multiple LWPs)?  the only problem I can think of is that something
    might assume that linux thread IDs are globally unique, or that the
    thread ID of the original thread is the same as the process ID.
    but that seems a bit unlikely, since I don't see any place that the
    linux thread ID is used (thought I could easily have missed that).
    does anyone know of any reason why this wouuldn't work?


    does anyone know of other work that needs to be done on COMPAT_LINUX
    before we can usefully report ourselves as 2.6.x?


-Chuck


Home | Main Index | Thread Index | Old Index