On Sun, May 06, 2001 at 10:04:12PM -0400, Roland McGrath wrote:
> > Now, we actually leak all these urefs (for example, when calling
> > gettimeofday). Even for a process calling mach_host_self() 1000 times a
> > second it would take 50 days to overflow. For purity, should we deallocate
> > the po
> Now, we actually leak all these urefs (for example, when calling
> gettimeofday). Even for a process calling mach_host_self() 1000 times a
> second it would take 50 days to overflow. For purity, should we deallocate
> the port? Overflow is set to TRUE in this code path, so it might
> be okay to
On Sun, May 06, 2001 at 08:33:56PM -0400, Roland McGrath wrote:
> > So is it true that port 23 (in my case above) is the host name port for all
> > tasks of the system? It must be, as realport.host_self is a global, and it
> > is passwd through as the mach port (although it is an ipc_port_t).
>
>
> Well, it seems that mach_host_self() is rather special in that it refers to
> a kernel object (port in the kernel name space) rather than an object from
> another user task.
Ports is ports.
> I didn't expect it to just increase the uref and return the port number,
> as I don't own the receive
On Sun, May 06, 2001 at 04:46:45PM -0400, Roland McGrath wrote:
> > I don't understand why mach_host_self() doesn't acquire a new port name and
> > leaks a port if not deallocated. In other words, I expected the following to
> > leak ports, but it doesn't:
> >
> > main ()
> > {
> > while (1)
>
> 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
> I don't understand why mach_host_self() doesn't acquire a new port name and
> leaks a port if not deallocated. In other words, I expected the following to
> leak ports, but it doesn't:
>
> main ()
> {
> while (1)
> mach_host_self(); /* Returns 23 on each and every call. */
> }
I don't kn
> why is mach_port_get_receive_status just returning a boolean if send right
> exists (the mach code has the equivalent of "srights = ip_srights > 0"), but
> the exact number of extant send once rights, while there is a special debug
> call mach_port_get_srights to get the exact number?
This is a
¿©·¯ºÐ¿¡°Ô °¡Àå ÇÊ¿äÇÏ°í À¯ÀÍÇÑ ÄÄÇ»ÅÍ °ü·ÃÇÁ·Î±×·¥À»
ÆÄ°ÝÀûÀ¸·Î ½Ñ °¡°Ý¿¡ °ø±ÞÇÕ´Ï´Ù
ÃֽŰÔÀÓ. À¯Æ¿°ü·ÃÇÁ·Î±×·¥. MP3. ºñµð¿À½Ãµð µîµî
¸ðµç ÇÁ·Î±×·¥À» ÆǸÅÇÕ´Ï´Ù
¹°·Ð ½Å¿ë °ÆÁ¤À» ÀüÇô ½Å°æ¾²Áö ¸¶½Ê½Ã¿ä
¾ÐÃàÈÀϼÓÀÇ ³»¿ëÀ» º¸½ÅÈÄ Àüȳª ¸ÞÀÏ·Î ¿¬¶ôÁֽʽÿä
ÀÌ ¸ÞÀÏÀ» º¸³½ ¾ÆÀ̵ð·Î´Â ¿¬¶ôÀÌ µÇÁö ¾
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
Hi,
I don't understand why mach_host_self() doesn't acquire a new port name and
leaks a port if not deallocated. In other words, I expected the following to
leak ports, but it doesn't:
main ()
{
while (1)
mach_host_self(); /* Returns 23 on each and every call. */
}
mach_task_self is cac
Hi,
why is mach_port_get_receive_status just returning a boolean if send right
exists (the mach code has the equivalent of "srights = ip_srights > 0"), but
the exact number of extant send once rights, while there is a special debug
call mach_port_get_srights to get the exact number?
Just wonderi
Figure out what lock file name it is actually trying to use.
It is probably trying to use a file name in a nonexistent directory.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
I disabled the gateway setting code in PPP in hopes of getting it to dial in and
this is what I got (from /var/log/syslog):
y 6 00:39:51 localhost ppp[7087]: Phase: Using interface: tun0
May 6 00:39:51 localhost ppp[7087]: Phase: deflink: Created in closed state
May 6 00:39:51 localhost ppp[70
14 matches
Mail list logo
