On Thu, Jul 12, 2001 at 04:34:45PM -0400, Roland McGrath wrote:
> I didn't look closely, but now I am thinking twice. If the data is small
> enough to fit inline, and you use a separate reply stub, then you can send
> it without copying. That ought to be the common case.
This would be what you
On Thu, Jul 12, 2001 at 04:34:45PM -0400, Roland McGrath wrote:
> > On Wed, Jul 11, 2001 at 04:49:17PM -0400, Roland McGrath wrote:
> > > That's fine by me if it's tested. BTW add -p to your diff switches.
> >
> > Actually, I goofed up. The arguments to the reply stub have not been
> > changed
> On Wed, Jul 11, 2001 at 04:49:17PM -0400, Roland McGrath wrote:
> > That's fine by me if it's tested. BTW add -p to your diff switches.
>
> Actually, I goofed up. The arguments to the reply stub have not been
> changed by my patch. In fact, as we now copy the user data all the time, a
> sepe
On Thu, Jul 12, 2001 at 09:06:12PM +0200, Marcus Brinkmann wrote:
> On Wed, Jul 11, 2001 at 04:49:17PM -0400, Roland McGrath wrote:
> > That's fine by me if it's tested. BTW add -p to your diff switches.
>
> Actually, I goofed up. The arguments to the reply stub have not been
> changed by my pa
On Wed, Jul 11, 2001 at 04:49:17PM -0400, Roland McGrath wrote:
> That's fine by me if it's tested. BTW add -p to your diff switches.
Actually, I goofed up. The arguments to the reply stub have not been
changed by my patch. In fact, as we now copy the user data all the time, a
seperate reply s
That's fine by me if it's tested. BTW add -p to your diff switches.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Wed, Jul 11, 2001 at 12:18:32AM +0200, Marcus Brinkmann wrote:
> For the auth server, I will send a patch for review soon.
Here it comes. I am not too happy about the macro magic, but it works out
ok. The code for S_auth_getids is completely reduplicated in
S_auth_server_authenticate. Do yo
On Sat, Jun 30, 2001 at 08:54:12PM -0700, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > I would suggest dealloc + iohelp_return_malloced_buffer, as usually those
> > uid vectors are small, and keeping them on one page each is a waste of
> > space.
>
> iohelp_re
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I would suggest dealloc + iohelp_return_malloced_buffer, as usually those
> uid vectors are small, and keeping them on one page each is a waste of
> space.
iohelp_return_malloced_buffer is not available in auth, nor should it
be just duplicated
On Wed, Jun 27, 2001 at 02:52:17PM +0200, Marcus Brinkmann wrote:
[auth_getids]
> This one is questionable. auth_getids uses idvec_copyout, which provides
> the internal buffer:
>
> inline void idvec_copyout (struct idvec *idvec, uid_t **ids, uid_t *nids)
> {
> if (idvec->num > *nids)
>
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> It just occured to me that it is probably safe to use malloc()'ed buffers,
> as long as you don't use dealloc with them? It's a bit awkward, because
> this is mixing Mach level with glibc level stuff. I don't know if it is
> safe to return a buffer
Hi,
ok, here a detailed analysis. It seems I found four other bugs along the
way. ;)
On Wed, Jun 27, 2001 at 12:35:25PM +0200, Marcus Brinkmann wrote:
> routine proc_getprocinfo (
> process: process_t;
> which: pid_t;
> inout flags: int;
> - out procinfo:
On Wed, Jun 27, 2001 at 02:52:17PM +0200, Marcus Brinkmann wrote:
> So, this should not use dealloc. However, idvec->ids is NOT a mmap'ed
> buffer! It is a malloced/realloced buffer (coming from
> libshouldbeinlibc/idvec.c).
>
> Is it correct that this should better use iohelp_return_malloced_b
13 matches
Mail list logo
