On Mon, Sep 29, 2003 at 05:04:05PM -0700, Brian O'Shea wrote: > --- Peter Pentchev <[EMAIL PROTECTED]> wrote: [actually, Pawel wrote this:] > > > Here you got sample kernel module which do this: > > > > > > http://garage.freebsd.pl/usmalloc.tgz > > > http://garage.freebsd.pl/usmalloc.README [and then I replied] > > > > Errrr... but won't this interfere *badly* with userland programs > > which attempt to allocate memory after making the syscall in question? > > Couldn't the user library interface to this new system call just > malloc() the memory first in the process, and then pass the pointer > and size to the kernel via the system call interface? This would > ensure that malloc() doesn't touch the desired range of memory until > it is freed by the user. You'd just have to be careful not to free > it until the kernel is done with it.
This would be my preferred solution, too, although it might mean that when you are not exactly sure of how much memory the kernel will need, you either overallocate and pass a max-size argument (see most of the socket calls like accept(2), getsockname(2), getpeername(2), etc), or you do two syscalls, one for determining the size needed, and another for actually copying the data (see sysctl(3)). The second approach is more robust, but it does have the overhead of an additional syscall and might also possibly be vulnerable to a race (if the data should change between the two invocations). This, of course, could be worked around by having another couple of syscalls for locking and unlocking the data - lock, query size, fetch, unlock - but that would open a whole new can of worms :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true.
pgp00000.pgp
Description: PGP signature
