Messages in this thread | | | Date | Wed, 28 Mar 2001 16:46:34 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Larger dev_t |
| |
On Wed, 28 Mar 2001, H. Peter Anvin wrote:
> Martin Dalecki wrote: > > > > > > devfs -- in the abstract -- really isn't that bad of an idea; after all, > > > > Devfs is from a desing point of view the duplication for the bad /proc > > design for devices. If you need a good design for general device > > handling with names - network interfaces are the thing too look at. > > mount() should be more like a select()... accept()! > > > > And what on earth makes this better? I have always thought the socket > interface to be hideously ugly and full of ad-hockery. Its abstractions > for handle multiple address families by and large don't work, and it > introduces new system calls left, right and center -- sometimes for good > reasons, but please do tell me why I can't open() an AF_UNIX socket, but > have to use a special system call called connect() instead.
Aye. The real problem with mount is that it always had been pretty heavy-weight. Especially mount(8). I've done some (very rough) testing on my tree - for ramfs-style filesystem latency of mount(2) is about 20% worse than latency of open(2). And it definitely can be improved - right now I'm interested in getting the code cleaned.
mount(8) is a problem, but in nosuid namespace we can seriously cut down on checks in the thing. And I'm very interested in designs that would allow killing /etc/mtab - dropping it would allow very easy mounting.
- 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/
| |