Re: user-space resource information...
"Kenneth D. Merry" wrote: > ... > > That's vmstat's problem, not a feature. :-) ... > > If it's not vm-related, it shouldn't be listed by vmstat. > > Interrupts aren't vm-related either, yet vmstat displays them. And it shouldn't do so. See my first comment. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
On Sun, Nov 05, 2000 at 17:32:16 +0900, Daniel C. Sobral wrote: > "Kenneth D. Merry" wrote: > > > > I think vmstat(8) might be a better fit than iostat. vmstat already > > displays kernel memory usage (-m), interrupt usage (-i), paging stats (-s), > > and zone allocator stats (-z). > > That's vmstat's problem, not a feature. :-) > > That kind of thinking is what led to Linux /proc. > > > Since vmstat already has "kitchen sink" type functionality (i.e. a wide > > variety of uses), I think it would probably work better to put this new > > functionality there. > > If it's not vm-related, it shouldn't be listed by vmstat. Interrupts aren't vm-related either, yet vmstat displays them. > > iostat is also designed primarily for continuous output use -- displaying a > > line of stats every N seconds. vmstat is also designed for that in its > > That's the objection I raised to Mike. :-) I suggested systat, though > that has it's problems too. Well, perhaps this stuff should go in its own utility, since it doesn't really seem to fit anywhere else. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
"Kenneth D. Merry" wrote: > > I think vmstat(8) might be a better fit than iostat. vmstat already > displays kernel memory usage (-m), interrupt usage (-i), paging stats (-s), > and zone allocator stats (-z). That's vmstat's problem, not a feature. :-) That kind of thinking is what led to Linux /proc. > Since vmstat already has "kitchen sink" type functionality (i.e. a wide > variety of uses), I think it would probably work better to put this new > functionality there. If it's not vm-related, it shouldn't be listed by vmstat. > iostat is also designed primarily for continuous output use -- displaying a > line of stats every N seconds. vmstat is also designed for that in its That's the objection I raised to Mike. :-) I suggested systat, though that has it's problems too. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] He has been convicted of criminal possession of a clue with intent to distribute. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
On Sat, Nov 04, 2000 at 11:52:35 -0800, Mike Smith wrote: > > I'm wondering if this should have its own program, rather than squat > > in on iostat ? > > Adding yet another program for such a trivial fragment of code seems > kinda silly. If/when someone uses the other interfaces as well to get > the full device tree extracted, that probably belongs elsewhere, but > right now iostat is as good a place as any for this I think. I think vmstat(8) might be a better fit than iostat. vmstat already displays kernel memory usage (-m), interrupt usage (-i), paging stats (-s), and zone allocator stats (-z). iostat only displays cpu, tty and disk I/O. Since vmstat already has "kitchen sink" type functionality (i.e. a wide variety of uses), I think it would probably work better to put this new functionality there. iostat is also designed primarily for continuous output use -- displaying a line of stats every N seconds. vmstat is also designed for that in its default output mode, but most of the other displays I mentioned above are one-shot displays, like the rman code. So one more wouldn't hurt. The only thing that would recommend iostat for the rman code is the name, I think. (I/O ports, iostat, etc.) So, I'd like to request that you use vmstat instead of iostat. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
In message <[EMAIL PROTECTED]> Mike Smith writes: : Well, I'm really sick of people complaining about not being able to get : at the things the resource manager knows from userspace. So I've done : something about it. Cool. I've wanted this for some time now. : 0: Interrupt request lines 0x0-0xf Nuke the leading numbers. No clue what they mean anyway. How are shared interrupts reported? I have several machines that share lots of interrupts. I'd also print decimal for small valued things, like those with a range <= 32. : 2: I/O ports 0x0-0x :0: atdma00x0-0xf :2: atpic00x20-0x21 This explains why the pccard code was, for a time, trying to assign 0x10-0x1f for a device I plugged in... :-) :0: sysresource0 0x0-0x9 :1: vga0 0xa-0xb active shareable :3: sysresource0 0xcd000-0xc :5: sysresource0 0xe8000-0xe :6: sysresource0 0xf-0xf3fff :7: sysresource0 0xf4000-0xf7fff :8: sysresource0 0xf8000-0xf :9: sysresource0 0x10-0x7ff : 11: fxp0 0xe300-0xe3000fff active : 13: sysresource0 0xfffe-0x This looks a little ugly as well, but I don't have a better format. I'll dink with things and see if there's any way I can improve the output. How hard would that device tree be now? Or is there extra hair that's needed for that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
> In message <[EMAIL PROTECTED]>, Mike Smith writes: > >> > Comments? Here's some sample output; the leading index numbers are > >> > >> Just 2: why are the irqs displayed in hex? > > > >See the following comment regarding "formatting conventions". There's no > >easy way for the program to know that they're IRQs (and IMO it shouldn't), > >so no way to know that they are conventionally formatted in ascii. Not > >sure what to do in the SMP case either, where the "IRQ" is really just a > >vector handle. > > If the largest number in the class is < 100, print decimal, otherwise > hex. Mmm. That's not a bad ballpark heuristic, although I'm still leaning towards presenting it with the rman. > I'm wondering if this should have its own program, rather than squat > in on iostat ? Adding yet another program for such a trivial fragment of code seems kinda silly. If/when someone uses the other interfaces as well to get the full device tree extracted, that probably belongs elsewhere, but right now iostat is as good a place as any for this I think. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> > Comments? Here's some sample output; the leading index numbers are >> >> Just 2: why are the irqs displayed in hex? > >See the following comment regarding "formatting conventions". There's no >easy way for the program to know that they're IRQs (and IMO it shouldn't), >so no way to know that they are conventionally formatted in ascii. Not >sure what to do in the SMP case either, where the "IRQ" is really just a >vector handle. If the largest number in the class is < 100, print decimal, otherwise hex. I'm wondering if this should have its own program, rather than squat in on iostat ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
> > Comments? Here's some sample output; the leading index numbers are > > Just 2: why are the irqs displayed in hex? See the following comment regarding "formatting conventions". There's no easy way for the program to know that they're IRQs (and IMO it shouldn't), so no way to know that they are conventionally formatted in ascii. Not sure what to do in the SMP case either, where the "IRQ" is really just a vector handle. > And: will it work on alphas? ;-) Yes. Go ahead and try it. 8) > > possibly misleading and I was considering removing them. I haven't > > I'd remove it if I were you. Ok, consider them history. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: user-space resource information...
On Sat, Nov 04, 2000 at 03:43:28AM -0800, Mike Smith wrote: > > Well, I'm really sick of people complaining about not being able to get > at the things the resource manager knows from userspace. So I've done > something about it. > > Please review: > > http://ziplok.dyndns.org/msmith/rman.diff > http://ziplok.dyndns.org/msmith/iostat.diff > > which adds the new '-r' flag to iostat which will print the current > resource manager ownership database. I have similar interfaces underway > to access the devclass and device trees, so that an enterprising > user-space hacker could trivially construct a complete map of the system > bus and resource structure using any of several different organisations. > > I may write a small user-space library to sit on top of these interfaces > to make life easier. sysctl is not the cleanest of interfaces for this > application, but it does the job. > > Comments? Here's some sample output; the leading index numbers are Just 2: why are the irqs displayed in hex? And: will it work on alphas? ;-) I really like it, don't misinterpret me please! > possibly misleading and I was considering removing them. I haven't I'd remove it if I were you. > decided yet what to do about formatting conventions; they may end up > going into the rman initialisation. > > 0: Interrupt request lines 0x0-0xf >0: attimer0 0x0 >1: atkbd00x1 active shareable >2: atpic00x2 >3: sio1 0x3 active >4: sio0 0x4 active >6: ppc0 0x7 active shareable >7: attimer1 0x8 >9: uhci0 0xa active shareable > 11: nomatch 0xc > 12: npxisa0 0xd > 13: ata0 0xe active > 14: ata1 0xf active > 1: DMA request lines 0x0-0x7 >1: ppc0 0x3 active >2: atdma00x4 > 2: I/O ports 0x0-0x >0: atdma00x0-0xf >2: atpic00x20-0x21 >4: attimer0 0x40-0x43 >6: atkbdc0 0x60 active >7: nomatch 0x61 >9: atkbdc0 0x64 active > 11: attimer1 0x70-0x71 > 13: atdma00x80-0x90 > 15: atdma00x94-0x9f > 16: atpic00xa0-0xa1 > 18: atdma00xc0-0xde > 20: npxisa0 0xf0 > 22: ata1 0x170-0x177 active > 24: ata0 0x1f0-0x1f7 active > 26: sysresource1 0x290-0x297 > 28: sio1 0x2f8-0x2ff active > 3: I/O memory addresses 0x0-0x >0: sysresource0 0x0-0x9 >1: vga0 0xa-0xb active shareable >3: sysresource0 0xcd000-0xc >5: sysresource0 0xe8000-0xe >6: sysresource0 0xf-0xf3fff >7: sysresource0 0xf4000-0xf7fff >8: sysresource0 0xf8000-0xf >9: sysresource0 0x10-0x7ff > 11: fxp0 0xe300-0xe3000fff active > 13: sysresource0 0xfffe-0x -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
user-space resource information...
Well, I'm really sick of people complaining about not being able to get at the things the resource manager knows from userspace. So I've done something about it. Please review: http://ziplok.dyndns.org/msmith/rman.diff http://ziplok.dyndns.org/msmith/iostat.diff which adds the new '-r' flag to iostat which will print the current resource manager ownership database. I have similar interfaces underway to access the devclass and device trees, so that an enterprising user-space hacker could trivially construct a complete map of the system bus and resource structure using any of several different organisations. I may write a small user-space library to sit on top of these interfaces to make life easier. sysctl is not the cleanest of interfaces for this application, but it does the job. Comments? Here's some sample output; the leading index numbers are possibly misleading and I was considering removing them. I haven't decided yet what to do about formatting conventions; they may end up going into the rman initialisation. 0: Interrupt request lines 0x0-0xf 0: attimer0 0x0 1: atkbd00x1 active shareable 2: atpic00x2 3: sio1 0x3 active 4: sio0 0x4 active 6: ppc0 0x7 active shareable 7: attimer1 0x8 9: uhci0 0xa active shareable 11: nomatch 0xc 12: npxisa0 0xd 13: ata0 0xe active 14: ata1 0xf active 1: DMA request lines 0x0-0x7 1: ppc0 0x3 active 2: atdma00x4 2: I/O ports 0x0-0x 0: atdma00x0-0xf 2: atpic00x20-0x21 4: attimer0 0x40-0x43 6: atkbdc0 0x60 active 7: nomatch 0x61 9: atkbdc0 0x64 active 11: attimer1 0x70-0x71 13: atdma00x80-0x90 15: atdma00x94-0x9f 16: atpic00xa0-0xa1 18: atdma00xc0-0xde 20: npxisa0 0xf0 22: ata1 0x170-0x177 active 24: ata0 0x1f0-0x1f7 active 26: sysresource1 0x290-0x297 28: sio1 0x2f8-0x2ff active 3: I/O memory addresses 0x0-0x 0: sysresource0 0x0-0x9 1: vga0 0xa-0xb active shareable 3: sysresource0 0xcd000-0xc 5: sysresource0 0xe8000-0xe 6: sysresource0 0xf-0xf3fff 7: sysresource0 0xf4000-0xf7fff 8: sysresource0 0xf8000-0xf 9: sysresource0 0x10-0x7ff 11: fxp0 0xe300-0xe3000fff active 13: sysresource0 0xfffe-0x -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
