Re: Larger dev_t

[Alexander Viro]

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.