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