[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)
Main Index |
Thread Index |