Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Jake Burkholder schrieb: [...] As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. You may have forgotten to also change KINFO_PROC_SIZE in src/sys/user.h I'm now getting bootup warning all the time: ... real memory = 197066752 (192448K bytes) avail memory = 187293696 (182904K bytes) Preloaded elf kernel "kernel" at 0xc045. WARNING: size of kinfo_proc (648) should be 644!!! Pentium Pro MTRR support enabled ... BTW What is the purpose of KINFO_PROC_SIZE? Why not simply using sizeof()? -- Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On Mon, Feb 12, 2001, Robert Watson wrote: On 12 Feb 2001, Dag-Erling Smorgrav wrote: Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... It seems to me that kinfo_proc is the wrong solution to a real problem. John Baldwin and I briefly discussed, online, an alternative solution that breaks out the per-process information into a series of sysctl's. This costs you more in terms of number of calls to retrieve the information, as well as introducing non-atomicity that might need to be addressed, but allows you to maintain compatibility in many more situations. It removes struct ordering constraints, allows you to happily handle the addition of new fields, and when a field is removed or changes size, you know which field it is, and your ability to look at other fields is not impacted. Another global sysctl could maintain a list of relevant fields, so you could even imagine a process browser that was extensible (especially when using base types for the fields, such as int). kinfo_proc addresses the issue that the kernel and userland concepts of a proc diverge due to the introduction of kernel-only fields, but doesn't really address issues such as ordered elements of the structure changing size. .. and extending my last email, here's how I see it: sysctl is designed for numerical or binary data return procfs (or any synthetic fs) is designed for text based data return The trouble here that I see is that people are inventing overly-complex methods of representing the data when they could just export it in text format. Yes, I know all about the problems there are with linux's procps/proctop. But in my opinion, I'm quite happy to fix the problems in procfs and attack the speed issues people keep seeing rather than invent an increasingly complex method of exporting data which isn't "right" yet. I am also one of those people who see evilnesses in going take raw data - generate text - parse text - get raw data, but is this really an interface we need blindingly fast? (My 2c, I might run off and commit a proof of concept "stat" file to procfs this week..) Adrian -- Adrian Chadd"Programming is like sex: [EMAIL PROTECTED] One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On Wed, 14 Feb 2001, Adrian Chadd wrote:
*sigh* now, if we had per-file open vnode[1] support, I could quite
happily solve this by fixing procfs, but people view procfs as bad for
some reason.
[1] Ignore my vagueness in terms here - the general request is to have
some form of state mapped back to an open file from the VNOPS. This
way at VOP_OPEN() I can populate the file data with some proc info,
and then VOP_READ/VOP_WRITE just read from this, rather than the
evilness (and non-atomic) way they work right now[2].
I had patches that did a lot of this at one point, although I'd object to
proc info, what you really want is struct file info (that is,
per-open-file information). The way I handled it was to add an additional
argument to the relevant VOP_ calls that was a cookie reference. So it
became something on the order of (approximate):
vop_open {
IN struct vnode *vp;
IN int mode;
IN struct ucred *cred;
IN struct proc *p;
INOUT void **cookie;
};
...
vop_read {
IN struct vnode *vp;
INOUT struct uio *uio;
IN int ioflag;
IN struct ucred *cred;
IN void *cookie;
};
...
And so on. If VOP_OPEN() was called with a non-null (void *), the cookie
would be filled in by the vnode owner. Later operations could have the
cookie passed in again for stateful operation, or NULL for stateless.
struct file had a cookie pointer added to it so that struct file-based
access became stateful. When stacking file systems, state mapping could
optionally be performed to allow sessions to propagate up and down the
stacked layers as the layer implementers saw fit (either by passing
through the cookie directly, or storing a cookie pointer in their own
cookie).
If you have it be per-process state, that breaks (a) multiple-opening
where you want to get different sessions and (b) retaining the same
session when using multiple processes (especially when using linux-style
threading). I didn't play with propagating this down through the device
layer, but if you wanted to do that you'd have to clean up the apropriate
mechanisms to make sure that all open's were symmetric with closes on
vnodes and on devices through the vnode layer.
There are probably problems with this design -- I played with it some, but
it lagged behind -CURRENT substantially after a while, and I don't think I
have that dev tree anymore. This design does allow the file system to
define statefulness in any form it would like to, storing whatever
information the file sytem implementation thinks is useful. It could
easily be a pointer to a struct of some sort, an integer, a pid, ..
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On 12 Feb 2001, Dag-Erling Smorgrav wrote: Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... It seems to me that kinfo_proc is the wrong solution to a real problem. John Baldwin and I briefly discussed, online, an alternative solution that breaks out the per-process information into a series of sysctl's. This costs you more in terms of number of calls to retrieve the information, as well as introducing non-atomicity that might need to be addressed, but allows you to maintain compatibility in many more situations. It removes struct ordering constraints, allows you to happily handle the addition of new fields, and when a field is removed or changes size, you know which field it is, and your ability to look at other fields is not impacted. Another global sysctl could maintain a list of relevant fields, so you could even imagine a process browser that was extensible (especially when using base types for the fields, such as int). kinfo_proc addresses the issue that the kernel and userland concepts of a proc diverge due to the introduction of kernel-only fields, but doesn't really address issues such as ordered elements of the structure changing size. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
On Mon, 12 Feb 2001, Robert Watson wrote: On 12 Feb 2001, Dag-Erling Smorgrav wrote: Jake Burkholder [EMAIL PROTECTED] writes: As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. I thought the whole point with kinfo_proc was to avoid this kind of situation... It seems to me that kinfo_proc is the wrong solution to a real problem. John Baldwin and I briefly discussed, online, an alternative solution that breaks out the per-process information into a series of sysctl's. This But sysctls are the wrong solution for all problems :-). using base types for the fields, such as int). kinfo_proc addresses the issue that the kernel and userland concepts of a proc diverge due to the introduction of kernel-only fields, but doesn't really address issues such as ordered elements of the structure changing size. These issues shouldn't cause problems. You just preserve the order and don't use any kernel structs. Using application interface structs like struct rusage and struct rtprio is safe enough since if they change then you have worse problems with the binary compaitibility of the syscalls that use them. The errors in the recent commit were: (1) using the kernel struct `struct priority' (2) not preserving the old priority fields. Point (1) wouldn't have caused breakage immediately if the priority fields had been copied to their old places. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/dev/acpica/Osd OsdSchedule.c src/sys/i386/i386 genassym.c swtch.s trap.c src/sys/ia64/ia64 trap.c src/sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c ...
jake2001/02/11 16:20:08 PST Modified files: sys/alpha/alpha trap.c sys/dev/acpica/Osd OsdSchedule.c sys/i386/i386genassym.c swtch.s trap.c sys/ia64/ia64trap.c sys/kern init_main.c kern_condvar.c kern_idle.c kern_intr.c kern_mib.c kern_mutex.c kern_proc.c kern_resource.c kern_sig.c kern_subr.c kern_switch.c kern_synch.c sys/posix4 ksched.c sys/sys ktr.h param.h proc.h rtprio.h systm.h tty.h user.h sys/ufs/ffs ffs_snapshot.c sys/vm vm_glue.c vm_meter.c Added files: sys/sys priority.h runq.h Log: Implement a unified run queue and adjust priority levels accordingly. ... As I mentioned in the commit message, this changes the size and layout of struct kinfo_proc, so you'll have to recompile libkvm-using programs. As always, make world is your friend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
