/proc filesystem enhancements
zeroboy
I was thinking about some of the tuneable parameters within the
OpenSolaris kernel, and thought that these should be accessible
directly through the /proc filesystem, a la Linux. Is this something
that would be useful to do?
fintanr
Hi,
What kind of tunables are you thinking about?
They are all accessible via various mechansim already,
ie rctladm, mdb, ndd etc.
Procfs in Solaris is very different from Linux, take a look
at the procfs community [1] on opensolaris, and Eric Schrocks
blogposting on the subject [2] for a bunch more details
- Fintan
[1] http://www.opensolaris.org/os/community/observability/process/procfs/
[2] http://blogs.sun.com/roller/page/eschrock/20040625#the_power_of_proc
On Tue, Jul 12, 2005 at 12:20:36AM -0700, Random wrote:
< I was thinking about some of the tuneable parameters within the
OpenSolaris kernel, and thought that these should be accessible
directly through the /proc filesystem, a la Linux. Is this something
that would be useful to do?
< This message posted from opensolaris.org
< _______________________________________________
< opensolaris-code mailing list
< opensolaris-code at opensolaris dot org
< https://opensolaris.org:444/mailman/listinfo/opensolaris-code
--
fintanr at sun dot com http://blogs.sun.com/fintanr
@dub03 http://wwws.sun.com/software/solaris/10
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
frankho
> > I was thinking about some of the tuneable parameters within the OpenSolaris
kernel, and thought that these should be accessible directly through the /proc
filesystem, a la Linux. Is this something that would be useful to do?
>
> It is wrong to put these parameters into /proc anyway because they don't
> beling there even in a read-only way.
>
> - Solaris supports tuneables in /etc/system since ~ 1992.
>
> - Many of the Linux tuneables don't need to be tuned on Solaris.
All true.
In addition, Solaris /proc has always been "pure" - it's for process
control. NOT for driver control/statistics.
Linux procfs is severely overloaded with functionality that just has
nothing to do with a "process control" interface. All the things that
Solaris has as kernel statistics, /system (objfs), sysconf()/sysinfo(),
and /etc/system, have all been packed into that big lump of things on
Linux that's dubbed "procfs" there.
While having such an egg-laying, milk-giving woolly pig surely makes
it easy where to look for things ("everything's in /proc"), it's by
no means clean design.
As far as runtime-tuning kernel interfaces goes, wouldn't such things
better be put into objfs(7fs) ? I.e. extend the interfaces in /system/
to allow (controlled) modification of per-driver tunables ?
In any case, there's little point in creating just the interface. You
also need admin tools then, because the Solaris ways of how to make
tuning permanent have always been a) /etc/system b) driver.conf. If you
allow for runtime tuning then whatever the way for this will be it'll
also need to update either /etc/system or a driver.conf file, depending
on the choice of the user whether this kind of tuning is supposed to
"survive" reboot or not. And of course you need to allow the affected
driver to "deny" tuning.
To sum this up:
a) /procfs is purely for process control and shall better stay that way
b) Traditional Solaris tuning is done by /etc/system or driver.conf files
and needs to stay that way - don't negatively surprise people unless
you've got a very good reason to do so.
c) Runtime tuning is (kind of) an undefined thing in Solaris. If the driver
is written to accept this (i.e. queries the value of a tunable at every
affected action instead of just at driver load time), then it has always
been possible to modify such a "tunable" using the kernel debugger, aka
echo "my_tunable/Z 0xb1eed2dead" | mdb -kw
works "fine" in such cases.
d) An improvement to this needs extensions to the driver interfaces, i.e.
drivers would need to export "validation" functions that the framework
could then call to check existance of the tunable and perform validation
on the requested value, or credential checks whether the user who attempts
to modify a specific knob is actually allowed to do so.
Since /system already provides access to running driver code and does
at least the credentials checks (it's used for allowing non-root users
DTrace fbt access), that would, in my opinion, be the place where such
extensions would go to - NOT /proc.
FrankH.
_______________________________________________
opensolaris-code mailing list
opensolaris-code at opensolaris dot org
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
| 网站地图 |