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 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 ...
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 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. *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]. [2] PLEASE could someone do this or give me some hints? I don't have the time to do it atm. 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 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
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 ...
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
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