Re: [MiNT] expanded /proc vs new /kern

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Martin-Eric Racine wrote:
> 
> Hello,
> 
> A while back, I asked the list about why /proc could not be fixed
> to allow long filenames, so that names like "rpc.nfsd" would not
> show as "rpc.<pid>" and was told that several applications expect
> /proc to be an 8+3 filesystem and depend upon that.
> 
> Nobody has yet brought forth any application, assides from "ps"
> (which Julian said he could easily recompile to support longer
> than 8+3), that actually _depend_ upon /proc being a 8+3.

Just a guess: top, then that tool that assigns default priorities to
processes based on the name (shipped with N.AES I think), a tool that
was written by me and is not official ...

> 
> Given that most of those I can think of live in the Unix domain,
> not as commercial GEM applications, I cannot think of any reason
> why they couldn't be patched and recompiled.
> 
> I would appreciate someone _clearly_ justifying why /proc cannot
> be expanded and also listing which apps really depend upon the
> 8+3 limitation.

I would not recommend changing that behavior for several reasons:

1. It does break compatibility.  Agreed, isn't it?

2. It would require a major rewrite of procfs.c in the kernel (and many
other parts).  Currently, the "/proc-name" of any process is held in an
array of fixed size.  Dropping that 8+3 scheme would mean that the
memory for the name has to be allocated dynamically.  This is generally
preferable but it's IMHO unnecessary here, see next point.  BTW, this
change would affect the entire kernel since that fixed size array is
actually located in the process context.

3. There is no real need for it.  There are probably few applications
that actually interpret anything into the filename.  A proper tool
simply checks if the name matches the scheme %08s.%03d and then
retrieves all other information means of ioctl.  It is simple to inquire
the full filename of the executable by the kernel.

I basically agree with you, 8+3 is a restriction here.  But only a minor
one and I wouldn't take the risk of unforeseen crashes for a relatively
small gain.  Besides, I don't know how much work it actually means to
change things.  And since it is not really urgently needed ...

Ciao

Guido