30 Sep
2017
30 Sep
'17
3:17 p.m.
Warner Losh:
It's an abundance of caution thing. This code had security problems in the
past, we're not 100% sure that we've killed all the issues, though we
believe we have.
====
And if there isn't anyone who's actively interested in the
code, willing to dig in to clean it up and make security
issues less likely, deal with multiprocessing matters, and
so on, that's a perfectly reasonable stance.
I think it's an unfortunate result, and I wonder how much
of it comes from a cultural view that sysctl >> /proc.
(Recall how Ken and Dennis originally resisted Doug's push
for pipelines and filters, because--as Dennis once put it
in a talk--it just wasn't the way programs worked?)
But as someone who is sometimes credited with removing
more code than he wrote while working on the latter-day
Research kernel, it's hard for me to argue with the principle.
A lot of the code I tossed out was complicated stuff that
was barely used if used at all, and that nobody was willing
to step up to volunteer to maintain.
Norman Wilson
Toronto ON
30 Sep
30 Sep
8:29 p.m.
New subject: UNIX of choice these days?
I never really considered proc vs sysctl as deeply as this discussion.
Both seem like a little bit of a stretch and cause some impedance
mismatch in ways they are actually used. For instance on FreeBSD you
can pass opaque structures around and that's how some of the utils
work -- these aren't displayed using sysctl(8). So now you have ABI
over a text API anyway.
I seem to recall proc is loosely deprecated in Linux anyway in favor
of sysfs. GregKH mentioned people misuse both, for instance making
them output pretty histograms instead of simple text values, that
defeat the fundamental design tenants of these interfaces -- which is
to try and maintain a stable API.
One thing I think Linux did pretty well is the whole object
orientation in C thing with kobject, and that nets you automatic sysfs
directories and nodes for pretty much everything.
Lots of gymnastics trying to solve a fundamentally more simple problem
of a text API vs ABI, hierarchy and maybe some object orientation. At
risk of ridicule, I think the AIX ODM was the best planned and
executed take on all that :)
Regards,
On Sat, Sep 30, 2017 at 8:17 AM, Norman Wilson <norman(a)oclsc.org> wrote:
Warner Losh:
It's an abundance of caution thing. This code had security problems in the
past, we're not 100% sure that we've killed all the issues, though we
believe we have.
====
And if there isn't anyone who's actively interested in the
code, willing to dig in to clean it up and make security
issues less likely, deal with multiprocessing matters, and
so on, that's a perfectly reasonable stance.
I think it's an unfortunate result, and I wonder how much
of it comes from a cultural view that sysctl >> /proc.
(Recall how Ken and Dennis originally resisted Doug's push
for pipelines and filters, because--as Dennis once put it
in a talk--it just wasn't the way programs worked?)
But as someone who is sometimes credited with removing
more code than he wrote while working on the latter-day
Research kernel, it's hard for me to argue with the principle.
A lot of the code I tossed out was complicated stuff that
was barely used if used at all, and that nobody was willing
to step up to volunteer to maintain.
Norman Wilson
Toronto ON
9:56 p.m.
New subject: UNIX of choice these days?
On Sep 30, 2017, at 1:29 PM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
I seem to recall proc is loosely deprecated in Linux
anyway in favor
of sysfs. GregKH mentioned people misuse both, for instance making
them output pretty histograms instead of simple text values, that
defeat the fundamental design tenants of these interfaces -- which is
to try and maintain a stable API.
One thing I think Linux did pretty well is the whole
object
orientation in C thing with kobject, and that nets you automatic sysfs
directories and nodes for pretty much everything.
The Linux /sys fs is truly bizarre. On a RaspberryPi running Linux 4.4.21+:
$ find /sys | wc # total entries
11448
$ find /sys -type l | wc # count of symlinks
1077
$ find /sys -type f | wc # count of "regular" files
8931
I am not sure exposing most everything via a namespace in this
manner is such a good idea (or at least in "good taste" :-)
Interfaces should be lean.
Similarly the /proc fs is quite strange. Why does it have any
non process subdirectory?
$ echo /proc/[0-9]* | wc -w # count of processes
142
$ echo /proc/[^0-9]* | wc -w # count of non-process directories
58
Compare:
Linux (raspberryPi + X windows):
$ echo /proc/[0-9]* |wc -w # how many processes
142
$ find /proc/[0-9]* | wc -l # how many proc related files+dirs
66153
FreeBSD (10.3 amd64+zfs+4 lightweight jails):
$ echo /proc/[0-9]* | wc -w # how many processes
123
$ find /proc/[0-9]* | wc -l # how many proc related files+dirs
1075
Plan9 (mostly quiescent):
$ echo /proc/[0-9]* | wc -w
64
$ du -a /proc/[0-9]* | wc -l
1235
Anyone feeling sad about /proc in FreeBSD should consider
the alternative!
10:37 p.m.
New subject: UNIX of choice these days?
To understand the Linux sysfs, you have to understand what problem
they are trying to solve. It is self inflicted, but it solves a
problem in a way the community values. Because the kernel is an
independent project versus libc (glibc, musl, Bionic, etc), and
because the base system is from others as well (coreutils, busybox,
systemd), Linus has become fanatical about ABI stability. The simple
text interfaces allow the kernel to change haphazardly without much
planning, and still retain binary compatibility. In terms of code
churn and needless KPI proliferation, Torvald's "masturbating monkeys"
insult toward OpenBSD holds up pretty well for his own crew :)
Operating systems (using subtle terminology that excludes "Linux"
without more specification) don't have that problem.
I haven't played with Plan9 at all. Read some code, the TCP stack was
cute but unrealistically simplistic. I need to take it for a spin.
Regards,
On Sat, Sep 30, 2017 at 2:56 PM, Bakul Shah <bakul(a)bitblocks.com> wrote:
On Sep 30, 2017, at 1:29 PM, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
I seem to recall proc is loosely deprecated in
Linux anyway in favor
of sysfs. GregKH mentioned people misuse both, for instance making
them output pretty histograms instead of simple text values, that
defeat the fundamental design tenants of these interfaces -- which is
to try and maintain a stable API.
One thing I think Linux did pretty well is the
whole object
orientation in C thing with kobject, and that nets you automatic sysfs
directories and nodes for pretty much everything.
The Linux /sys fs is truly bizarre. On a RaspberryPi running Linux 4.4.21+:
$ find /sys | wc # total entries
11448
$ find /sys -type l | wc # count of symlinks
1077
$ find /sys -type f | wc # count of "regular" files
8931
I am not sure exposing most everything via a namespace in this
manner is such a good idea (or at least in "good taste" :-)
Interfaces should be lean.
Similarly the /proc fs is quite strange. Why does it have any
non process subdirectory?
$ echo /proc/[0-9]* | wc -w # count of processes
142
$ echo /proc/[^0-9]* | wc -w # count of non-process directories
58
Compare:
Linux (raspberryPi + X windows):
$ echo /proc/[0-9]* |wc -w # how many processes
142
$ find /proc/[0-9]* | wc -l # how many proc related files+dirs
66153
FreeBSD (10.3 amd64+zfs+4 lightweight jails):
$ echo /proc/[0-9]* | wc -w # how many processes
123
$ find /proc/[0-9]* | wc -l # how many proc related files+dirs
1075
Plan9 (mostly quiescent):
$ echo /proc/[0-9]* | wc -w
64
$ du -a /proc/[0-9]* | wc -l
1235
Anyone feeling sad about /proc in FreeBSD should consider
the alternative!
2400
days inactive
2400
days old
3 comments
3 participants
participants (3)
-
Bakul Shah -
Kevin Bowling -
Norman Wilson