linux-kernel - Re: [patch 6/9] signalfd/timerfd v1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703110917500.9690@woody.linux-foundation.org>
Date:	Sun, 11 Mar 2007 09:29:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nicholas Miell <nmiell@...cast.net>
cc:	Davide Libenzi <davidel@...ilserver.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/