Re: [PATCH] libdiskfs: fix reference counting of peropen objects

At Fri, 29 Aug 2014 12:50:28 +0200, Justus Winter wrote: > > Quoting Neal H. Walfield (2014-08-29 11:55:07) > > At Fri, 29 Aug 2014 11:33:44 +0200, > > Justus Winter wrote: > > > Previously, peropen objects were created with a reference count of > > > zero.

Re: [PATCH] libdiskfs: fix reference counting of peropen objects

At Fri, 29 Aug 2014 11:33:44 +0200, Justus Winter wrote: > Previously, peropen objects were created with a reference count of > zero. Therefore, if diskfs_create_protid fails, passing such an > object to diskfs_release_peropen would lead to a reference count > underflow. > > * libdiskfs/peropen-m

Re: [PATCH] Support invoking the debugger over the serial console

At Thu, 21 Aug 2014 13:16:01 +0200, Samuel Thibault wrote: > > Hello, > > Thanks for sharing, I've had this kind of patch in my tree for a long > with another, easier to parse, keypress, but this implementation seems > nice as it keeps it ctrl-alt-d. > > Justus Winter, le Thu 21 Aug 2014 12:14:5

Re: [PATCH 5/7] include: add lock-less reference counting primitives

At Tue, 13 May 2014 21:02:54 +0200, Justus Winter wrote: > + assert (r != UINT_MAX); How about 'assert(r != UINT_MAX || !"refcount underflowed!")'. Since assert (r != UINT_MAX) requires understanding the use of an unsigned int.

Re: [PATCH 4/7] libihash: use fast binary scaling to determine the load

