On Mon, May 07, 2001 at 11:19:08PM -0700, Thomas Bushnell, BSG wrote:
> The host port will
> stay around always and forever, no matter how many or how few there
> references there are, and there is no such thing as a "port leak" of
> references to the host port, because the host port protocol does
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Overflowing the ip_srights reference count in the port structure.
Right. So since mach_host_self sets OVERFLOW, the result of maxing
out the user refs is harmless. (If it didn't set it, then
mach_host_self might sometimes get an error; that would
On Mon, May 07, 2001 at 06:33:52PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > 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
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
Hi folks,
Should help-hurd be emphasized as the primary hurd hacking help (say that
three times fast!) mailing list at the hurd.gnu.org website? It seems that
bug-hurd is acting in that capacity at this time. Either approach is
acceptable to me. It seems to me that bug-hurd was being used in this
Roland McGrath <[EMAIL PROTECTED]> writes:
> If sysvshm were some magical new kind of facility, it wouldn't be so easy
> to implement it with code just like other facilities we already have. So
> you can relate what the actual meat of the sysvshm functionality is to
> other facilities, and not j
> > Can you give concise answers to these questions?
>
> Hopefully.
>
> > 1. What facility does your new RPC interface provide
> >over using the normal filesystem interfaces with
> >some convention of fixed-length file names for shm keys?
>
> It adds 2.1 new functions. First, it adds:
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Faults are, well, ok. We'll never be able to give them on a
> > default-pager based interface, of course.
>
> What I'd had in mind was new default_pager_object calls to fix the size of
> a memory object (and clear pages past the new end). Those ch
> I don't have the previous messages, but I did grasp this much from the
> code. It might be that this is ultimately just a short-term hack for
> a tmpfs, however, and we have to hobble together what kludges work
> with it. I have some ideas about what the Right Thing would be; they
> all requir
Roland McGrath <[EMAIL PROTECTED]> writes:
> > It has occured to me: should suid binaries on a user mounted file system
> > be run as the owner of the filesystem?
>
> Yes, probably. Moreover, what it means to get the auth port for running a
> setuid binary should be the very same thing it means
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> While I am looking at stupid little omissions that don't make a real
> difference: In proc/host.c we call host_kernel_version and use the result
> without making sure it is actually null terminated. The kernel uses strncpy
> to copy out the string.
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> 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 TRU
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> 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_g
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Take a look at both ext2fs and ufs. Neither deallocates its reference to
> > the underlying node.
>
> Contrary to the propaganda of the time, Bushnells do write bugs.
> Copying them doesn't make them less wrong.
Oops, I'm wrong.
It's not a bug, I
Roland McGrath <[EMAIL PROTECTED]> writes:
> > Take a look at both ext2fs and ufs. Neither deallocates its reference to
> > the underlying node.
>
> Contrary to the propaganda of the time, Bushnells do write bugs.
> Copying them doesn't make them less wrong.
Indeed, those are bugs. Miles (in
Roland McGrath <[EMAIL PROTECTED]> writes:
> Despite what Thomas has said, I believe that it is reasonable for
> diskfs_truncate to return with allocsize arbitrarily higher than what was
> asked for. (It's up to the filesystem how it does allocation, and if its
> method overallocates a truncated
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
Neal H Walfield <[EMAIL PROTECTED]> writes:
&> On Fri, May 04, 2001 at 02:58:51PM -0700, Thomas Bushnell, BSG wrote:
> > Neal H Walfield <[EMAIL PROTECTED]> writes:
> >
> > > I have a patch ready to go that changes all int -> int32 and off_t and
> > > ssize_t to int64. Do you want this. Would
Hi,
I wrote this for inclusion in the What Is area of the web page. It is only
a first draft, and not complete yet, but after the horrible confusion
yesterday, it would be nice if someone could skim over it. Any comments
appreciated!
Thanks,
Marcus
2001-05-07 Marcus Brinkmann <[EMAIL PROTEC
> Can you give concise answers to these questions?
Hopefully.
> 1. What facility does your new RPC interface provide
>over using the normal filesystem interfaces with
>some convention of fixed-length file names for shm keys?
It adds 2.1 new functions. First, it adds:
shm_getid
On Fri, May 04, 2001 at 02:58:51PM -0700, Thomas Bushnell, BSG wrote:
> Neal H Walfield <[EMAIL PROTECTED]> writes:
>
> > I have a patch ready to go that changes all int -> int32 and off_t and
> > ssize_t to int64. Do you want this. Would you like something else?
>
> No, I think this is the so
21 matches
Mail list logo
