5 Aug
2014
5 Aug
'14
3:26 a.m.
On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm(a)mcvoy.com> wrote:
Seem like even Roger liked it:
https://lwn.net/lwn/1998/0226/sunproc.html
:-) There are a few different issues here. Linux exports a lot of
interesting info that Solaris doesn't. It's hard not to like that. Where
they put it, who cares. The unix filesystem hierarchy wasn't exactly
planned out by neat freaks.
On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy
wrote:
> On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote:
> > We in Solaris designed /proc as a tool for developers to build
innovative
> > solutions, not an end-user interface. The
Linux community believes
that
> > 'cat /proc/self/maps' is the best
user interface, while we believe
that
> > pmap(1) is right answer. The reason for this
is that mdb(1), truss(1),
> > dtrace(1M) and a host of other tools all make use of this same
information.
> > It would be a waste of time to take binary
information in the kernel,
> > convert it to text, and then have the userland components all write
their
> > own (error prone) parsing routines to
convert this information back
into a
> > custom binary form. Plus, we can change the
options and output format
of
> > pmap without breaking other applications
that depend on the contents
of
> > /proc.
>
> I come from SunOS background and have had more than a few /proc
discussions
> with Roger Faulkner (who I believed did the
System V /proc at Bell
Labs?).
>
> I get the arguments above but I don't buy 'em. linux really got /proc
> right in terms of usefulness.
Digging binary blobs out of the kernel
> and translating them sucks. I've done, I've written kmem drivers for
> ps, I understand how it works. I far prefer the pure ascii model that
> Linux has.
Part of the argument was more or less that the binary model allows a richer
set of tools to be built on top of it, and that those tools provide a
better interface to the info. Does Solaris have a richer set of tools than
Linux in this regard? I think so, but I don't know how much of this is owed
to the difference between binary and text interfaces in /proc.
Last time I checked, Linix had no pcred(1), for example. top(1) doesn't
provide nearly as much info as prstat(1) -- for example, prstat -mL. Why
that is, I don't know. Plus, prstat is marginally less resource intensive.
Anything as sweet as (k)mdb in linux? Forget it. Maybe that's because Linus
was so resistant to having a debugger in the kernel for so long? DTrace?
Well, sort of -- a port of dtrace! But I'm really at an unfair disadvantage
here. *Why* Solaris has such better tools, you would know better than me. I
only know that it does. As for the second part, that writing the tools that
use the binary interface is unpleasant, again I have to defer to you. I've
never done that.
> I also get that Linux turned /proc into
/whatever/I/think/I/need/today
> and that makes purists grit their teeth. None the less, if you give
> me a choice I'll take the linux way. Want to see what files you have
> open?
>
> ls -l /proc/$$/fd
I think this would work in solaris, maybe linux too: pfiles $$
> Etc. Really easy to poke around and figure stuff
out as needed and no
> rats nest of header files to decode the structures.
Again, that's what the tools are for. If a tool doesn't give me the info I
need in Solaris, I guess I'm SOL. In Linux, *maybe* I'd have a chance of
finding it in /proc. :-)