At Tue, 13 May 2014 21:02:53 +0200, Justus Winter wrote: > diff --git a/libihash/ihash.c b/libihash/ihash.c > index d628d75..f529a17 100644 > --- a/libihash/ihash.c > +++ b/libihash/ihash.c >if (ht->size) > { > - /* Only fill the hash table up to its maximum load factor. */ > -

Re: [PATCH 03/11] include: add lock-less reference counting primitives

At Tue, 13 May 2014 13:47:51 +0200, Samuel Thibault wrote: > > Neal H. Walfield, le Tue 13 May 2014 13:44:37 +0200, a écrit : > > At Tue, 13 May 2014 12:52:03 +0200, > > Justus Winter wrote: > > > Quoting Neal H. Walfield (2014-05-13 09:44:21) > > >

Re: [PATCH 03/11] include: add lock-less reference counting primitives

At Tue, 13 May 2014 12:52:03 +0200, Justus Winter wrote: > > Quoting Neal H. Walfield (2014-05-13 09:44:21) > > At Mon, 12 May 2014 12:05:41 +0200, > > Justus Winter wrote: > > > +/* Decrement REF. Return the result of the operation. This function > > > +

Re: [PATCH 07/11] libihash: use an integer hash function on the keys

At Mon, 12 May 2014 12:05:45 +0200, Justus Winter wrote: > > Use an integer hash function to derive the index from the key. This > should reduce the number of collisions. > > * libihash/ihash.c (hash_int32): New function. > (find_index): Use hash_int32 on the key to derive the index. > (add_one)

Re: [PATCH 03/11] include: add lock-less reference counting primitives

At Mon, 12 May 2014 12:05:41 +0200, Justus Winter wrote: > +/* Decrement REF. Return the result of the operation. This function > + uses atomic operations. It is not required to serialize calls to > + this function. */ > +static inline unsigned int > +refcount_deref (refcount_t *ref) > +{ >

Re: [PATCH 04/11] doc: document mach_port_set_protected_payload

At Mon, 17 Feb 2014 23:35:12 +0100, Richard Braun wrote: > > On Mon, Feb 17, 2014 at 06:20:54PM +0100, Justus Winter wrote: > > +@deftypefun kern_return_t mach_port_set_protected_payload (@w{ipc_space_t > > @var{task}}, @w{mach_port_t @var{name}}, @w{unsigned long @var{payload}}) > > +The functio

Re: [RFC] Enable thread termination

At Mon, 18 Nov 2013 16:14:57 +0100, Samuel Thibault wrote: > > Neal H. Walfield, le Mon 18 Nov 2013 13:41:46 +0100, a écrit : > > At Mon, 18 Nov 2013 12:31:42 +0100, > > Richard Braun wrote: > > > The threading library is a > > > low level component and shoul

Re: [RFC] Enable thread termination

At Mon, 18 Nov 2013 12:31:42 +0100, Richard Braun wrote: > > 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 termina

Re: [RFC] Enable thread termination

At Sun, 17 Nov 2013 17:13:23 +0100, 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 the threading library. This patch makes use > of a new GNU Mach spec

Re: [RFC] cleanup of #includes

At Thu, 14 Nov 2013 14:38:04 +0100, Svante Signell wrote: > > On Thu, 2013-11-14 at 14:26 +0100, Neal H. Walfield wrote: > > At Thu, 14 Nov 2013 13:56:30 +0100, > > Svante Signell wrote: > > > > 1. Do you consider the comment describing which symbols are pulled >

Re: [RFC] cleanup of #includes

At Thu, 14 Nov 2013 13:56:30 +0100, Svante Signell wrote: > > 1. Do you consider the comment describing which symbols are pulled > >from the header as noise or worthwile information? > > Very useful! No. This information gets out of date. Neal

Re: [PATCH] libports: implement lockless management of threads

Yes, this is what I was thinking of. I recall there being type defs for appropriate atomic types. If that is still the recommended approach, please update your patch appropriately. The most important thing, however, is ensuring that the semantics are preserved. That is, was the use of the value

Re: [PATCH] libports: fix the thread counts in case the thread creation fails

At Sun, 10 Nov 2013 11:54:20 +0100, Samuel Thibault wrote: > > Neal H. Walfield, le Sun 10 Nov 2013 11:38:04 +0100, a écrit : > > At Sat, 9 Nov 2013 18:21:51 +0100, > > Samuel Thibault wrote: > > > > + pthread_spin_lock (&lock);

Re: [PATCH] libports: fix the thread counts in case the thread creation fails

At Sat, 9 Nov 2013 18:21:51 +0100, Samuel Thibault wrote: > > + pthread_spin_lock (&lock); > > + totalthreads--; > > + nreqthreads--; > > + pthread_spin_unlock (&lock); It might be a good idea use atomic operations instead of the spin lock (which is what the spin lo

Re: [PATCH 3/5] libports: fix error handling in _ports_create_port_internal

At Fri, 25 Oct 2013 15:54:43 +0200, Justus Winter wrote: > > Quoting Thomas Schwinge (2013-10-25 15:27:10) > > > --- a/libports/create-internal.c > > > +++ b/libports/create-internal.c > > > @@ -109,10 +109,11 @@ _ports_create_port_internal (struct port_class > > > *class, > > >err = EINTR; >

Re: RFC: [PATCH] SCM_CREDS support

At Thu, 24 Oct 2013 15:38:11 +0200, Svante Signell wrote: > > Well, the question is quite simple: what happens when the sender > > provides faked ports, e.g. pointing to other proc/auth servers? That's > > where having to explain how the patch is working would possibly even > > work out the securi

Re: [PATCH 3/5] console-client: replace function epilogue with console_exit

At Thu, 10 Oct 2013 18:08:20 +0200, Justus Winter wrote: > > * console-client/console.c (main): Replace epilogue with console_exit. > --- > console-client/console.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/console-client/console.c b/console-client/console.c >

Re: [PATCH 3/7] name_equal: return early from function if src null-terminates in the loop

At Fri, 13 Sep 2013 15:06:33 +0200, Marin Ramesa wrote: > > On 13.09.2013 14:42:44, Neal H. Walfield wrote: > > At Fri, 13 Sep 2013 13:31:53 +0200, > > Marin Ramesa wrote: > > > diff --git a/device/dev_name.c b/device/dev_name.c > > > index bf541df..6ce4b19

Re: [PATCH 3/7] name_equal: return early from function if src null-terminates in the loop

At Fri, 13 Sep 2013 13:31:53 +0200, Marin Ramesa wrote: > diff --git a/device/dev_name.c b/device/dev_name.c > index bf541df..6ce4b19 100644 > --- a/device/dev_name.c > +++ b/device/dev_name.c > @@ -69,9 +69,12 @@ name_equal(src, len, target) > int len; > char*target; > { > -

Re: Hacking gnumach to track parental relationship of tasks

At Thu, 5 Sep 2013 16:57:41 +0200, Justus Winter wrote: > I made two rather small and (as I thought) straight forward changes to > gnumach to keep track of a tasks father task and to make this > information available. What happens when the parent task is destroyed? Are the children destroyed wit

Re: [PATCH 10/16] hurd: add fsys_get_children

At Tue, 30 Jul 2013 22:44:22 +0200, Richard Braun wrote: > > On Tue, Jul 30, 2013 at 12:20:32PM +0200, Neal H. Walfield wrote: > > > fsys_get_children returns any active translators bound to nodes of the > > > receiving filesystem as an argz vector containing file names re

Re: [PATCH 10/16] hurd: add fsys_get_children

At Tue, 30 Jul 2013 11:59:18 +0200, Justus Winter wrote: > > fsys_get_children returns any active translators bound to nodes of the > receiving filesystem as an argz vector containing file names relative > to the root of the receiving translator. What if the caller is chrooted? The filenames sho

Re: feature-mtab-translator (v3)

At Mon, 22 Jul 2013 22:49:03 +0200, Samuel Thibault wrote: > > Neal H. Walfield, le Mon 22 Jul 2013 21:50:02 +0200, a écrit : > > At Fri, 19 Jul 2013 17:25:02 +0200, > > Justus Winter wrote: > > > * The translator used to traverse the translator tree and if it > >

Re: feature-mtab-translator (v3)

At Fri, 19 Jul 2013 17:25:02 +0200, Justus Winter wrote: > * The translator used to traverse the translator tree and if it > encountered itself, it would deadlock. This is cleanly solved by > comparing the control ports of the current node and the mtab > translator. I don't think you can rel

Re: feature-mtab-translator (v3)

At Fri, 19 Jul 2013 18:04:47 +0200, Justus Winter wrote: > My personal preference would be to run the translator on /proc/mounts > as unprivileged user created solely for this purpose by default. This is not how things are done on the Hurd. You don't need an "unpriviledged user" you just drop al

Re: [PATCH 17/17] add mtab prototype

At Fri, 19 Jul 2013 17:25:19 +0200, Justus Winter wrote: > +static char *path = NULL; > +static int insecure = 0; Don't explicitly initialize static variables to 0 or NULL. This takes up unnecessary space in the executable and prevents using zero-filled memory. Neal

Re: [PATCH 03/17] libdiskfs: track file name in struct peropen

If you take this approach, you need to update relpath on renames. Do you? (I may have missed that.) Neal At Fri, 19 Jul 2013 17:25:05 +0200, Justus Winter wrote: > > --- > libdiskfs/dir-lookup.c | 24 > libdiskfs/diskfs.h |3 +++ > libdiskfs/fsys-getroot

Re: feature-mtab-translator (v3)

At Fri, 19 Jul 2013 18:04:47 +0200, Justus Winter wrote: > My personal preference would be to run the translator on /proc/mounts > as unprivileged user created solely for this purpose by default. It's > up to the system administrator to change that if he wishes. I know > it's not as magically as it

Re: [PATCH 15/17] hurd: add fsys_get_source

This needs much better documentation. At Fri, 19 Jul 2013 17:25:17 +0200, Justus Winter wrote: > > --- > hurd/fsys.defs |7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/hurd/fsys.defs b/hurd/fsys.defs > index 4b649d9..27ada29 100644 > --- a/hurd/fsys.defs > +++ b/hurd/fsys.def

Re: [PATCH 10/17] hurd: add fsys_get_children

At Thu, 18 Jul 2013 11:39:14 +0200, Justus Winter wrote: > He has shown me how this could be implemented, but doing so requires > attaching credentials to all fsys_* by means of > e.g. libdiskfs/fsmutations.h and fixing all functions that are > affected by this. I think it's doable, but my time mig

Re: [PATCH 10/17] hurd: add fsys_get_children

At Mon, 15 Jul 2013 12:13:52 +0200, Samuel Thibault wrote: > > Neal H. Walfield, le Mon 15 Jul 2013 11:34:38 +0200, a écrit : > > > > So, let's think about the > > > > fsck problem. What we need is a registry. I propose an mtab > > > > translator

Re: [PATCH 10/17] hurd: add fsys_get_children

At Mon, 15 Jul 2013 10:37:37 +0200, Samuel Thibault wrote: > > I don't like your solution to the mtab problem. But, as you admit, > > it's really a solution to the fsck problem. > > Not only. It's also about umount being able to know what to unmount when > calling umount /dev/cdrom, about mount/d

Re: [PATCH 10/17] hurd: add fsys_get_children

At Fri, 12 Jul 2013 15:07:59 +0200, Justus Winter wrote: > Quoting Samuel Thibault (2013-07-12 14:44:31) > > Neal H. Walfield, le Fri 12 Jul 2013 13:52:17 +0200, a écrit : > > > I apologize if you've already explained this someplace else. > > > > > > If I

Re: [PATCH 10/17] hurd: add fsys_get_children

At Fri, 12 Jul 2013 14:44:31 +0200, Samuel Thibault wrote: > > Neal H. Walfield, le Fri 12 Jul 2013 13:52:17 +0200, a écrit : > > I apologize if you've already explained this someplace else. > > > > If I understand correctly, you want to get all the nodes with activ

Re: [PATCH 10/17] hurd: add fsys_get_children

At Thu, 11 Jul 2013 18:09:13 +0200, Justus Winter wrote: > diff --git a/hurd/fsys.defs b/hurd/fsys.defs > index 979a6cf..4b649d9 100644 > --- a/hurd/fsys.defs > +++ b/hurd/fsys.defs > @@ -127,3 +127,11 @@ routine fsys_get_options ( > server: fsys_t; > RPT > out options: data_t, de

Re: Hurd stacks, some more (was: RFC: ruby1.9.1 FTBFS)

At Thu, 4 Jul 2013 17:06:09 +0200, Thomas Schwinge wrote: > I wonder: if MAP_STACK is set, would it even be > reasonable for mmap to ignore the supplied length, and instead use the > one "proper" value, 0x20? I think that this is only acceptable if the length exceeds the supplied length. This

Re: Guile not running properly on GNU/Hurd

At Sat, 2 Feb 2013 23:24:38 +0100, Richard Braun wrote: > On Sat, Feb 02, 2013 at 07:51:38PM +0100, Gabriel Schnoering wrote: > > I can't run guile in gdb as there are some error with the garbage > > collector. > > These are probably not errors. Many language interpretors rely on > receiving SIGSE

Re: [PATCH 5/7] Fix double call to pthread_mutex_unlock in _treefs_s_dir_lookup.

At Mon, 17 Dec 2012 01:31:32 +0100, Samuel Thibault wrote: > > Cyril Roelandt, le Mon 17 Dec 2012 00:51:28 +0100, a écrit : > > * libtreefs/dir-lookup.c (_treefs_s_dir_lookup): remove a redundant call to > > pthread_mutex_unlock. > > > > Signed-off-by: Cyril Roelandt > > --- > > libtreefs/dir-l

Re: Question about your libpthread

At Mon, 13 Aug 2012 11:54:17 +0200, Richard Braun wrote: > In addition, here you only mention the recylcing problem, not the > threadvar alignment problem. Or is there no such problem ? It's been a decade since I wrote the code, I've fotten a bit. I don't know offhand if there is a problem and I

Re: Question about your libpthread

I've add bug-hurd to the cc. At Mon, 13 Aug 2012 11:16:26 +0200, Richard Braun wrote: > > On Sun, Aug 12, 2012 at 07:03:06PM +0200, Neal H. Walfield wrote: > > But, if it is a generally useful function, I don't see why not to > > expose it as a general function. Ju

Re: libpthread: caching of data structures and kernel resources

At Fri, 10 Aug 2012 09:15:01 +0200, Neal H. Walfield wrote: > > Why does Viengoos in > > sysdeps/viengoos/pt-thread-halt.c:__pthread_thread_halt have to do > > different things depending on whether »thread == _pthread_self« or not? > > I'm assuming that o

Re: libpthread: caching of data structures and kernel resources

Hi, Thomas, At Fri, 10 Aug 2012 01:17:30 +0200, Thomas Schwinge wrote: > libpthread applies some caching of data structures > (cf. __pthread_free_threads; »state == PTHREAD_TERMINATED«) which after a > thread has exited can be re-used for a new one. > ... > Is this an optimization, assuming the se

Re: libpthread cleanup: L4 port, PowerPC port

At Tue, 7 Aug 2012 23:55:12 +0200, Thomas Schwinge wrote: > > It's generic code. At least glibc keeps generic code around, if I > > recall correctly. Further, one of the very nice things about this > > libpthread is that it is really easy to integrate into a new OS (or > > even use in a kernel).

Re: libpthread cleanup: L4 port, PowerPC port

At Sat, 4 Aug 2012 15:56:01 +0200, Thomas Schwinge wrote: > On Sat, 04 Aug 2012 15:16:22 +0200, "Neal H. Walfield" > wrote: > > At Sat, 4 Aug 2012 15:02:46 +0200, > > Thomas Schwinge wrote: > > > > > * signal/README: Likewise. > > > &g

Re: libpthread cleanup: L4 port, PowerPC port

At Sat, 4 Aug 2012 15:02:46 +0200, Thomas Schwinge wrote: > > > master-viengoos and its successor, master-viengoos-on-bare-metal. > > > > master-viengoos is an implementation of Viengoos that runs on L4. > > viengoos-on-bare-metal runs directly on x86-64 (and it a bit more > > advanced) and provid

Re: libpthread cleanup: L4 port, PowerPC port

At Sat, 4 Aug 2012 12:34:28 +0200, Thomas Schwinge wrote: > There has been a libpthread port for Hurd on L4 use, which is dead, and > has been superseded by a Viengoos port, which has its own branches: For what it is worth, the L4 port works directly on L4: no further OS personality support is req

Re: [PATCH] Page cache accounting

At Sun, 15 Jul 2012 19:35:31 +0200, Richard Braun wrote: > > On Sun, Jul 15, 2012 at 06:39:05PM +0200, Neal H. Walfield wrote: > > I'd encourage you to use a more self-describing data structure. In > > the very least, please consider a version number and a bitmask > >

Re: [PATCH] Page cache accounting

At Sat, 14 Jul 2012 17:06:37 +0200, Richard Braun wrote: > > If no major objection is raised (particularly about the new Mig > routine), I'll commit this patch in a few days. > ... > +struct vm_cache_statistics { > + integer_t object_count; /* # of cached objects */ > + integer_t

Re: Reworking libpager.

Hi, Максим, If I didn't post the patches, then either I never wrote them or they have been lost. Sorry. Neal At Sun, 3 Jun 2012 14:08:27 +0300, Максим wrote: > > Hello, > > I'm GSoC student and I work upon improving of disk I/O in hurd [1]. As part > of my project I have to modify libpager's

Re: [PATCH, libpthread] Correct logic for PTHREAD_KEY_INVALID slots.

I haven't looked at this change in detail, but it sounds sane and if Samuel says its okay, that's good enough for me. Neal

Re: Link to xgethostname broken at the porting guidelines page

At Mon, 11 Apr 2011 09:58:18 +0200, Svante Signell wrote: > When porting packages, is replacing a call to gethostname using > MAXHOSTNAMELEN with a call to Neal Walfields xgethostname still the > recommended way, as described at > http://www.gnu.org/software/hurd/hurd/porting/guidelines.html > > I

Re: Problems with signal delivery

At Thu, 2 Sep 2010 19:52:42 -0700 (PDT), Roland McGrath wrote: > > > Do you mean that there is some code relying on these Hurd semantics, and > > that therefore we should not try to change them to match POSIX, except > > maybe when the pthread functions are used? > > I mean the semantics are the

Re: RPC user stub libraries (was: error compiling hurd after gnumach interface change)

At Mon, 19 Jul 2010 11:16:03 +0200, Thomas Schwinge wrote: > * Avoid code duplication -- may have been relevant, but is it > still? > > Actually, if I understood correctly, in his Viengoos kernel, Neal > is doing all RPC stub code generation in the pre-processor, thus

Re: libparted backend for libstore (was: cannot boot subhurd)

At Sun, 3 Jan 2010 17:15:37 +0100, Thomas Schwinge wrote: > > [1 ] > Hello! > > On Sun, Jan 03, 2010 at 04:56:54PM +0100, Samuel Thibault wrote: > > Thomas Schwinge, le Sun 03 Jan 2010 16:48:00 +0100, a écrit : > > > We will need it as soon as we switch from the Mach disk device > > > handling t

Re: [Patch 0/2] Proxy memory objects revisited

This looks like a fine addition. One could imagine more complex schemes, which enable remapping (think scatter/gather type mechanisms), however, I don't think that this is generally useful. Further such additional functionality would significantly increase the complexity whereas your proposal is a

Re: Moving to git

> Here is one additional topic I want to confirm with you all before > committing it: the duplication of ChangeLog snippets and commit log > messages is a pain. However, it is not mandatory to maintain ChangeLog > files in the VCS sources -- it's fine with the GNU Coding Standards to > only create

Re: Moving to git

At Sun, 11 Jan 2009 12:50:58 +0100, Thomas Schwinge wrote: > > > Rationale: split as far as it's still making sense. There is no > > > reason to have an interger hashing library, a pthread > > > implementation, an ext2 file system interpreter, libc amendments, > > > Hurd interfaces

resource management that involve applications

At Tue, 23 Dec 2008 12:19:26 +0100, Michal Suchanek wrote: > I would like to see a design of a system where resource management > works at least in theory by involving the applications. It sounds like > a good idea but protecting from malfunction of the involved > applications is somewhat challengi

Re: master's thesis on hurd

At Thu, 27 Nov 2008 22:58:07 +0100, Ruben Pollan wrote: > I'm student of computer engineering on spain. I'm about to finish my degree (5 > years of study). I have to do a master's thesis, I'm interesting on hurd and I > think will be a good idea do something about hurd. > > I don't have much exper

Re: [PATCH] ipc/mach_port.c compiler warning fix.

Thanks. Can you please supply a GNU change log? At Tue, 4 Nov 2008 19:06:07 +0530, Shakthi Kannan wrote: > > Fix ipc/mach_port.c compiler warning. > > --- > ipc/mach_port.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/ipc/mach_port.c b/ipc/mach_port.c > inde

Re: EQP

Hi, Jason, > I see multiprogramming as bad as any real sense of > time is lost and all the problems of locking and synchronization arise. How do you deal with the following scenario: Consider a file server: it must handle multiple simultaneous requests; it has shared meta-data needs to be update

Re: EQP

At Thu, 30 Oct 2008 20:56:31 +, Jason Cozens wrote: > My main point is that processors should not be kept busy when it leads > to a bad programming model. This bad programming model as I see it is > multiprogramming. What is different about EQP that it, unlike multiprogramming, results in a g

EQP

Hi Jason, It seems like you've put a lot of thought into this and come up with some good ideas. Thanks for sharing them with us! At Wed, 29 Oct 2008 21:01:33 +, Jason Cozens wrote: > A basic assumption of most OS design that processors have to be kept > busy is questioned Can you clarify wh

Re: Regarding ddekit

At Fri, 24 Oct 2008 12:35:22 +0530, Shakthi Kannan wrote: > DDEKit + DDE26 is run in L4 with L4Env, L4IO modules in user-space. > Moreover on top of DDE26, they use L4Env and L4 modules as server > applications. But, as per the project idea here: > http://www.bddebian.com/~wiki/community/gsoc/proje

Re: current CVS libpthread makes trivial programs linked to it hang

At Sat, 27 Sep 2008 00:55:31 +0200, Samuel Thibault wrote: > There seems to be at least two issues: > > if (_pthread_self ()) > > doesn't actually make sense since _pthread_self() already asserts(self), > so the assertion will be triggered inside it. This is true for the Hurd on Mach implementat

Re: Current state of Xorg on Hurd?

At Tue, 2 Sep 2008 10:15:41 +0200, Arne Babenhauserheide wrote: > * For Desktops: Are pthreads fully implemented, now? Can I get KDE or similar > running? :) What do you mean? With the exception of the real-time extensions and a few bits that are hard to implement without tight integration with

Re: What operations in store_parsed_open() need the privilege?

At Wed, 27 Aug 2008 15:05:59 -0700, Thomas Bushnell BSG wrote: > > On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote: > > I know boot fails and gets EPERM when it calls store_parsed_open, but I > > need to know what operations inside store_parsed_open() fail. Otherwise, > > I don't know how to f

Re: [PATCH] Use standard constants in boot/

Why do you think this change is important? Do you expect this to be applied? If so, you need to include a change log.

Re: Is it possible to replace the scheduler in a Hurd system?

At Tue, 26 Aug 2008 12:46:49 +0200, Arne Babenhauserheide wrote: > Since I just skimmed over scheduling, the question bit me, if itis possible > to > replace the scheduler in a Hurd system as user. > > Is it possible to replace the scheduler for my own processes? > > -> The general scheduler

Re: "Microkernels rule!" and the Hurd

At Mon, 25 Aug 2008 07:53:05 +0200, Arne Babenhauserheide wrote: > Could you write a counter-story/public reply for the Hurd-Wiki? > > It needn't be long, but it should be available online. What are you looking for that I didn't say in my note? Neal

Re: The patch of boot to open a virtual network interface

At Tue, 19 Aug 2008 17:37:14 +0200, zhengda wrote: > Since boot only uses one interface, boot probably accepts only one > interface name from subhurd. This needn't be the case. In fact, it should be able to expose any number of objects as devices. A good interface might be: -d foo=filename1

Re: The patch of boot to open a virtual network interface

At Tue, 19 Aug 2008 15:48:11 +0200, zhengda wrote: > 2008-07-29 Zheng Da <[EMAIL PROTECTED]> > > * boot/boot.c (ds_device_open): Handle the request to open the virtual > network device. > > diff -u boot.old/boot.c boot/boot.c > --- boot.old/boot.c 2008-08-17 18:38:02.0 +0200 > ++

Re: The patch of glibc which allows the user to override the pfinet server

At Wed, 13 Aug 2008 12:41:12 +0200, zhengda wrote: > >> + if (__asprintf (&name, "SOCK_SERV_%d", domain) > 0) > >> +{ > >> + np = getenv (name); > >> + __free (name); > >> +} > >> > > > > You need to check whether asprintf() returns an error code (-1), me

"Microkernels rule!" and the Hurd

--Practice and Experience May 1998 http://portal.acm.org/citation.cfm?id=279869.279875 [4] A Critique of the GNU Hurd Multi-server Operating System Neal H. Walfield and Marcus Brinkmann ACM SIGOPS Operating Systems Review July 2007 http://portal.acm.org/citation.cfm?id=1278901.1278907

Re: The patch of glibc which allows the user to override the pfinet server

At Wed, 25 Jun 2008 16:44:51 +0200, zhengda wrote: > I wonder if it's really necessary to override a single pf server. When porting pppd, I did this regularly; I used an alternative pfinet server but continued to use the default pipe server. I don't see why you think it would be normal to want to

Re: The patch of glibc which allows the user to override the pfinet server

This works in the case where you want to override all pf servers. This case is important. Also important is the ability to override a single pf server in a similar manner. A couple comments on the code: please follow the GNU coding standards. Second, I assume that you left the #if 0 in because yo

Re: client-side memory buffers

At Tue, 1 Apr 2008 18:01:25 -0600, Joshua Stratton wrote: > On Tue, Apr 1, 2008 at 3:50 PM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > > > Please don't top post. > > > > At Tue, 1 Apr 2008 10:48:02 -0600, > > Joshua Stratton wrote: > > > >

Re: client-side memory buffers

Please don't top post. At Tue, 1 Apr 2008 10:48:02 -0600, Joshua Stratton wrote: > > The problem you described was the client owning the memory object, sending > it to the server, and the server having the ability to unmap the memory > because it has ownership, if I understand correctly. No. Th

Re: client-side memory buffers

At Tue, 1 Apr 2008 08:11:30 -0600, Joshua Stratton wrote: > On Tue, Apr 1, 2008 at 2:28 AM, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > > The problem is exactly the same as that with L4's data spaces. When > > the server maps and accesses the memory object, the client

Re: client-side memory buffers

At Mon, 31 Mar 2008 21:23:41 -0600, Joshua Stratton wrote: > > I was on the irc channel talking about the feasibility using client-side > memory buffers for a new network stack. Based on some feedback about > difficulties of implementing this in the Hurd, I thought I would ask anyone > if they th

[task #7895] cthread implementation in terms of pthread interface

URL: Summary: cthread implementation in terms of pthread interface Project: The GNU Hurd Submitted by: neal Submitted on: Thursday 03/27/2008 at 15:26 Category: The GNU Hurd S

Re: Thread model

At Wed, 19 Mar 2008 18:35:56 -0400, Thomas Bushnell BSG wrote: > On Wed, 2008-03-19 at 17:56 +0100, Neal H. Walfield wrote: > > At Wed, 19 Mar 2008 09:58:57 -0400, > > Thomas Bushnell BSG wrote: > > > And throwing a big wrinkle into all that is that many architectu

Re: Thread model

At Wed, 19 Mar 2008 09:58:57 -0400, Thomas Bushnell BSG wrote: > And throwing a big wrinkle into all that is that many architectures do > not make it *possible* for users to handle page faults. The processor > dumps a load of crap on the stack, and the kernel must preserve it > carefully and then

Re: Thread model

At Sun, 16 Mar 2008 08:01:22 +0100, <[EMAIL PROTECTED]> wrote: > On Tue, Mar 11, 2008 at 12:10:17PM +0100, Neal H. Walfield wrote: > > > > using some kind of continuation mechanism: Have a limited number of > > > threads (ideally one per CPU) handle incoming

Re: Thread model

At Sun, 16 Mar 2008 08:21:19 +0100, <[EMAIL PROTECTED]> wrote: > On Wed, Mar 12, 2008 at 05:12:03PM +0100, Marcus Brinkmann wrote: > > > As for the threading model, more than one kernel thread per real CPU > > doesn't seem to make much sense in most cases. > > Well, add a "per processing step" to

Re: Thread model

At Wed, 12 Mar 2008 15:32:26 -0400, Thomas Bushnell BSG wrote: > On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote: > > What you are suggesting is essentially using a user-level thread > > package. (Compacting a thread's state in the form of a closure is a > >

Re: Thread model

Olaf, > The real solution here of course is to fix the thread model I fully agree that given Mach's architecture, one kernel thread per extant RPC is the wrong approach. > using some kind of continuation mechanism: Have a limited number of > threads (ideally one per CPU) handle incoming requests

Re: invalid pthread_t value?

At Sat, 22 Dec 2007 23:15:58 +0100, Samuel Thibault wrote: > The NSPR needs an invalid value for pthread_t, which the Hurd doesn't > officially have. I had proposed them to use -1 (since that would mean > that there are something like 2^32 threads running, which just can't > be...), but they don't

Re: Entropy Patch (as an attachment)

At Mon, 6 Aug 2007 20:14:25 +0200, Samuel Thibault wrote: > > Hi, > > Neal H. Walfield, le Mon 06 Aug 2007 19:56:30 +0200, a écrit : > > > +#ifdef MACH_ENTROPY > > > + /* Let's grab the cylinder numbers for entropy */ > > > + entropy_put

Re: Entropy Patch (as an attachment)

> Index: device/blkio.c > === > RCS file: /sources/hurd/gnumach/device/Attic/blkio.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 blkio.c > --- device/blkio.c25 Feb 1997 21:28:13 - 1.1.1.1 > +++ device/blkio.c6

Re: Fixed Entropy Patch

At Sun, 5 Aug 2007 01:41:54 -0400 (EDT), Michael Casadevall wrote: > Index: device/cons.c > === > RCS file: /sources/hurd/gnumach/device/Attic/cons.c,v > retrieving revision 1.2.4.6 > diff -u -r1.2.4.6 cons.c > - --- device/cons.c 13

Hurd/L4 History

At Wed, 1 Aug 2007 18:30:20 +0200, <[EMAIL PROTECTED]> wrote: > On Wed, Jul 25, 2007 at 09:17:49PM -0400, Michael Casadevall wrote: > > > Hurdng - the project of porting hurd translators to another > > microkernel beside mach such as L4. > > That is not fully correct. The original port to L4 was

Re: [libchannel] Control procedures

I agree with Pierre, please provide some examples. I suspect that if an object implements a wider interface, then the added methods should be written up as a regular mig interface file. That's what mig is there for: the dirty work. As the new routines extend the old interface, just call the basic

Re: passive translators

At Thu, 21 Jun 2007 20:02:35 +0800, Wei Shen wrote: > > On 6/21/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote: > > > > At Thu, 21 Jun 2007 15:37:49 +0800, > > > Could you please give some explanation on "PFINETSERVER=fd:3 myprog > > > 3 > > &g

Re: passive translators

At Thu, 21 Jun 2007 15:37:49 +0800, Wei Shen wrote: > > Hi, > > Could you please give some explanation on "PFINETSERVER=fd:3 myprog > 3http://www.gnu.org/software/bash/manual/bashref.html#SEC38 So, as bash starts myprog, it opens /path/to/pfinet and inserts the resulting file descriptor into the

Re: Defualt socket server overriding

At Wed, 20 Jun 2007 10:30:02 -0700, Thomas Bushnell BSG wrote: > On Wed, 2007-06-20 at 16:20 +0200, Neal H. Walfield wrote: > > When we are just interested in > > overriding a small parts of the environment and the rest represents a > > reasonable default, this may be fine.

  1   2   3   4   5   6   >