> > Both user and kernel bits are, of course, improvable, but
> > this should at least show that the approach works.
> Prefer the "char device" approach myself. open = create, read =
> down, write = up. Following (completely untested) patch stole your
> work to implement "/dev/usem". Added bonus is the ability to mmap the
> fd to map in the shared page, which means the fd carries a shared
> region with it (hey, it was 14 more lines).
Nice hack. I'm not particularly attached to my implementation
but:
* Dedicating a whole page per semaphore seems rather
expensive for a "lightweight" primitive.
* Possibly ditto even file descriptors. I may want
several thousand of these.
* Are there any numbers for the VFS overheads? There
are quite a few lock acquires in there, even if the
paths are fairly short.
* It would be nice to keep the userspace structure
opaque (except for the counter) and able to share
it transparently between processes.
Actually, the more I look at Linus's original idea, the more
sense it seems to make (and the more I regret scrapping my
almost-complete implementation of it for the fd idea :)
(Oh, and you forgot:
> +static struct file_operations usem_fops = {
> + read: read_usem,
> + write: write_usem,
> + open: open_usem,
> + release: release_usem,
mmap: mmap_usem,
> +};
)
Cheers,
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/