Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 16:31, Ævar Arnfjörð Bjarmason wrote: > I obviously much prefer #1, and I don't think it would harm kFreeBSD > users, what do you think? Has the Debian GNU/kFreeBSD port had many > issues due to differences in getpid()/getppid() behavior? I've pushed a patch implementing #1 to a branch: http://perl5.git.perl.org/perl.git/commitdiff/8c442cc912aa -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cacbzzx5afexa8e4kdjtncqx6hwcnnsd-j4vgmq4tbxahnbm...@mail.gmail.com
Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads
On Sun, Feb 12, 2012 at 15:16, Robert Millan wrote:
> El 12 de febrer de 2012 12:42, Niko Tyni ha escrit:
>> [crossposted to the Debian GNU/kFreeBSD development list debian-bsd
>> and the Perl 5 development list perl5-porters ]
>
> Thanks for bringing this up.
>
>>> This is also a complete non-issue in practice these days, LinuxThreads
>>> was a Linux 2.4 thread implementation that nobody maintains
>>> anymore[2], all modern Linux distros use NPTL threads which don't
>>> suffer from this discrepancy.
>
> This is not correct. LinuxThreads is only obsolete on GNU/Linux, but
> it is maintained and used on GNU/kFreeBSD because, contrary to what
> its name would indicate, it's a reasonably portable pthread library
> with few kernel-specific dependencies.
I'll adjust the commit message to mention that.
>> Under POSIX threads the getpid() and getppid() functions return the
>> same values across multiple threads, i.e. threads don't have their own
>> PID's. This is not the case under the obsolete LinuxThreads where each
>> thread has a different PID, so getpid() and getppid() will return
>> different values across threads.
>
> The version of LinuxThreads used on GNU/kFreeBSD has been patched to
> use kFreeBSD (kernel of FreeBSD) thread primitives, and thus future
> releases of Debian GNU/kFreeBSD will no longer be affected by this
> problem.
>
> Debian "Squeeze" release *IS* affected, however. It'd be better if
> you could wait at least until there's a new release before breaking
> compatibility with Squeeze users.
With this patch on top this passes tests on my 6.0 kFreeBSD machine:
diff --git a/t/op/getpid.t b/t/op/getpid.t
index 67a0f90..7688240 100644
--- a/t/op/getpid.t
+++ b/t/op/getpid.t
@@ -30,7 +30,16 @@ my $ppid2 : shared = 0;
new threads( sub { ($pid2, $ppid2) = ($$, getppid()); } ) -> join();
-# If this breaks you're either running under LinuxThreads or your
-# system doesn't have POSIX thread semantics.
-is($pid, $pid2, 'getpid() in a thread is the same as in the parent');
-is($ppid, $ppid2, 'getppid() in a thread is the same as in the parent');
+# If this breaks you're either running under LinuxThreads (and we
+# haven't detected it) or your system doesn't have POSIX thread
+# semantics.
+if ($^O =~ /^(?:gnukfreebsd|linux)$/ and
+(my $linuxthreads = qx[getconf GNU_LIBPTHREAD_VERSION 2>&1])
=~ /linuxthreads/) {
+chomp $linuxthreads;
+diag "We're running under $^O with linuxthreads <$linuxthreads>";
+isnt($pid, $pid2, "getpid() in a thread is different from
the parent on this non-POSIX system");
+isnt($ppid, $ppid2, "getppid() in a thread is different from
the parent on this non-POSIX system");
+} else {
+is($pid, $pid2, 'getpid() in a thread is the same as in the parent');
+is($ppid, $ppid2, 'getppid() in a thread is the same as in
the parent');
+}
However the return values of $$ and getppid() in threads on kFreeBSD
with linuxthreads will of course be different. I think that's a
feature as pointed out in the original commit message.
So here's what we can do:
1. We can take this patch as-is with that fix above on top, which
means that it'll pass tests everywhere but on Linux 2.4 and
kFreeBSD 6.0 $$ and getppid() will reflect the OS's idea, not our
POSIX emulation.
2. I could munge it (urghl) so this whole thing tries to detect
linuxthreads, and if they're there we try to cache the pid, this
means however that on Linux 2.4 users running embedded
PerlInterpreter that they fork (with e.g. uWSGI) will run into
subtle issues on Linux 2.4 and kFreeBSD 6.0.
I think in practice the number of users that'lle be harmed by the
caching will outnumber those that are harmed because they're
writing multithreaded Perl programs and relying on this particular
feature.
3. We can revert the un-caching of $$ and made everyone suffer the
edge cases for the sake of linuxthreads.
I obviously much prefer #1, and I don't think it would harm kFreeBSD
users, what do you think? Has the Debian GNU/kFreeBSD port had many
issues due to differences in getpid()/getppid() behavior?
Also what does it even mean that threads have pids? Can you kill(1)
threads individuall? Send signals to them that aren't sent to the
parent process etc?
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cacbzzx6vxdwrh65oerzttgguxsrhsdx3dzttpcpgsdtnhc6...@mail.gmail.com
Re: GNU/kFreeBSD debian-installer
On Wed, Aug 18, 2010 at 12:07, Aurelien Jarno wrote: > The current image is what is planned for the Squeeze release, we will > try to fix as many bugs as possible until it happens. Thanks. I just ran the mini.iso in VirtualBox on Ubuntu, it worked, although I used English for the installation language. The main thing that's missing is the keyboard selection. Having to figure out how to set the keyboard properly after installation (I can't even recall offhand how to do that on GNU/Linux) makes it somewhat less useful than the regular d-i. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim3urqxgtbrawvlhydwtkwof0izrwsk0yt_r...@mail.gmail.com
Re: any known-good installer ISOs?
On Wed, Aug 11, 2010 at 20:41, Brett Dikeman wrote: > Are there any known-good images? I tried mostly the AMD64 images, but > a few x86 images. No dice. Also, could someone please update the > Wiki to contain more current and accurate info for those of us looking > to dip our toes in? I've had success with the daily mini.iso images: http://d-i.debian.org/daily-images/kfreebsd-i386/daily/monolithic/mini.iso On Ubuntu with virtualbox-ose 3.1.6-dfsg-2ubuntu2 on 2.6.32-21-generic i686 GNU/Linux. Also try to disable the dual processor PAE/NX config. As I recall I had some issues with that, but I can't recall what exactly. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimpuzhm+t2nwzqnvbnepzlmtfpeqczb9ty...@mail.gmail.com
Re: Processed: Bug#559364: regression: console text is red: pending by 106_teken_op.diff
On Sat, Aug 7, 2010 at 11:24, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > >> tags 559364 + pending > Bug #559364 [kfreebsd-image-8.0-1-686] regression: console text is red > Added tag(s) pending. I'm not sure if this is the same issue, but I get orange text on startup with the 8.1 kernel: http://v.nix.is/~avar/fbsd-boot.png -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimbsvt2vfivtsfmozmfhiggeti4o7up95dm8...@mail.gmail.com
Re: Releasability of the kFreeBSD ports
On Thu, Aug 5, 2010 at 19:13, Ævar Arnfjörð Bjarmason wrote: > On Wed, Aug 4, 2010 at 17:52, Axel Beckert wrote: > >> * Emacs 23 via remote X doesn't work. No idea why yet. > > I haven't debugged it properly either, but the fix suggested in > #559392 of adding this to src/s/gnu-kfreebsd.h works: > > #define BROKEN_FIONREAD I spoke too soon. That makes everything I tried in X work, but the console Emacs is completely broken and doesn't accept any keyboard input with that. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimbnyg4g=penax43v2tnq78f3gx5d7tyf-s=...@mail.gmail.com
Re: Releasability of the kFreeBSD ports
On Wed, Aug 4, 2010 at 17:52, Axel Beckert wrote:
> * Emacs 23 via remote X doesn't work. No idea why yet.
I haven't debugged it properly either, but the fix suggested in
#559392 of adding this to src/s/gnu-kfreebsd.h works:
#define BROKEN_FIONREAD
That disables code paths like these in keyboard.c:
/* Determine how many characters we should *try* to read. */
#ifdef FIONREAD
/* Find out how much input is available. */
if (ioctl (fileno (tty->input), FIONREAD, &n_to_read) < 0)
And in sysdep.c:
#ifdef FIONREAD
status = ioctl (fd, FIONREAD, &avail);
#else /* no FIONREAD */
/* Hoping it will return -1 if nothing
available
or 0 if all 0 chars requested are read. */
if (proc_buffered_char[fd] >= 0)
avail = 1;
else
{
avail = read (fd, &buf, 1);
if (avail > 0)
proc_buffered_char[fd] = buf;
}
#endif /* no FIONREAD */
So perhaps it's some glibc or kernel bug related to ioctl()? This
issue is most likely not specific to Emacs.
Has anyone contacted upstream about this bug?
Here's some unrelated issues that I've run into with thu kFreeBSD port
thus far that I haven't found bugs for:
* The debian-installer doesn't ask for a keyboard layout.
* Almost no docs, for solving e.g. that issue. I only found out about
/etc/kbdcontrol.conf by asking around on IRC. This is to be
expected, but presumably needs to be fixed before it can go into
stable.
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikie9ddg=j3xg0dfoe42mrafwwyynhs9owi5...@mail.gmail.com
