Subject: Re: sysctl(2) and/or /kern for system variable manipulation
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 03/25/2000 13:55:57
> Indeed the concept of having so many namespaces in BSD is highly
> questionable. libkvm, sysctl, et al should all be moved to the
> filesystem namespace.
"Should"? Why? What's wrong with having many namespaces? Separate
namespaces have many good properties - for example, a chrooted program
can still manipulate AF_INET sockets normally. (This can be looked
upon as good or bad, depending on your inclination.)
> As for whether or not this means duplicating the effort with
> maintaining post-crash core dump analysis tools depends on how
> flexible those who use such tools are willing to be. If it is
> necessary to always guarantee that
> 'ps -M /var/crash/*.0.core -N /var/crash/*.0' will continue to work
> instead of having some new tool akin to the sysV "crash" program
> (whether implemented as a separate tool or as a set of GDB macros),
> well then yes, I guess it does mean duplicating some of the
> maintenance headaches and bloating some programs.
Personally, the main reason I want ps -M ... -N ... instead of a
separate crash-type program is that I can be sure it's the same ps,
supporting all the same options in exactly the same way, with all the
same output formats, etc, etc.
It occurs to me that it might well be sufficient to have a tool that
presents a kernfs-style mountable interface, but instead of being
driven off a live kernel it's driven off netbsd.0.core and netbsd.0
files. It seems this might end up being more work than the other way,
but it seems to me it should be at least considered.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B