people. Mike will handle the bug when he decides to, and
I'll keep providing packages in the mean time.
--
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 31.1.0esr-1 (from unstable) is available.
--
Richard Braun
at
address 0).
--
Richard Braun
probably want to align on what others do, as usual.
--
Richard Braun
On Thu, Jul 10, 2014 at 11:18:17PM +0200, Richard Braun wrote:
All right, it looks like open() gets interrupted by SIGCHLD here. It's
my understanding that signal handling is highly system-specific in such
cases, but we probably want to align on what others do, as usual.
By the way, it looks
On Thu, Jul 10, 2014 at 02:21:06PM -0700, Roland McGrath wrote:
Is the SIGCHLD set with SA_RESTART?
From what I see, no.
--
Richard Braun
() :
If nbyte is zero and the file is not a regular file, the results are
unspecified.
We might also want to change this though, since the behaviour observed
on other systems seems more appropriate.
--
Richard Braun
On Sat, Jun 28, 2014 at 10:48:56AM +0200, Richard Braun wrote:
On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote:
This is because the client is calling:
send(sockfd, , 0, 0)
Normally this doesn't trigger recv() in the server and thus can be
used to test, whether
On Sat, Jun 28, 2014 at 12:09:15PM +0200, Samuel Thibault wrote:
Richard Braun, le Sat 28 Jun 2014 11:51:42 +0200, a écrit :
On Sat, Jun 28, 2014 at 10:48:56AM +0200, Richard Braun wrote:
On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote:
This is because the client
On Sat, Jun 28, 2014 at 12:42:40PM +0200, Richard Braun wrote:
I'll see if simply catching completely empty messages at socket_send is
a good enough solution.
The solution seems to work, and I couldn't see anything against it,
unlike the previous attempt. However I'd really like to put
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 30.0-2 (from unstable) is available.
--
Richard Braun
.
There are strong interdependencies, some are explicit, some are
implicit. And being able to change some aspects of the Hurd is part
of why I advocated this merge in the first place (as clearly stated in
my original mail).
I strongly agree with Justus on this.
--
Richard Braun
On Fri, May 30, 2014 at 09:35:37AM +0200, Justus Winter wrote:
Quoting Richard Braun (2014-05-29 19:12:13)
On Thu, May 29, 2014 at 07:04:48PM +0200, Samuel Thibault wrote:
But precisely: once the only thread gets a data_request, it'll call
pager_read_page, which will typically call
On Fri, May 30, 2014 at 08:15:43PM +0200, Samuel Thibault wrote:
Justus Winter, le Fri 30 May 2014 09:35:37 +0200, a écrit :
Quoting Richard Braun (2014-05-29 19:12:13)
On Thu, May 29, 2014 at 07:04:48PM +0200, Samuel Thibault wrote:
But precisely: once the only thread gets
not pipelining the I/O requests.
Right, I assumed the store interface wasn't synchronous...
--
Richard Braun
On Fri, May 23, 2014 at 01:44:09AM +0200, Samuel Thibault wrote:
Richard Braun, le Mon 05 May 2014 18:32:26 +0200, a écrit :
On Mon, May 05, 2014 at 06:01:17PM +0200, Samuel Thibault wrote:
? The patch makes both ext2fs's service_paging_requests and libdiskfs'
service_paging_requests
On Tue, May 13, 2014 at 10:37:05AM +0200, Richard Braun wrote:
It disappeared a few months ago, and since it's not widespread, I
suggest, despite providing to Justus in the first place, to use the
Murmur finalizer instead. But we need to test that part a bit more.
I'm currently doing just
for the trap call.
Keep in mind that, while most system calls are actually RPCs, a few of
them actually are real system calls (i.e. traps) in addition to
mach_msg. mach_thread_self and mach_task_self are such calls.
--
Richard Braun
On Tue, May 20, 2014 at 11:50:28PM +0200, Samuel Thibault wrote:
Richard Braun, le Tue 20 May 2014 23:42:24 +0200, a écrit :
On Tue, May 20, 2014 at 10:50:07PM +0200, Samuel Thibault wrote:
I would advise starting with trivial system calls, such as
mach_thread_self, mach_task_self
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 29.0.1 (from unstable) is available.
--
Richard Braun
a few months ago, and since it's not widespread, I
suggest, despite providing to Justus in the first place, to use the
Murmur finalizer instead. But we need to test that part a bit more.
I'm currently doing just that.
--
Richard Braun
system to enforce the use of the accessor functions.
I understand, but type-puning will break with smart compilers. We do
have had bugs like that in the past.
I agree, you should directly use the proper type here, or maybe void *
but I don't see the point.
--
Richard Braun
.
--
Richard Braun
threaded, which is fine
since it's the I/O bound part.
--
Richard Braun
, which is what really matters.
--
Richard Braun
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
this special size, and have munmap override its given range
to skip that area.
--
Richard Braun
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
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
investigate yet.
The issue
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
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, 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
any of these advantages in practice, but I've hit
the issues many times...
--
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
Hello,
Apparently, the deadline for proposals is tomorrow (March 21). Students
indenting to participate should be careful not to miss it.
--
Richard Braun
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
separate / and /home
partitions.
--
Richard Braun
much appreciate mentoring.
--
Richard Braun
file is enough ?
--
Richard Braun
, 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, the issue is described on the wiki [1].
--
Richard Braun
[1] http://darnassus.sceen.net/~hurd
defaults0 3
/dev/hd0s3noneswapsw0 0
/dev/hd2/media/cdrom0iso9660noauto0 0
what could be the problem? what is failing? it looks quite correct
to me. Swap and CDROM shouldn't be fsck'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
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
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
. */
+#define IO_BITS_PROTECTED_PAYLOAD 0x4000 /* pp set? */
Thanks :-).
--
Richard Braun
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
be worth
emphasizing that 0 is an invalid value for a protected payload.
--
Richard Braun
in mind while reading/editing the code. Doing things differently for
something like mere names isn't worth the trouble.
--
Richard Braun
-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
, for this
special call, it was done on purpose to avoid the VM system (since it's
a debugging call).
--
Richard Braun
, 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
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:09PM +0100, Marin Ramesa wrote
during work/week
ends/holidays, so let your client lurk there a few hours/days at least.
--
Richard Braun
. For example, state the address
requirements (pointing and aligned to an int).
--
Richard Braun
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 actually did not implement this because I don't know how
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);
+
+thread_timeout_setup(current_thread
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 really
means but the GCC manual says
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
apply the attribute directly
to the structure, thus even avoiding the typedef altogether?
Yes, that's the preferred way.
--
Richard Braun
, 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
I'm usually not keen on micro
optimizations before fixing system encompassing design issues :).
--
Richard Braun
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.
http://lists.gnu.org/archive/html/bug-hurd
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 (*address == value) {
In addition
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)
+
+ queue_iterate(futex-chain, futex, futex_t, chain
.
--
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 ?
I link it with gnumach .o files
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't understand
what it means to function
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 as
Actually, kern/rbtree.h
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
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,
On Thu, Dec 26, 2013 at 05:44:56PM +0100, Samuel Thibault wrote:
loses, actually :)
(and ditto further down)
Right, thanks.
--
Richard Braun
, 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
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
.
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
/ 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
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. You'll get a new entry at boot time
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 necessary to actually test it from
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 execute a program over it? I tried
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. Removing
forward declarations and unused
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
patch shortly.
Test it yourself from
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 ?
--
Richard
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.
I earlier wrote some proof
. 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 pointer,
the evaluation of b
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. And that's exactly why this check against
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
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:
ipc_port_t notify_port = 0;
in ipc
semantics
are actually what matter most here with regard to code ordering, and
they actually reduce the effectiveness of optimizations.
--
Richard Braun
. Keep it simple, limit yourself to cleaning the code, not
making it more complicated (and then dirtier) than it could be.
--
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 structure
and then passed
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. And
there is not one member
you assume the data to be null-terminated.
--
Richard Braun
201 - 300 of 557 matches
Mail list logo
