Re: Reflection and /proc

[Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>]

Scott Lurndal wrote:
>That is why all login (and some inetd) programs have code similar to the following:
>
>	for(i=3; i<getdtablesize(); i++)
>		(void) close(i);
>
>It would be much more efficient to just say:
>
>	closeall(3);	/* Close 3 and higher */

This would work for this specific purpose. How about something more
flexible:

	fd_set	list_of_fds;
	...
	FD_ZERO(&list_of_fds);			   /* initialize list */
	get_proc_info(OPEN_FILE_SET,&list_of_fds); /* the new "something" */
	for (i=3; FD_ISSET(i,&list_of_fds); i++)
	    (void) close(i);

The thing I am considering here are additional files that may be desired
(such as a database socket connection, not necessarily on file id 3). It
could also be used to pass file ids to be monitored via a select. Granted
that it is desirable to do a fork(), dup, close sequence to compact the
list of file ids, but it wouldn't be necessary. This also simplifies the
implementation: the get_proc_info only returns the file id set from the
process task structure. I did intend the "get_proc_info" thing to be
able to retrieve other data about the process, hence the OPEN_FILE_SET
as a selector for the data desired.

This also removes the close loop from being in the kernel and provides
a way to retrieve other per user/process limits, capabilities, permissions
in a more controled manner. IMHO the current method of having a single
system call per data type (getgroups, getdtablesize, gettimes, getpid,...)
seems excessive.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html