> Alexander Viro writes:
> > On 15 Nov 1999, Doug Alcorn wrote:
>
> >> The point of /proc is to provide user space access to this information
> >> without having to make syscalls to the kernel.
> >
> > The point of /proc is to avoid direct poking into the kernel memory.
> > Moreover, in its current form it is highly non-portable. And that includes
> > portability between 2.0/2.2/2.4. Please, _stop_ abusing it. Basically,
>
> Stop abusing it? Hey, fine, I can make /bin/ps setuid-root again.
abuse: v. to put a wrong or improper use.
> > _nobody_ promises that any given file in /proc will remain there in 2.4.
> > Most likely 2.4 will keep compatibility symlinks, but even that is not
> > guaranteed. If k3wl krapplications will break - too bad for them.
>
> If these go, the world breaks for the k3wl /bin/ps krapplication
> and related junk:
>
> /proc/cpuinfo (used by glibc AFAIK, to count processors)
> /proc/ksyms
> /proc/loadavg
> /proc/meminfo
> /proc/stat
> /proc/tty/drivers
> /proc/uptime
We will need some compatibility symlinks and the stuff you've mentioned is
going to be there. BTW, /proc/<pid>/tty is in the queue.
It would be reall nice if we had a generally accepted library with sane
interface that could be used by everything. Then the changes would be much
easier. Right now we have all sorts of spiffy little utilities (seriously
resembling DOS BBS collections - bad symptom in itself), each of them
doing its own thing in its own way. Yes, if they would directly use the
kernel memory it would be even worse. But even in the current form it's a
mess.
> For the sysctl program used in boot scripts, add /proc/sys/ to the list.
/proc/sys is pretty regular and reasonable. Besides, sysctl(8) should not
use procfs - all we need is sysctlbyname(2) (check BSD manpages).
> Possible clean-up procedure: make everything except the process
> directories be invisible. Add a new filesystem, handled by the
> same driver, that makes non-process things visible and process
> directories disabled. Call it "kern" if so desired.
What a horrible kludge instead of honest union-mount ;-) However,
things are trickier than that. Code-wise procfs proper is already
separated - base.c and array.c are independent from the rest and as soon
as the thing will get superblock of its own we will be able to remove
remaining checks for inumber ranges. The real problem is not there. It's
in the fact that we had _no_ namespace policy in /proc. For many years.
How would you like little gems like /proc/ip2mem or /proc/h8? No, the
former has nothing to IP. And it has nothing to do anywhere near the root.
We have more or less regular parts of /proc - per-process stuff
and /proc/sys (aka kernfs for BSD folks). The rest falls into several
classes. There are "subsystem information" animals. They don't fit into
sysctl() interface (albeit some of them might go there) and they are
usually read-only. Not a big deal, except that we have 1001 format and
_really_ messy namespace. Finding relevant thing may be very nontrivial.
meminfo, loadavg, etc. would happily go there. There are oddballs that
allow write() - usually it's a sysctl wanting to happen. And there are
real horrors - come on, ioctl() on /proc file... (yes, we have such
beasts; check /proc/mtrr for one). And there is kcore/ksyms/kmsg group.
So far cleanup had been kernel-only, but now we are almost at the point
where changes will become visible for userland. For the most of those
files nobody will really care, but for some of them we will need
compatibility links and they will stay for a while. As for the rest...
Just about anything will be better than current ad-hockery.
Nobody talks about dropping the fs-based interface to this stuff
and reverting to /dev/kmem games. But there is a serious need to reshuffle
this bag of #@$! into coherent state.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/