Manolis Ragkousis, le Wed 28 May 2014 18:47:57 +, a écrit :
> I sent the mail by mistake incomplete, I am sorry.
>
> > Could you try this patch for the Hurd’s configure.in?
>
> I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail
> with
> >> syntax error near unexpecte
libdiskfs has two kind of nodes, struct node and struct netnode.
struct node is used to store libdiskfs specific data, while struct
netnode contains user supplied data. Previously, both objects were
allocated separatly, and a pointer from the node to the netnode
provided a mapping from the former
Previously, fakeroot stored netnodes in the hash table. But we are
not interested in a cache for netnodes, we need a node cache. So
fakeroot kept pointers to the associated node object in each netnode
object.
Use fat netfs nodes, which combine node and netnode objects.
* trans/fakeroot.c (struc
libnetfs has two kind of nodes, struct node and struct netnode.
struct node is used to store libnetfs specific data, while struct
netnode contains user supplied data. Previously, both objects were
allocated separatly, and a pointer from the node to the netnode
provided a mapping from the former to
The current name cache lookup operation completes in O(n) time. This
means that making the cache too large would decrease the performance.
Therefore it was required to tune the size, hence the need for
statistics.
We will use a data structure with worst case constant lookup times in
the future, r
When using fat nodes, expressions of the form E->nn can be rewritten
as netfs_node_netnode (E). This is much faster as it only involves a
offset calculation. For reference, I used the following semantic
patch to create the patch:
@@
expression E;
@@
- E->nn
+ netfs_node_netnode (E)
* trans/fak
Previously, name cache lookup operation completed in O(n) time. This
means that making the cache too large would decrease the performance.
Therefore it was required to tune the size.
Implement the name cache using a hash table.
We use buckets of a fixed size. We approximate the least-frequently
Justus Winter, le Thu 29 May 2014 18:40:59 +0200, a écrit :
> libdiskfs has two kind of nodes, struct node and struct netnode.
> struct node is used to store libdiskfs specific data, while struct
> netnode contains user supplied data. Previously, both objects were
> allocated separatly, and a poin
Justus Winter, le Thu 29 May 2014 18:41:00 +0200, a écrit :
> libnetfs has two kind of nodes, struct node and struct netnode.
> struct node is used to store libnetfs specific data, while struct
> netnode contains user supplied data. Previously, both objects were
> allocated separatly, and a pointe
Justus Winter, le Thu 29 May 2014 18:41:01 +0200, a écrit :
> Previously, fakeroot stored netnodes in the hash table. But we are
> not interested in a cache for netnodes, we need a node cache. So
> fakeroot kept pointers to the associated node object in each netnode
> object.
>
> Use fat netfs n
Justus Winter, le Thu 29 May 2014 18:41:02 +0200, a écrit :
> When using fat nodes, expressions of the form E->nn can be rewritten
> as netfs_node_netnode (E). This is much faster as it only involves a
> offset calculation. For reference, I used the following semantic
> patch to create the patch:
Justus Winter, le Thu 29 May 2014 18:41:04 +0200, a écrit :
> Previously, name cache lookup operation completed in O(n) time. This
> means that making the cache too large would decrease the performance.
> Therefore it was required to tune the size.
>
> Implement the name cache using a hash table.
Justus Winter, le Thu 29 May 2014 18:41:03 +0200, a écrit :
> The current name cache lookup operation completes in O(n) time. This
> means that making the cache too large would decrease the performance.
> Therefore it was required to tune the size, hence the need for
> statistics.
>
> We will use
Richard Braun, le Tue 27 May 2014 14:12:07 +0200, a écrit :
> > But the paging part also comes from client events, doesn't it? E.g.
> > on-demand loads of parts of mapped libraries, etc.
>
> If on-demand here means on page fault, then no. In Mach, client threads
> don't process their page faults,
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 store_read, which will wait
> on the eventual I/O, and no other request will be processed during that
> time, and thus
> Could you try
>
> AC_MSG_WARN("cross-compiling, disabling linking")
>
> ?
diff --git a/configure.ac b/configure.ac
index ecabfdf..7ede6db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,13 @@ AC_PROG_INSTALL
AC_PROG_AWK
AC_PROG_SED
+if test "x$cross_compiling" = "xyes"; then
+ # I
Manolis Ragkousis, le Thu 29 May 2014 21:01:02 +, a écrit :
> Works like a charm.
Good, applied, thanks!
Samuel
Justus Winter, le Fri 23 May 2014 08:39:56 +0200, a écrit :
> Quoting Samuel Thibault (2014-05-23 00:22:14)
> > Justus Winter, le Thu 22 May 2014 22:13:28 +0200, a écrit :
> > > Until the Hurd specific header is available, provide a local
> > > declaration of ped_device_new_from_store.
> >
> > Mmm
What is the state of the patch unsubmitted-pthread_posix-option.diff
from the debian/hurd glibc package?
It is critical in building glibc, as without it fails with
> In file included from gai_sigqueue.c:22:0:
> ./gai_misc.h:32:5: error: unknown type name 'pthread_cond_t'
> pthread_cond_t *
Manolis Ragkousis, le Thu 29 May 2014 22:34:35 +, a écrit :
> Maybe some of these changes should be pushed to upstream.What do you think?
Well, all our patches should be pushed to upstream, whenever anybody
gets the time to submit them :)
I don't really have much more to say than the comment,
That's great thank you :-)
Manolis
Justus Winter, le Sat 08 Jun 2013 14:15:14 +0200, a écrit :
> Quoting Samuel Thibault (2013-06-08 13:34:18)
> > Justus Winter, le Sat 08 Jun 2013 13:27:07 +0200, a écrit :
> > > I'm trying to setup pbuilder on one of my virtual Hurd
> > > systems. Problem is that debootstrap eventually dies:
> >
>
22 matches
Mail list logo
