> Ah, yes. I see my error now.
But just the one, eh? I guess we'll have to keep working on you to attain
full repetence.
> Every task gets associated with it a "restricted name". (Alternative
> name suggestions welcome.) This is a send right, and I don't envision
> anyone ever sending messag
Roland McGrath <[EMAIL PROTECTED]> writes:
> I have been assuming that in your proposal task_create completes without
> waiting for this notification to be received and processed. If the
> notification is a message containing the task port of the creator task,
> then this will arrive as MACH_POR
> The original Hurdish ancestor only has to remain alive for long enough
> for proc to establish its record and copy the owner ID. If the kernel
> actively notifies proc as soon as the process is created with this
> information, we can be guaranteed it gets captured and recorded.
I have been ass
Roland McGrath <[EMAIL PROTECTED]> writes:
> > That's correct, but in the model of just "return null if the parent is
> > gone", why is this a problem?
>
> This model makes it impossible to guarantee an assignment of the task to
> its original Hurdish ancestor. I think that guarantee is the mos
> That's correct, but in the model of just "return null if the parent is
> gone", why is this a problem?
This model makes it impossible to guarantee an assignment of the task to
its original Hurdish ancestor. I think that guarantee is the most valuable
part of the feature, because it allows unre
Roland McGrath <[EMAIL PROTECTED]> writes:
> > * Mach needs a facility to find out what task is the parent of
> > a given task.
>
> I'm not sure if there was a particular motivation for this other than the
> kind of thing in proc that I suggested.
Also a process accounting motivation here
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Yes, this would work out the way you described it. How about Mach keeping
> track of the task hierarchy? I am not sure how exactly this would need to
> be implemented. Mach could keep a pointer to the parent task in the task
> structure. Someone
> * Mach needs a facility to find out what task is the parent of
> a given task.
I'm not sure if there was a particular motivation for this other than the
kind of thing in proc that I suggested. I'm not sure there is a reason to
do the kernel interface I suggested (propagating a value that pr
On Mon, May 14, 2001 at 02:59:43AM -0400, Roland McGrath wrote:
[msgport, boot command line etc]
What you write makes sense. I didn't notice msgport before. It looks like
it's a great tool.
> > BTW, what output can we expect from a pstree on the Hurd? Will the hierarchy
> > of a sub-Hurd show
> We don't need to rely on the PID 2 info:
>
> /gnu/root/D1:2- 7 153M 9.67M 0:00.00 0:12.43 /boot/gnumach.gz root=hd2s5
>
> So, the kernel is clearly identified by the program name at least.
That is not really clean or robust. I mean:
(sh -c "exec -a /boot/gnumach.gz /bin/sleep
On Mon, May 07, 2001 at 06:19:42PM -0700, Thomas Bushnell, BSG wrote:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > > Makes perfect sense. Looking at the output of ps to get the kernel command
> > > line is a natural thing to do, and much better than /proc/cmdline indeed.
> > > I don't see
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Makes perfect sense. Looking at the output of ps to get the kernel command
> > line is a natural thing to do, and much better than /proc/cmdline indeed.
> > I don't see any explicit need for a fancier programmable interface either.
>
> Well, I'm no
> Makes perfect sense. Looking at the output of ps to get the kernel command
> line is a natural thing to do, and much better than /proc/cmdline indeed.
> I don't see any explicit need for a fancier programmable interface either.
Well, I'm not entirely sanguine about the "PID 2 is the kernel" co
On Sat, May 05, 2001 at 08:22:42PM -0400, Roland McGrath wrote:
> The simplest kludge is to just use "ps --fmt=%command 2" or the libps
> equivalent thereof. PID 2 is always the kernel task, and the existing init
> hack diddles things so that the kernel command line appears like a normal
> proces
> I was wondering about host_get_boot_info and if it could be used to provide
> /proc/cmdline in Neals procfs. I don't know about any standard interface to
> get a kernel command line.
I don't recall ever having noticed the host_get_boot_info interface.
That certainly seems like a natural thing
On Fri, May 04, 2001 at 10:26:18PM +0200, Marcus Brinkmann wrote:
> This can be pasted into the bootscript via ${kernel-command-line}, and
> passed to init via -K. I think it can be passed to init by adding this to
> --bootflags of the root filesystem. Can someone confirm this?
>
> /hurd/ext2fs.
16 matches
Mail list logo
