On Tue, Aug 21, 2012 at 09:44:43PM +0200, Richard Braun wrote:
> Debian packages are available for testing using this repository :
> deb http://ftp.sceen.net/debian-hurd experimental/
> deb-src http://ftp.sceen.net/debian-hurd experimental/
>
> Upgrade glibc packages first, th
is this really a client-server
implementation... And you're blaming lack of documentation for that ?!
Seriously ?
I mean, you're really, seriously asking those questions ?!
>From there, it seems to me you have two options here. You either keep
working on stuff that doesn't require understanding operating systems
(that is, you work on high level package porting, or you move on to
another project that isn't an operating system), or you get to work
and read and learn about them.
Seriously.
--
Richard Braun
isn't the place to
waste time on the basics. Things are complicated but not "overly". You
just need a bit of training like anybody does. Read a book about
operating systems, or use a search engine to find sites such as
http://wiki.osdev.org/. And please, please, LEARN C, because it's
almost not acceptable that someone writes patches for C programs,
replacing static with dynamic allocations, and doesn't understand what
malloc, realloc, and free really do, forcing people to go through
many review iterations just because of your lack of willingness to
correctly learn things instead of relying on others to do the job.
> > Seriously.
>
> Yes, sincerely.
I can't believe that.
--
Richard Braun
l it's actually right, and if
people are too annoyed to answer you, you'll blame them for not doing
anything to help, at which point you'll give up.
> > And please, please, LEARN C, because it's
> > almost not acceptable that someone writes patches for C programs,
> > replacing static with dynamic allocations, and doesn't understand what
> > malloc, realloc, and free really do, forcing people to go through
> > many review iterations just because of your lack of willingness to
> > correctly learn things instead of relying on others to do the job.
>
> I'm rather fluent by now, most patches sent for review are granted by
> either Samuel or Guillem. You don't seem to be a very frequent reviewer,
> however.
They're faster to reply than I am. I wouldn't know the many mistakes you
cause if I didn't review them.
> I know that you are one of the few people doing _real_ development on
> gnumach and Hurd, that is really appreciated. Please don't make this
> discussion into a pie-throwing war. There are too few Hurd users and
> developers for that.
Again, I hoped to keep it all between ourselves instead of making it
public. That's your choice. Please don't answer this with additional
nonsense just to have the last word.
--
Richard Braun
> total_system_time += p.system_time
> total_user_time += p.user_time
I didn't take the time to look at the details of your code, but one
quick note: what if the "idle task" isn't part of the process list ?
This problem isn't specific to Debian, I'm copying to bug-hurd as well.
--
Richard Braun
poll() shall return a non-negative
> value. A positive value indicates the total number of file
> descriptors that have been selected (that is, file descriptors
> for which the revents member is non-zero).
I also still don't see the point.
--
Richard Braun
y for its /servers/socket node,
and not for the socket descriptors. See pflocal/sserver.c.
--
Richard Braun
ion to this problem, it requires a lot more
efforts than these ugly hacks.
--
Richard Braun
n). If you simply replace the executable file, it doesn't change
the fact that the server is still running with the previous code, and
the parent of /servers/socket/1 (normally the root file system server)
still redirects lookups for this node to the already existing pflocal
instance.
--
Richard Braun
r, you won't see
the output of printf calls. You should probably replace them with
fprintf calls to a file in e.g. /tmp.
--
Richard Braun
/home file system should still retain all users files, so they should
be restored along the reinstallation.
--
Richard Braun
).
It's actually the only thing to do here. As discussed on IRC, I added
another check in vm_map_enter to catch wrong internal calls, and
committed the change.
--
Richard Braun
the current
Debian package yet.
--
Richard Braun
happen is EPIPE)
> (that would have saved a mail roundtrip if you had simply said so in
> your mail)
I only see EPIPE in pipe_wait_writable, which is only used in case
SELECT_WRITE is set. I'm not sure how this will fix the behaviour for
the POLLIN case.
--
Richard Braun
On Mon, Nov 26, 2012 at 02:34:04PM +0100, Samuel Thibault wrote:
> In the read case, the end of file will be detected by a zero-read, not
> an EPIPE.
Right. What about the SELECT_URG/POLLPRI case ? This one looks quite
obscur.
--
Richard Braun
On Mon, Nov 26, 2012 at 02:38:44PM +0100, Samuel Thibault wrote:
> Richard Braun, le Mon 26 Nov 2012 14:37:23 +0100, a écrit :
> > Right. What about the SELECT_URG/POLLPRI case ? This one looks quite
> > obscur.
>
> It is. IIRC for TCP/IP it's used for out-of-band data.
;m not really a Mach or ATA expert),
> apart from a few style and formatting issues.
As it's a diff from Linux 2.0.40, we probably want to keep it the way it
exists upstream. Concerning the changes themselves, they look fine so
far. Nice job :).
--
Richard Braun
On Tue, Nov 20, 2012 at 04:03:04PM +0100, Richard Braun wrote:
> The public Hurd box darnassus.sceen.net suffered a problem (due to human
> error when updating kernel/libc/hurd servers), which caused a fatal
> corruption of the root file system. The machine needs to be completely
>
case of only a few running threads at the same time.
--
Richard Braun
On Sun, Dec 02, 2012 at 11:15:08AM +0100, Richard Braun wrote:
> the port to pthreads), I noticed that much of the time spent by the CPU
> is actually wasted for two major reasons.
I didn't emphasize enough that, contrary to "popular" belief, the main
bottleneck is
On Mon, Dec 10, 2012 at 01:45:55AM +0100, Cyril Roelandt wrote:
> I attached a patch that fixes the issue, but I can't guarantee that
> it doesn't break anything. What do you think ?
Looks fine.
--
Richard Braun
y bug.
Please don't mention work I haven't released to explain bugs in your own
work ... This was untested code which was later replaced. See [1].
--
Richard Braun
[1]
http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
aging), so perhaps TH_UNINT is set during page-in or something
> like that? Hmm...
The TH_UNINT flag is often set in GNU Mach. The main reason is to prevent
leaving an inconsistent state if a thread never resumes. Legacy task
(process) swapping is a likely reason for the state you're observing.
--
Richard Braun
On Sun, Dec 23, 2012 at 11:49:25PM +0100, Samuel Thibault wrote:
> > Other than that, the analysis and the fix look good.
>
> AIUI, with the gnumach fix it is not needed any more, right?
Yes, that's the idea.
--
Richard Braun
* rootdir.c: Include and .
(rootdir_gc_meminfo): Call vm_cache_statistics and return the VM cache size.
---
rootdir.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/rootdir.c b/rootdir.c
index 1fa71b0..31e2d8c 100644
--- a/rootdir.c
+++ b/rootdir.c
@@ -17,8 +17,10
* utils/vmstat.c: Include and .
(vm_state): New `cache_stats` member.
(vm_state_refresh): Call vm_cache_statistics.
(_F): Adjust offset.
(fields): Add entries for new statistics and adjust member names.
---
utils/vmstat.c | 44 +---
1 file changed, 29 ins
wever
isolate the respective specific code in helper functions.
--
Richard Braun
The fmh function could in some cases mistakenly call vm_map with a null
size. A recent kernel fix made that invalid and return KERN_INVALID_ARGUMENT,
which isn't an expected code here, resulting in the linker not starting.
Avoid calling vm_map when the computed mapping size is null to fix the
probl
Here is the current state of my work about fixing functions that block
for a limited time (e.g. pthread_cond_timedwait), and cancellation.
---
pthread/pt-alloc.c |3 +
pthread/pt-cancel.c | 26 +-
pthread/pt-internal.h |8 ++
On Thu, Jan 24, 2013 at 12:14:44AM +0100, Richard Braun wrote:
> diff --git a/pthread/pt-cancel.c b/pthread/pt-cancel.c
> index d19c557..3698cce 100644
> --- a/pthread/pt-cancel.c
> +++ b/pthread/pt-cancel.c
> @@ -31,9 +31,31 @@ pthread_cancel (pthread_t t)
>if (! p)
&
series with
git. Finally, each time I give more thought about it, the separation of
the "three" cases you're trying to introduce looks wrong to me. The
amount of change needed to handle each case is small enough to keep them
inline. Please avoid completely reworking _hurd_select just to fix a
small conformance issue ...
--
Richard Braun
ze), poll and select behave the same when nfds
is 0, i.e. the timeout is not ignored and the call acts as a sleep.
IMHO, our implementation should stick to that common behaviour.
--
Richard Braun
I'd also mention the way the design affects security (making processes
obtain due rights instead of switching from root to a less privileged
user).
--
Richard Braun
Here is the fixed version of my current work about fixing functions
that block for a limited time (e.g. pthread_cond_timedwait), and
cancellation, with additional description of what it is about.
This patch solves two issues. The first one is cancellation handling
when a cancellation request is se
t; command to
make it automatically pass on SIGSEGV signals so that you only catch the
SIGILL you're interested in.
--
Richard Braun
GINFO)
signal handler and see how it goes, in which case there is a bug in the
signal handling code.
See the following glibc files for reference :
- sysdeps/mach/hurd/i386/trampoline.c
- sysdeps/mach/hurd/i386/sigreturn.c
--
Richard Braun
'll
> have to submit them to libc-alpha anyway...
+1
--
Richard Braun
us, it's also faster, and we can more effectively concentrate on
thinking about the big picture and the details. The second is to reduce
the likeliness of regressions. Please keep that in mind.
--
Richard Braun
rst we told you not to. Look at
the branch Samuel just created [1], it's not a rewrite, there only are a
few changes, quite simple to understand.
--
Richard Braun
[1]
http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=youpi/poll_errors_fixes
threats about copyright assignments... Seriously...
And this last act of arrogance about the copyright issue is so rude I
will just say it plainly :
>From now on, I'll completely ignore you. System development is obviously
not for you, go do something else (my early apologies to whoever gets
him in his team). Go away from this project.
--
Richard Braun
fter.
Among the immediate benefits, vim (actually, when called with another
name such as view or through another program like dch or git) now
reacts properly. The gitk tool magically works again. Iceweasel no
longer suffers from threads randomly spinning in infinite loops.
Feedbacks are welcome.
--
Richard Braun
he dandelions) because it's hilarious, but I
really wouldn't mind the former either. As this issue is a critical one
that currently severely prevents usage of the system and further
development, it should be resolved quickly.
--
Richard Braun
been contributing to it, spread over
> several years, my proposal is to just feed that amount back into the
> general GNU Hurd pool, which is what will happen on Saturday unless
> someone intervenes.
Agreed. Thanks for taking care of that.
--
Richard Braun
open issues. I believe it's even more important now that the GSoC is
about to start.
--
Richard Braun
gestion was to permanentely add a link to project ideas, not only
during the duration of the GSoC.
--
Richard Braun
re, but debugging should currently have priority
nonetheless, and the DWARF call frame information data are quite not as
easy to use.
--
Richard Braun
On Sat, Apr 13, 2013 at 06:26:57AM -0400, James Simko wrote:
> do you still need a technical writer to do documentation?
Well, yes, obviously. But we also need people who want to be involved
to actually enjoy what they'll be doing.
--
Richard Braun
o be
busy elsewhere.
--
Richard Braun
If requested by the user, make libpager call pager_notify_evict when a page
is flushed out by the kernel. Based on work by Ognyan Kulev.
* console/pager.c (pager_notify_evict): New function.
(user_pager_create): Update call to pager_create.
* ext2fs/pager.c: (pager_notify_evict): New function.
(cr
This is a revised version of the large store patch for ext2fs, written
by Ognyan Kulev. It provides support for stores larger than 2 GiB.
* ext2fs/balloc.c: Use the new disk_cache_block_ref and disk_cache_block_deref
functions to access blocks from the disk cache.
* ext2fs/ext2fs.c (main): Update
On Sun, Dec 02, 2012 at 11:15:08AM +0100, Richard Braun wrote:
> On Sat, Dec 01, 2012 at 12:53:30PM +0100, Thomas Schwinge wrote:
> > So, switching to a SSD does give a small performance boost, but not the
> > big one we had hoped for. Using --no-atime improves this further.
> &
While it's true that Mach time values are returned in microseconds, they
are correctly handled as such, and not as clock ticks, by applications.
On the other hand, tools such as top provide wrong results since values
in /proc are actually provided as true clock ticks.
---
sysdeps/mach/hurd/getclkt
sage passing. A simple solution would be
to create raw system calls, but I'm not sure that's something we want
to do as it can be handy to emulate kernel calls. Another solution is
to restrict these RPCs to kernel objects only.
--
Richard Braun
On Fri, May 10, 2013 at 05:07:52PM +0200, Richard Braun wrote:
> On Thu, May 09, 2013 at 07:20:39PM +0200, Samuel Thibault wrote:
> > Thomas Schwinge, le Thu 09 May 2013 18:42:18 +0200, a écrit :
> > > Then, to what extent are the proposed new RPCs just a specialized
> >
point of that change. Using
already generated system headers is the intent here. The fact they were
generated doesn't matter at all, they are the interface reference that
applications (and even the Hurd itself) must use.
--
Richard Braun
ded by glibc (and by the libc0.3-dev package on
Debian GNU/Hurd).
--
Richard Braun
ould just go away. A simple elevator is trivial anyway, and forcing
ourselves to rethink it if we do need it (e.g. with regard to tagged
command queuing) is a good thing to do IMO.
--
Richard Braun
hoon/packages/hurd-pkg/build/libshouldbeinlibc'
> make[2]: *** [libshouldbeinlibc] Error 2
> make[2]: Leaving directory `/media/scratch/teythoon/packages/hurd-pkg/build'
> dh_auto_build: make -j1 returned exit code 2
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory `/media/scratch/teythoon/packages/hurd-pkg'
> make: *** [binary] Error 2
You need more recent sources, i.e. those from debian-ports.
--
Richard Braun
123d5aaf
> > Maybe something for the web pages until these versions are available in
> > Debian main (if ever)
>
> Any reason not to serve source packages from debian-ports.org?
I'd like to know as well.
--
Richard Braun
On Mon, Jun 10, 2013 at 07:30:58PM +0200, Justus Winter wrote:
> Quoting Richard Braun (2013-06-10 16:28:40)
> > On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote:
> > > Awesome, didn't know this one. Still I was hoping to get a git repo
> > > since
- Forwarded message from Richard Braun -
Date: Mon, 6 May 2013 21:49:56 +0200
From: Richard Braun
To: bug-hurd@gnu.org
Subject: [PATCH] Make __getclktck return 100 for the Hurd
X-Mailer: git-send-email 1.7.2.5
While it's true that Mach time values are returned in microseconds,
exported through sysconf(_SC_CLK_TCK).
--
Richard Braun
ual number of ticks per second. I personally think the latter is
better for clarity, and also to limit overflows for long running
processes, although that's really secondary.
--
Richard Braun
an RPC from the
Hurd. To make sure that's the case, see if rpctrace catches the call.
--
Richard Braun
On Wed, Jul 03, 2013 at 11:35:31AM +0200, Marin Ramesa wrote:
> diff -Nurp ../gnumach/ddb/db_break.c ../gnumach1/ddb/db_break.c
Please ease the life of maintainers by providing git-generated patches
with a proper changelog entry.
--
Richard Braun
commit entries for reference.
Thanks.
--
Richard Braun
On Thu, Jul 04, 2013 at 03:29:57PM +0200, Justus Winter wrote:
> I'm thinking that this might be an opportunity to get rid of the
> heuristic in that function. The comment explains the issue:
If you have time, sure, otherwise the heuristic seems to be enough for
the time being.
--
Richard Braun
make the client figure it out by itself from a port to the mount
> point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be slower, but
> should be safer. The RPC would thus return an array of ports to the
> mount points instead of an array of strings.
>
> Anybody else?
Looks better indeed.
--
Richard Braun
ght
> violation of some kind. Or they are just too trivial for that.
This shouldn't be a problem at all.
--
Richard Braun
x27;t think it has anything to do with the instruction cache. Use the
thread_info() call to determine what the suspend count is, it may have
been incremented implicitely.
--
Richard Braun
> something maybe wrong, but the err is zero.
Something does look wrong. Check all the parameters of your call, one
by one, rigorously.
--
Richard Braun
On Thu, Jul 18, 2013 at 12:22:07AM +0800, Yue Lu wrote:
> On Thu, Jul 18, 2013 at 12:13 AM, Richard Braun wrote:
> > On Thu, Jul 18, 2013 at 12:07:20AM +0800, Yue Lu wrote:
> >> when I used thread_info() to check the suspend count, they are zero.
> >> But I met a str
m starting to agree that, considering a recursive approach does more
than what we need, a simple registry translator is probably much simpler
and safer than what we're trying to do here.
--
Richard Braun
#x27;s still a valid security concern,
worth mentioning here.
--
Richard Braun
f the caller is chrooted? The filenames should be relative to
> the caller's root.
Is that really necessary ? Support for chroot has always been incomplete
and present for compatibility only. In addition, Linux still shows the
paths at mount time in /proc/mounts from a chroot.
--
Richard Braun
, which seems to be an impractical way of extending
system functionality ...
--
Richard Braun
[1] http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00214.html
. Also, providing the correct values aligns our procfs more
> closely with the Linux one, and that is one of the points of our
> procfs, isn't it?
What's the problem with adding support for valid values ?
--
Richard Braun
h nsmux, to exec, say,
> foo.gz,,gunzip for instance, instead of guessing.
A better example would be providing an exec server for old a.out static
binaries for example. But for compression, what Justus describes looks
a lot more hurdish to me.
--
Richard Braun
such projects, you need a
good amount of autonomy.
--
Richard Braun
> > by setting the TASK_KERNEL_PORT of a task.)
>
> Apparently task_create is a kernel trap.
How come it appears in the output of rpctrace then ?
--
Richard Braun
On Thu, Sep 12, 2013 at 08:24:41AM +0200, Samuel Thibault wrote:
> Richard Braun, le Thu 12 Sep 2013 01:57:10 +0200, a écrit :
> > How come it appears in the output of rpctrace then ?
>
> As I said, glibc probably nicely uses the RPC instead of the trap.
Then why are we discuss
On Thu, Sep 12, 2013 at 10:38:31AM +0200, Samuel Thibault wrote:
> Richard Braun, le Thu 12 Sep 2013 10:33:23 +0200, a écrit :
> > Then why are we discussing interposing system calls ?
>
> Because a malicious program can still use the trap to escape whatever
> cgroup system we
On Mon, Sep 16, 2013 at 01:50:57AM +0200, Samuel Thibault wrote:
> Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> > I suggest we simply disable the trap versions.
>
> Ah, right.
>
> I don't have the time to dive into the details, but in the end, coul
ce? (at least for the record)
Nothing major, I'd simply like this process to be as visible as the rest
of the system.
--
Richard Braun
On Mon, Sep 16, 2013 at 02:58:24AM +0200, Richard Braun wrote:
> On Mon, Sep 16, 2013 at 01:50:57AM +0200, Samuel Thibault wrote:
> > Richard Braun, le Thu 12 Sep 2013 10:57:25 +0200, a écrit :
> > > I suggest we simply disable the trap versions.
> >
> > Ah, right.
sks are kernel objects, task grouping should be
done by the kernel too. For me, it looks like this issue is part of
the more general problem of resource accounting in Mach.
--
Richard Braun
n those source lines you replace
refer to an optimization used by the Mach kernel which consists of
using object addresses as kernel port names to skip looking up the
object port.
So actually, these hashing functions take both a port name or a device
as argument.
--
Richard Braun
m right, procfs is outside the main Hurd repository because it's
not the original procfs server. We could probably merge it in one day
though.
--
Richard Braun
el what a "locked futex" means. That's
> why it's userland which provides the value the kernel should check for.
>
> You can read "futexes are tricky" from Ulrich Drepper, for more details.
>
> > + /* Check if there is an existing futex at the address given. */
>
> Better use a hash table :)
Also, futex_wait_lock looks to be local to futex_wait...
--
Richard Braun
On Sun, Sep 22, 2013 at 10:28:47AM +0200, Marin Ramesa wrote:
> On 22.09.2013 02:08:41, Richard Braun wrote:
> > Also, futex_wait_lock looks to be local to futex_wait...
>
> Yes it is. But if I introduce a more global lock that should imply that
> there is another operation t
On Mon, Sep 23, 2013 at 09:13:25AM +0200, Marin Ramesa wrote:
> The idea is to implement a simple mutex using one atomic operation
> combined with futex calls.
Use the algorithms presented in "Futexes are tricky", I personally won't
accept anything less after 2010...
--
Richard Braun
On Mon, Sep 23, 2013 at 11:34:36AM +0200, Marin Ramesa wrote:
> On 23.09.2013 10:35:34, Richard Braun wrote:
> > Use the algorithms presented in "Futexes are tricky", I personally
> > won't accept anything less after 2010...
>
> I do, it's actually the ve
eturn ret;
> }
Besides, you fetch the value of the mutex outside the critical section.
This really is a beginner mistake, showing that you probably need to
gain experience with concurrency itself first.
--
Richard Braun
//www.gnu.org/software/hurd/documentation.html
--
Richard Braun
The node structure for the `mounts' entry is created and destroyed on
each access, despite the fact a translator is activated on it. Fix the
issue by caching it.
* rootdir.c (rootdir_mounts_node): New variable.
(rootdir_mounts_node_lock): Likewise.
(rootdir_mounts_make_node): New function.
(rootdi
previous ones.
> So, how to start with it?
Don't take it wrong, but everything you need is on the wiki. If you
really want to contribute, just do it. How hard is it to just grab the
code, clean it, and send patches ?
--
Richard Braun
that some function pointers
used by glibc code, such as demuxers used by mach_msg_server_timeout,
can't easily be modified to take a generic void * pointer without
breaking the ABI. Those function pointers were intended to be nested
functions from the start.
--
Richard Braun
muel, Richard and me in
> favor of that kind of change, Roland and you against it.
It's not a matter of mere numbers. We need consensus, and if we can't
achieve it, the actual maintainer (who currently is Samuel) decides.
--
Richard Braun
.c (rbtree_insert_rebalance): Simplify node swap.
>
> I'd rather keep it as such, as an expression of the rbtree rotation.
It's not a rotation, merely a variable swap, I would personally simplify
it too. FYI, Justus find it too with Clang if I'm right.
--
Richard Braun
after diskfs_startup_diskfs returns).
In the mean time, I was thinking adding simple blocking calls, replacing
pthread_exit with poll. Is anybody uncomfortable with that hack ?
--
Richard Braun
101 - 200 of 595 matches
Mail list logo
