On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > UNIX has pid's for "process" handles, and "file descriptors" for just
> > about everything else.
>
> And I imagine that somebody will come up with way of getting a fd for a
> process sooner or later.
Well, /proc/<pid>/ is about as close as you get. And that's largely
inspired by a Plan-9'ish thing that does indeed expose processes as files.
The problem with processes is that they are actually so *complicated* that
trying to describe them with a single file isn't all that useful (you
could use tons of different ioctl's to do different operations, but that's
against the "stream of bytes" model in UNIX, and even more so against the
whole Plan-9 model).
> Actually, I was thinking reducing struct file to the bare minimum, and
> then using that as the common header shared by object-specific
> structures. I don't know how unpleasant that would be from a memory
> allocation perspective, though.
It would probably not be a bad idea, but I just doubt that it makes much
of a difference, at least not for timerfd/signalfd files. There likely
just won't be that many of them (I'd expect that processes that use them
would normally just have one or two of each).
It might be more relevant for things like sockets and pty's: do a
ls -l /proc/*/fd
and see what kind of files you have open, and I suspect most of the files
will actually be sockets on a normal desktop setup, and even more so on
some network server thing. And yes, it might be nice to avoid allocating
memory for the (unnecessary) readahead and f_pos state, but in the end
you seldom really have all *that* much memory allocated for file
descriptors. The real memory use ends up being elsewhere..
IOW, I don't think it's a bad idea per se, I just doubt that it is worth
the complexity and effort.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
