Re: Reflection and /proc

[slurn@griffin.engr.sgi.com (Scott Lurndal)]

In article <7bga4b$9v2bg@fido.engr.sgi.com>, you write:
|> On Mon, Mar 01, 1999 at 06:51:58PM -0800, Scott Lurndal wrote:

|> > Having the maximum file descriptor in use by a process (not the number of
|> > file descriptors in  use), can be useful in situations  where you need to
|> > close all open  files before performing some task -  if, for example, the
|> > file descriptor limit  is 2048, then most current programs  such as login
|> > which need to close all open  files before invoking the shell, will issue
|> > 2048 close system  calls - if you know the  maximum you can significantly
|> > reduce the number of system calls performed e.g. at login time.
|> 
|> I see  where you're  aiming, but  IMHO this  is not  necessary at  all. The
|> application should do  it's own bookkeeping and know  what file descriptors
|> are  open. As  for your  example: i  very much  prefer the  penalty for  an
|> unecessary system  call to  added complexity and  possible incompatibility:
|> Did you ever try  to port from/to HP-UX? Their pty  handling will drive you
|> crazy...

You've missed the point.  A process cannot know what file descriptors
were in use prior to the fork() operation that created it.   Because 
a login shell needs to start with a known environment, and because the
shell will be started under a different uid than the root which the 
login process is running under, login _must_ close all file descriptors
before invoking the shell (leaving 0, 1 and 2) to avoid any overt
channels (i.e. login probably has the shadow file open....).

|> 
|> > Better solution would be a 'closeall' system call which starts at a given
|> > fd and closes all from fd..getdtablesize().
|> 
|> But that can be done in user-space as  well. Why insist on a system call? I
|> guess i  know your answer:  speed. But then look  at NT, they  sacrificed a
|> reasonably good  architecture (WRT device drivers  and user-interface) when
|> moving from 3.5 to  4.0. Result: a buggy video driver  can crash the system
|> which was very hard in 3.5.

Yes, speed is the concern.  With large systems running many users and 
large databases, having to issue 2048 system calls on each login 
can cause significant performance degradation.

|> 
|> So my argument is: sometimes you need to  know where to draw the line. I am
|> not (yet) convinced we need to cross it here.

Makes little difference when max files is < 255.   Makes huge difference when
max files > 2048;  while linux doesn't currently target the large server
marketplace, when it does, it will have to efficiently support very large
numbers of open files. 


|> > /proc  is  an  overloaded,  overburdened   interface  in  linux.  It  was
|> > originally  designed  as  a  replacement for  ptrace  (/proc  stands  for
|> > process), and linux has extended it to  be more than it was designed for.
|> > The original  /proc implementation  in SVR4  provided a  binary debugging
|> > interface and there  was no text in  the kernel at all, thus  no need for
|> > nationalization in the kernel. Having  the ps(1) command format and print
|> > the /proc/$$/status file  from its binary contents is  much more flexible
|> > from a nationalization standpoint.
|> 
|> I stand corrected.  But that perfectly well demonstrates why i am against
|> proprietary linux extensions.  A split into a SVR4-compliant procfs and
|> a kernfs a la BSD would have made more sense, but...

It is still possible.   Doing the debugger interface for /proc would
be a bit of work, but on the bright side, it would eliminate the 
monstrosity known as ptrace().

|> 
|> > |> Yes. But i  guess the whole discussion  of NLS in the  kernel is moot,
|> > |> because Linus has repeatedly stated that he will never ever accept any
|> > |> such changes. End of topic as far as i am concerned.
|> >
|> > Seems like a reasonable statement, to me.
|> 
|> Am i detecting sarcasm here?  ;-)
|> 

Who me?  Actually, most of the unix vendors have tried hard to 
keep localization and internationalization concerns out of the
kernel as much as possible (to the point where the standards 
recommend that the characters representing file names be from the
portable character set so they will be consistent across all
locales).

scott
-
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