misread the specification, thanks for correcting.
--
Richard Braun
On Tue, Nov 12, 2013 at 02:34:18PM +0100, Richard Braun wrote:
> Right, I misread the specification, thanks for correcting.
FYI, this means we currently have a bug with regard to that : after the
main thread calls pthread_exit(), and thread destruction is actually
implemented (as opposed to
On Tue, Nov 12, 2013 at 12:39:40PM +0100, Samuel Thibault wrote:
> Richard Braun, le Tue 12 Nov 2013 11:56:05 +0100, a écrit :
> > It's not a rotation, merely a variable swap,
>
> Ok, but below the comment says
>
> /* Node is the left child of its parent. */
>
>
r stuff like mach_port_allocate?
Yes, but I guess such occurrences are rare.
> 3. libihash/ihash.c includes . Shouldn't it include
>"ihash.h" instead, so that it gets the local version instead of the
>one in /usr/include?
It probably should, yes.
--
Richard Braun
struction isn't only
meant to reduce resource usage after peaks, but also to fix those bugs.
I guess we can merge your changes however, since they're not conflicting
at all. With the fix Samuel mentioned, it should be fine.
--
Richard Braun
On Sat, Nov 16, 2013 at 04:39:01PM +0100, Marin Ramesa wrote:
> I assumed it's inconvinient for people to suddenly find 32 messages in
We think of it (and our viewers make us see it) as one thread, not 32
messages.
--
Richard Braun
The following changes actually apply to Debian eglibc 2.17-96 sources,
and aren't meant to be pushed as such, but rather to review the various
solutions added to support thread termination.
The current state is to never terminate threads, on the assumption that
they can't both terminate and releas
On Sun, Nov 17, 2013 at 09:41:03PM +0100, Samuel Thibault wrote:
> Richard Braun, le Sun 17 Nov 2013 17:13:23 +0100, a écrit :
> > This patch makes use of a new GNU Mach specific call
> > (thread_terminate_release [1]) so that threads do terminate themselves
> > and releas
On Sun, Nov 17, 2013 at 05:13:23PM +0100, Richard Braun wrote:
> The following changes actually apply to Debian eglibc 2.17-96 sources,
Binary packages are available for testing on my repository :
deb http://ftp.sceen.net/debian-hurd-i386 experimental/
Install gnumach first, then glibc, t
On Mon, Nov 18, 2013 at 11:33:55AM +0100, Neal H. Walfield wrote:
> Richard Braun wrote:
> > The current state is to never terminate threads, on the assumption that
> > they can't both terminate and release their stack on their own. Such
> > resources are recycled by th
On Mon, Nov 18, 2013 at 04:22:06PM +0100, Samuel Thibault wrote:
> Richard Braun, le Sun 17 Nov 2013 17:13:23 +0100, a écrit :
> > Two resources are still recycled: the internal pthread structure
> > (because it makes ID allocation easy), and thread local storage (TLS)
> > bec
to zero.
> >
> > Analyzers will probably prefer that indeed.
>
> So there is a good reason for this kind of initialization (int x = x)?
It was done on purpose, yes. It tells GCC to consider the variable
initialized, and is useful to silence warnings when the code is valid.
--
Richard Braun
he same time.
I'm not sure to grasp the relation between this patch and deadlock
avoidance. I also don't see what's wrong with generating data at open
time.
--
Richard Braun
On Wed, Nov 20, 2013 at 01:18:17PM +0100, Justus Winter wrote:
> Quoting Richard Braun (2013-11-20 12:13:20)
> > I'm not sure to grasp the relation between this patch and deadlock
> > avoidance. I also don't see what's wrong with generating data at open
&
this comparison. Everything looks good to me
> now. Here's the warning:
>
> cc1: warning: assuming signed overflow does not occur when assuming
> that (X - c) <= X is always true [-Wstrict-overflow]
Remove your explicit cast, make K_DONE an unsigned.
--
Richard Braun
On Mon, Dec 09, 2013 at 11:07:46AM +0100, Marin Ramesa wrote:
> On 09.12.2013 11:00:12, Richard Braun wrote:
> > On Mon, Dec 09, 2013 at 08:20:11AM +0100, Marin Ramesa wrote:
> > > On 08.12.2013 15:25:42, Samuel Thibault wrote:
> > > > Marin Ramesa, le Mon 02 De
nsigned int and
the warning disappeared.
--
Richard Braun
On Wed, Dec 11, 2013 at 05:30:43PM +0100, Marin Ramesa wrote:
> - ipc_mqueue_t mqueue;
> + ipc_mqueue_t mqueue = mqueue; /* Quiet GCC warning. */
Don't do that. Instead, tweak simple_unlock and similar functions this
way :
#define simple_unlock(l) ((void)(l))
--
Richard Braun
On Wed, Dec 11, 2013 at 09:07:38PM +0100, Marin Ramesa wrote:
> On 11.12.2013 18:02:50, Richard Braun wrote:
> > On Wed, Dec 11, 2013 at 05:30:43PM +0100, Marin Ramesa wrote:
> > > - ipc_mqueue_t mqueue;
> > > + ipc_mqueue_t mqueue = mqueue; /* Quiet GCC warning. */
>
eimplement strlen inline, and I also don't
understand why you assume the data to be null-terminated.
--
Richard Braun
On Sat, Dec 14, 2013 at 01:32:27PM +0100, Marin Ramesa wrote:
> On 14.12.2013 12:45:32, Richard Braun wrote:
> > I really don't see a problem in that code, you'll have to describe it
> > better.
>
> So a pointer to io_data is cast to a pointer to a vm_map_copy
On Sun, Dec 15, 2013 at 02:43:50PM +0100, Marin Ramesa wrote:
> On 15.12.2013 14:00:22, Richard Braun wrote:
> > What makes you think the content could be something else than a
> > vm_map_copy object ?
>
> Well io_data is a pointer to char, not a pointer to vm_map_copy. An
you mention it, the lock semantics
are actually what matter most here with regard to code ordering, and
they actually reduce the effectiveness of optimizations.
--
Richard Braun
please, learn from experience and don't try to
overengineer. Keep it simple, limit yourself to cleaning the code, not
making it more complicated (and then dirtier) than it could be.
--
Richard Braun
t's wrong. The && and || operators are guaranteed to be evaluated
left-to-right, and yield if the first operand compares equal to 0. And
that's exactly why this check against NULL is done first.
--
Richard Braun
On Wed, Dec 18, 2013 at 10:46:40AM +0100, Richard Braun wrote:
> On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
> > Compiler needs to check both !a and !b. In order to evaluate !b it must
> > evaluate b. So when the code path is that when entry is a null po
On Wed, Dec 18, 2013 at 10:55:47AM +0100, Marin Ramesa wrote:
> On 18.12.2013 10:46:40, Richard Braun wrote:
> > No, that's wrong. The && and || operators are guaranteed to be
> > evaluated left-to-right, and yield if the first operand compares
> > equal to 0.
age(actual * sizeof *info);
> kr = kmem_alloc_pageable(ipc_kernel_map, &addr, size);
> if (kr != KERN_SUCCESS)
> return KERN_RESOURCE_SHORTAGE;
--
Richard Braun
On Wed, Dec 18, 2013 at 09:17:49AM +0100, Marin Ramesa wrote:
> The same situation as the previous patch.
Same comment as for the previous patch.
--
Richard Braun
TRUE));
>
> GCC stops complaing about uninitialized variable.
I don't get this warning, can you tell us how you configure GNU Mach ?
--
Richard Braun
On Wed, Dec 18, 2013 at 11:40:09AM +0100, Marin Ramesa wrote:
> On 18.12.2013 11:34:03, Richard Braun wrote:
> > I don't get this warning, can you tell us how you configure GNU
> > Mach ?
>
> --enable-kdb --prefix=
>
> But the warning is turned off by:
>
&g
On Sat, Dec 21, 2013 at 10:55:14PM +0100, Marin Ramesa wrote:
> I noticed some bugs. I'm sending a fixed patch. The prevoius version is here:
> http://lists.gnu.org/archive/html/bug-hurd/2013-12/msg00493.html
How about adding everything necessary to actually test it from
userspace ?
right of your
contributions to the FSF.
The slab allocator did not originate from GNU Mach and its history is a
bit messy. It is really not a good template for contributions.
--
Richard Braun
On Sat, Dec 21, 2013 at 11:29:34PM +0100, Marin Ramesa wrote:
> On 21.12.2013 23:20:43, Richard Braun wrote:
> > How about adding everything necessary to actually test it from
> > userspace ?
>
> Sure, what needs to be added? I don't have the conditions to test this.
&g
On Sun, Dec 22, 2013 at 03:32:42PM +0100, Marin Ramesa wrote:
> On 22.12.2013 01:28:37, Richard Braun wrote:
> > On Sat, Dec 21, 2013 at 11:29:34PM +0100, Marin Ramesa wrote:
> > > On 21.12.2013 23:20:43, Richard Braun wrote:
> > > > How about adding everything nece
On Sun, Dec 22, 2013 at 06:22:03PM +0100, Marin Ramesa wrote:
> On 22.12.2013 17:56:32, Richard Braun wrote:
> > Test it yourself from userspace before you resubmit.
>
> That's the problem. I don't know how to test this. How to boot up a
> modified gnumach and then
On Sun, Dec 22, 2013 at 06:57:50PM +0100, Marin Ramesa wrote:
> On 22.12.2013 18:25:10, Richard Braun wrote:
> > Are you saying you've been sending us patches without ever
> > testing them ?
>
> Yes. But that's different, that's just cleaning the code. Removin
On Sun, Dec 22, 2013 at 06:22:03PM +0100, Marin Ramesa wrote:
> On 22.12.2013 17:56:32, Richard Braun wrote:
> > > OK, I'm reading the documentation. In the meantime I have defined
> > > several simple RPCs for testing purposes. I will send the updated
> > &
On Sun, Dec 22, 2013 at 11:56:39PM +0100, Marin Ramesa wrote:
> Can you please show me the gnumach menuentry generated by grub?
How about looking at the documentation ? For example
http://www.gnu.org/software/grub/manual/grub.html#GNU_002fHurd
--
Richard Braun
On Sun, Dec 22, 2013 at 11:56:39PM +0100, Marin Ramesa wrote:
> On 22/12/13 22:04:15, Richard Braun wrote:
> > Whether it's in a virtual machine or a real one doesn't matter at
> > all. On Debian, simply copy the gnumach binary to /boot and run
> > update-grub.
question: why are you working on this ? Considering the
beginner mistakes you did at the C level itself, and that you've never
even run a real GNU Mach instance, what makes you think you have the
proper experience to work on such a low-level tool that involves both
virtual memory and concurrency, two of the most difficult domains in
computer science ?
--
Richard Braun
n't want to cause
> any trouble.
For now, I'm the only one reacting to this, not much of a trouble.
But I'm pretty sure we would all like contributors to pay great care
to what they're doing, whatever their technical level.
--
Richard Braun
(except if bounded) is
unacceptable.
Then, why a scan through vm_objects ? Why not directly find the one
futex associated with a (map, address) and wake all threads waiting
on it ?
Also, why pass a number of threads to wake ? Why not simply choose
between one or all ?
--
Richard Braun
change we've had until now is 1/ you do something wrong 2/ I
tell you it's wrong 3/ you justify why you did something wrong without
making the effort to reconsider 4/ I show you it's definitely wrong
5/ you end up agreeing. Let's make it a 3-step process.
--
Richard Braun
,
extensively document the API in the header, e.g. as it's done for the
slab allocator. I also suggest moving everything not public (such as
the hash table) in the .c file, and if there is anything private that
still needs to be in a header, move that to a _i.h file ("i" could mean
internal/implementation/inline/whatever), so that the main header only
documents the public API.
--
Richard Braun
On Thu, Dec 26, 2013 at 02:58:01PM +0100, Richard Braun wrote:
> I know this isn't the traditional way to do it in Mach, but please,
> extensively document the API in the header, e.g. as it's done for the
> slab allocator. I also suggest moving everything not public (such
On Thu, Dec 26, 2013 at 03:15:24PM +0100, Marin Ramesa wrote:
> I get segfaults in kalloc(). I don't know what I'm doing wrong.
Show us how you use it.
--
Richard Braun
rongly suspect kalloc does what you want it to do, but something
in your code makes an illegal access. In the worst case, use prints
to find the faulty instruction.
--
Richard Braun
This change makes libpthread release almost every resource allocated for
a thread, including the kernel thread, its send right, its reply port
and its stack. This improves resource usage after peaks of activity
during which servers can create hundreds or even thousands of threads.
To achieve it, t
On Thu, Dec 26, 2013 at 05:44:56PM +0100, Samuel Thibault wrote:
> "loses", actually :)
> (and ditto further down)
Right, thanks.
--
Richard Braun
vm_map_lookup(thread->map, (vm_offset_t)futex->address,
> VM_PROT_READ, thread->version, thread->object,
> + thread->offset, thread->out_prot,
> thread->wired) != KERN_SUCCESS)) {
> + kfree((vm_offset_t)thread, sizeof(struct futex_thread));
> + return FUTEX_MEMORY_ERROR;
> + }
Futexes are only concerned with (map, address) pairs, why are
VM objects involved ?
> +++ b/kern/futex.h
The public header should at least define struct futex as an opaque type.
> +++ b/kern/futex_i.h
You didn't use the private header correctly. What you put into it
should instead be declared as static functions inside the .c file.
There are undoubtedly other problems but I don't have the time nor
the motivation to look through them now. If you really insist on this
task, you should really, really, REALLY get better with the basics
first. There are just too many mistakes here to do anything with that
patch.
--
Richard Braun
On Fri, Dec 27, 2013 at 07:55:02PM +0100, Marin Ramesa wrote:
> On 12/27/2013 07:14:40 PM, Richard Braun wrote:
> >What do you mean when you say you test on the Hurd and Linux ? How do
> >you use GDB with Mach to determine it's actually kalloc thta
> >segfaults ?
>
On Fri, Dec 27, 2013 at 10:23:01PM +0100, Marin Ramesa wrote:
> On 12/27/2013 09:58:07 PM, Richard Braun wrote:
> >Do you mean you're expecting kalloc() to actually work in a POSIX
> >environment ?
>
> I expected it to work on Hurd running gnumach, but I don'
On Sat, Dec 28, 2013 at 02:30:01AM +0100, Marin Ramesa wrote:
> On 12/27/2013 07:14:40 PM, Richard Braun wrote:
> >> +void futex_cross_address_space_wake(futex_t futex, boolean_t
> >wake_all)
> >> +{
> >> + #define min(x, y) (x <= y ? x : y)
> >&
passed address
> + *
> + */
> +extern int futex_wake(int *address, boolean_t wake_all);
> +
> +/*
> + * Function: futex_hash_table_setup()
> + *
> + * Setup of the global hash table.
> + *
> + * Returns:
> + * FUTEX_RESOURCE_SHORTAGE - allocation of the hash table has failed
> + * 0 - success
> + *
> + */
> +int futex_hash_table_setup(void);
Rename that to futex_setup. The caller should not know what happens
internally.
As a general rule, rewrite the description of the API to extensively
describe the behaviour. I personally don't recommend listing the return
codes, as it can easily change without being maintained. List a return
code only when it's special and important enough that it needs to be
mentioned. The description of the behaviour is far more important.
Also, how do you intend to handle timed waits ?
Last, but not least, when are futex objects released ?
--
Richard Braun
On Tue, Dec 31, 2013 at 04:26:01PM +0100, Richard Braun wrote:
> On Sun, Dec 29, 2013 at 09:44:51PM +0100, Marin Ramesa wrote:
> > + simple_lock(&futex->futex_wait_lock);
> > +
> > + /* If the value is still the same. */
> > + if
l scripting, understanding of C, and anything else?
Operating system knowledge from the userspace point of view, essentially
system calls, address space layout, and a decent grasp on the Mach and
Hurd concepts.
--
Richard Braun
ine to me, although I'm usually not keen on micro
optimizations before fixing system encompassing design issues :).
--
Richard Braun
ruct sync_circle *scircle);
> +int sync_circle_signal(struct sync_circle *scircle);
> +
> +/* Simple mutex implementation based on futex calls and GCC builtins. */
> +struct simple_mutex {
> +
> + #define SMUTEX_UNLOCKED 0
> + #define SMUTEX_NO_WAITERS 1
> + #define SMUTEX_WAITERS 2
> +
> + int value;
> +
> +};
> +
> +#define decl_simple_mutex(class, name) \
> +class struct simple_mutex name;
> +
> +void simple_mutex_init(struct simple_mutex *smutex);
> +void simple_mutex_lock(struct simple_mutex *smutex);
> +void simple_mutex_unlock(struct simple_mutex *smutex);
What does all this have antyhing to do in the public header ?
> @@ -158,6 +159,8 @@ void setup_main(void)
> recompute_priorities(NULL);
> compute_mach_factor();
>
> + futex_setup();
> +
Well, you got that one right, but I suppose it won't be needed once all
the other changes are made, since there should be no globally shared
structure after that point.
--
Richard Braun
On Mon, Jan 06, 2014 at 12:34:32PM +0100, Richard Braun wrote:
> > +static struct rbtree futex_tree;
>
> http://lists.gnu.org/archive/html/bug-hurd/2013-12/msg00545.html :
> "Personally, I'd use a per-task red-black tree".
>
>
On Tue, Jan 07, 2014 at 09:29:45AM +0100, Marin Ramesa wrote:
> On 01/06/2014 03:00:35 PM, Richard Braun wrote:
> >We also need to make sure nothing bad happens to an (object, offset)
> >pair when, say, copy-on-write is performed by the VM system...
>
> I'll add a chec
est. What needs to be tested is:
This does look much better, but there is still quite some work to be
done before it gets right. I'll send a detailed review later.
--
Richard Braun
.h it would seem that you can apply the attribute directly
> to the structure, thus even avoiding the typedef altogether?
Yes, that's the preferred way.
--
Richard Braun
ct simple_mutex *smutex)
> +{
> + int c;
> +
> + if ((c = __sync_val_compare_and_swap(&smutex->value, SMUTEX_UNLOCKED,
> SMUTEX_NO_WAITERS)) != SMUTEX_UNLOCKED) {
> + if (c != SMUTEX_WAITERS)
> + c = __sync_lock_test_and_set(&sm
id of it.
> Secondly, you are calling the macro ARRAY_SIZE with pfutexes as
> parameter. This will be evaluated to 0. Here's why:
Simply put, ARRAY_SIZE() is intended for statically allocated arrays
where the size is known at compile time. Don't use it on pointers.
But again, since there shouldn't be an array in the first place, this
function should be entirely reworked.
--
Richard Braun
On Thu, Jan 09, 2014 at 05:06:09PM +0100, Marin Ramesa wrote:
> On 01/09/2014 03:45:35 PM, Richard Braun wrote:
> >> +/* TODO Should be per-task. */
> >> +static struct futex *pfutexes;
> >
> >Most locks are private, so yes, do work on that too.
>
> I ac
On Thu, Jan 09, 2014 at 05:52:21PM +0100, Richard Braun wrote:
> On Thu, Jan 09, 2014 at 05:06:09PM +0100, Marin Ramesa wrote:
> > >> +simple_lock(&futex_shared_lock);
> > >> +
> > >> +
On Thu, Jan 09, 2014 at 09:51:51PM +0100, Marin Ramesa wrote:
> On 01/09/2014 05:52:21 PM, Richard Braun wrote:
> >On Thu, Jan 09, 2014 at 05:06:09PM +0100, Marin Ramesa wrote:
> >> Shouldn't the compare be atomic. Maybe I don't understand what
> >> atomic real
On Fri, Jan 10, 2014 at 08:28:12AM +0100, Marin Ramesa wrote:
> On 01/10/2014 01:59:55 AM, Richard Braun wrote:
> >On Thu, Jan 09, 2014 at 09:51:51PM +0100, Marin Ramesa wrote:
> >> On 01/09/2014 05:52:21 PM, Richard Braun wrote:
> >> >On Thu, Jan 09, 2014 at 05:06:
ions, we may be long to answer, in particular during work/week
ends/holidays, so let your client lurk there a few hours/days at least.
--
Richard Braun
e timeout parameter type, despite your claim for a
"final version". And worst of all, you dare claim "everything works".
You clearly have little clue about what you're actually doing, and don't
make the effort to check your assumptions and learn. I won't review any
more of your work.
--
Richard Braun
earning effort instead ?
--
Richard Braun
it's done for practically every system. So in practice, setting some
user data and accessing it from the kernel soon after will succeed most
of the time because writing the content will cause page faults if
needed, after which the kernel can simply read it.
That is how e.g. mach_print is able to do its job, although, for this
special call, it was done on purpose to avoid the VM system (since it's
a debugging call).
--
Richard Braun
(object, offset), depending on the
futex type (private, shared, respectively). Problems I can see with that
approach are :
- do we have to check that shared futexes refer to shareable memory ?
- if so, how to make that check reliably ?
- what happens when unmapping a futex ?
- does copy-on-right have any effect on a private futex - if implemented
as a (map, address) pair, I imagine it wouldn't, but is it true ?
These are the kind of things I was hoping to discuss with this patch.
--
Richard Braun
doing it. We can't really fight that.
Null-terminated strings is what people will naturally expect and have
in mind while reading/editing the code. Doing things differently for
something like mere names isn't worth the trouble.
--
Richard Braun
payload of 0. It could be worth
emphasizing that 0 is an invalid value for a protected payload.
--
Richard Braun
shed that as a project idea [1], I'm quite happy to
see it happening. Very good job again, Justus.
--
Richard Braun
[1]
http://www.gnu.org/software/hurd/community/gsoc/project_ideas/object_lookups.html
ip_msgcount;
> mach_port_msgcount_t ip_qlimit;
> struct ipc_thread_queue ip_blocked;
> + unsigned long ip_protected_payload;
> };
Increasing the port structure size by 4 bytes for a single bit is a
little frustrating. Instead, how about storing that bit in
ip_target.ipt_object.io_bits, right next to IO_BITS_ACTIVE ?
--
Richard Braun
ipc ports. */
> +#define IO_BITS_PROTECTED_PAYLOAD 0x4000 /* pp set? */
Thanks :-).
--
Richard Braun
ackages to track the experimental
branch until the changes are merged in the official repository.
Enjoy.
--
Richard Braun
[1]
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Define-_PR_HAVE_SOCKADDR_LEN-for-the-Hurd.patch;att=1;bug=739658
;d and they appear correct.
You set hd0s2 to type ext3.
--
Richard Braun
On Sat, Mar 01, 2014 at 12:13:18PM +0800, Zhang Cong wrote:
> 1. Crash once for clipboard assert=NULL?, I lost the detail.
Please try to reproduce, or at least give more details about what you
did before the crash occurred.
--
Richard Braun
h the details. You need to understand the general
architecture of the Hurd, and then dig in libdiskfs/libfshelp and the
ext2fs translator, I suppose. It is definitely a Hurd bug, which may
require development (i.e. it may be a feature missing, not a mere bug).
Unless I'm mistaken
th "configure.ac" and adding
it in a series file is enough ?
--
Richard Braun
else that could benefit of being reconfigured?
Honestly, I'm not sure you'll get help for such a specific problem. The
failed reinstall, though, is more troubling (and then interesting). I
suggest you reattempt to reinstall, and use the other virtual terminals
to check the status of the system if reinstallation fails again.
--
Richard Braun
x27;s strongly advised to use separate / and /home
partitions.
--
Richard Braun
r issue
is one project we'd very much appreciate mentoring.
--
Richard Braun
Hello,
Apparently, the deadline for proposals is tomorrow (March 21). Students
indenting to participate should be careful not to miss it.
--
Richard Braun
On Sun, Mar 30, 2014 at 07:40:50PM +0200, Justus Winter wrote:
> here is another prototype of mine, also employing a
> source-transformation, that can detect port leaks:
Well, that's impressive, once more. Excellent job.
--
Richard Braun
ct or others, I've never actually seen
or felt in any way any of these advantages in practice, but I've hit
the issues many times...
--
Richard Braun
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote:
> I intend to regularly update these packages to track the experimental
> branch until the changes are merged in the official repository.
Iceweasel 28.0-1 and NSPR 4.10.4 are now available.
--
Richard Braun
r bug in libbpf but I didn't
investigate yet.
--
Richard Braun
[1]
http://darnassus.sceen.net/~rbraun/0001-Debian-GNU-Hurd-with-NETDDE-support.patch
On Thu, Apr 10, 2014 at 02:01:17AM +0200, Richard Braun wrote:
> The first issue that can be noticed is that, despite the filter being
> filled with both NETF_IN and NETF_OUT, only incoming packets seem
> to be captured. This is probably a minor bug in libbpf but I didn't
> inve
ket filters, even if there
is no filter installed. If someone wants to work on optimizing this,
feel free to do it, but please mind the details because that's where
the tricky bugs will come from.
--
Richard Braun
; found in glibc like "lowlevellock.h",
>
> Mmm, if it's only headers, wouldn't it be possible to install just them?
Keep in mind that, when boostrapping toolchains, it is common practice
to install headers only, and build partially in multiple stages until
the final versoin is obtained.
--
Richard Braun
rough null pointers, e.g. it
could even be 64 or 128 KiB. We could alter glibc so that the first
mapping has this special size, and have munmap override its given range
to skip that area.
--
Richard Braun
s I could freeze a file system by merely writing to it (e.g.
with dd) and interrupting with Ctrl-C.
But it's certainly on the right path and shouldn't be far from being
reliable (or at least, a lot more reliable than the current code).
Thanks a lot for working on this.
--
Richard Braun
part becomes single threaded, which is fine
since it's the I/O bound part.
--
Richard Braun
s still multithreaded, which is what really matters.
--
Richard Braun
e properly, not to violate strict aliasing currently.
--
Richard Braun
201 - 300 of 595 matches
Mail list logo
