tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Proposal for new syscalls: getrusagex and waitx



On Thu, 30 Oct 2008, Quentin Garnier wrote:

> On Thu, Oct 30, 2008 at 10:58:46AM -0500, Eric Haszlakiewicz wrote:
> > On Wed, Oct 29, 2008 at 10:35:24PM +0000, David Laight wrote:
> > > On Tue, Oct 28, 2008 at 04:30:37PM -0700, Matt Thomas wrote:
> > > > It's already used by ioctls for plists.  Basically the kernel
> > > > allocates VM and
> > > > puts the dictionary in it returning the location and size.  User code
> > > > is responsible
> > > > munmap it after its done with it.
> > >
> > > That is trully horrid!
> >
> > hmm.. it doesn't seem too bad to me.  That sounds like a great way to have
> > the kernel allocate memory for a process, similar to how various library
> > functions allocate memory and have a function other than free to release it.
> > (e.g. fopen, openlog, etc...)
> >
> > What's so horrid about it?
>
> I don't what people have against it.  I don't see any other way to have
> data going two ways flexibly in one call.  The usual solution involves
> two calls which is a locking nightmare.

It might be worth pointing out that the above method is the _syscall_ API
and not the end-user API. Although 'user code' is responsible for
converting the externalised version into a dictionary and unmapping the
memory, this would normally be handled in a library stub, and the
programming API would no doubt just pass a prop_dict_t pointer (as the
libprop ioctl routines do)

iain


Home | Main Index | Thread Index | Old Index