From 6f9c0342f33f52a2bda98d3709fbefd678bd46d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 06:06:11 +0200 Subject: IRC. --- open_issues/packaging_libpthread.mdwn | 114 ++++++++++++++++++++++++++++------ 1 file changed, 96 insertions(+), 18 deletions(-) (limited to 'open_issues/packaging_libpthread.mdwn') diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index fa3d4312..f8ef4ae7 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,9 +11,13 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread open_issue_glibc]] -IRC, #hurd, 2010-07-31 +[[!toc]] - My idea was to have a separate libpthread package. What do you think about that? + +# IRC, freenode, #hurd, 2010-07-31 + + My idea was to have a separate libpthread package. What do you + think about that? in the long term, that can't work with glibc because of the thread stub stuff @@ -21,30 +26,103 @@ IRC, #hurd, 2010-07-31 it's not really possible to keep synchronized because you have to decide which package you unpack first (when upgrading) - Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? ... for incompatible forward changes? that'd be a mess to maintain - Drepper doesn't have this constraint and thus adds members of private fields at will - OK, but how is it different then if the libpthread is in the Hurd package? + Drepper doesn't have this constraint and thus adds members of + private fields at will + OK, but how is it different then if the libpthread is in the + Hurd package? I'm not saying it's better to have libpthread in the Hurd package OK. - I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc Then, to goal is to have it in glibc? OK. :-) - OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. - So our official goal is to have libpthread in glibc, at least for Debian purposese? + OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + So our official goal is to have libpthread in glibc, at least + for Debian purposese? for any port purpose Ack. - provided you're using glibc, you're deemed to ship libpthread with it + provided you're using glibc, you're deemed to ship libpthread with + it because of the strong relations Drepper puts between them - (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) - yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used (would be nice to not have those issues anymore...) - So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) - Does that sound about right, or am I missing something fundamental? + So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + Does that sound about right, or am I missing something + fundamental? I actually don't know what a git submodule permits :) looks like a good thing for this, yes - Unfortunately I can't allocate much time at the moment to work on this. :-/ - well, as long as I know where we're going, I can know how to package stuff in Debian - That sounds like a plan to me. libpthread -> glibc as submodule. - (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) + Unfortunately I can't allocate much time at the moment to work + on this. :-/ + well, as long as I know where we're going, I can know how to + package stuff in Debian + That sounds like a plan to me. libpthread -> glibc as + submodule. + (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + had you tried to build libpthread as a glibc addon? + youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + k + I'm trying it atm + Oh, OK. + that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + (once I add forward.c, but that part should not be hard) + that means also less use of pthread-stubs^ + ? + tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + also, any reason for using ia32 and not i386? glibc uses the latter + pinotree: rid of pthread-stubs yes + \o/ + youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + I'm talking about libpthread + not glibc + Oh. + sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + Anyway, no idea about that either. + that one is meant to be used with the spin-lock.h just below + +-inline + also, I guess signal/ was for the l4 port? + youpi: I guess so. + tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + we don't have a non-mach sysdeps directory? + youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + ah, right + youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + pinotree: it worked, it was for libpthread + good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + phew + confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue -- cgit v1.2.3 From b75e038615d51cb62c200e336e59202519db8cae Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 22:36:45 +0800 Subject: IRC. --- open_issues/file_system_exerciser.mdwn | 16 +++++++++++++- open_issues/glibc.mdwn | 29 +++++++++++++++++++++++++ open_issues/gnumach_rpc_timeouts.mdwn | 19 ++++++++++++++++ open_issues/gnumach_vm_map_red-black_trees.mdwn | 12 ++++++++++ open_issues/largefile.mdwn | 21 ++++++++++++++++++ open_issues/packaging_libpthread.mdwn | 11 ++++++++++ 6 files changed, 107 insertions(+), 1 deletion(-) create mode 100644 open_issues/gnumach_rpc_timeouts.mdwn create mode 100644 open_issues/largefile.mdwn (limited to 'open_issues/packaging_libpthread.mdwn') diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn index 4277e5e7..c51863b9 100644 --- a/open_issues/file_system_exerciser.mdwn +++ b/open_issues/file_system_exerciser.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -13,3 +13,17 @@ License|/fdl]]."]]"""]] Test our file system implementations with the File System Exerciser. * + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + mcsim: http://sourceforge.net/projects/fsmark/ + mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + (and in general to test fs'es) diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 6c52cc7f..1ce47560 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -189,6 +189,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, `setns`, `sync_file_range` + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + I get the same error on FreeBSD, but including sys/stat.h + makes it work + Can't find a solution on Hurd though :/ + the Hurd doesn't have chflags + apparently linux neither + what does it do? + change flags :) + Are you sure the Hurd does not have chflags ? Because gcc + does not complain + there is no chflags function in /usr/include + but what flags does it change? + According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + Hum, there is actually a chflags() definition + but no declaration + so actually chflags is supported, but the declaration was + forgotten + probably because since linux doens't have it, it has never + been a problem up to now + so I'd say ignore the error for now, we'll add the + declaration + * `getcontext`/`setcontext` Needed for [[gccgo]]. diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + it seems that how ticks are calculated in mach, it becomes 0 + +because of diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn index d77bea32..17263099 100644 --- a/open_issues/gnumach_vm_map_red-black_trees.mdwn +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -140,3 +140,15 @@ License|/fdl]]."]]"""]] i'll commit it soon then I'd say feel free to, yes thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + i kind of understood why (at least in some parts) largefile doesn't seem to work properly + libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + diskfs.h is a public header though :/ + well, we can change the soname to mark ABI change diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index f8ef4ae7..d243aaaa 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -126,3 +126,14 @@ License|/fdl]]."]]"""]] phew confirmed that moving libpthread to glibc fixes the gcc/binutils no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + I know, I've asked tschwinge about it + it's not urging anyway + right -- cgit v1.2.3