Re: CFT: Graphics support for /boot/loader
Skip Ford wrote: Oliver Fromme wrote: Julian Elischer wrote: BTW most of these things seem to have ESC drop out of graphics mode.. do you have something like that? (or maybe ESC should go to loader prompt...?) Good question. The screen layout isn't final, of course, and I'm open to suggestions. (Also, there will be a short descriptive text for the countdown and how to pause it.) I think it might make sense to provide an additional action using the Esc key that leaves graphics mode and displays the old text menu instead. What about F8? That's what I'd guess a majority of people would instinctively reach for to get to a boot menu. Ok, scratch that idea. Windows uses F8 to stop an automatic boot, not really to drop to a text menu from a graphics menu. We can press any key to stop an automatic boot already, so F8 could be used to halt an automatic boot and jump straight to a boot menu, but that has nothing to do with this graphical boot menu. It could even jump to the graphical boot menu, not necessarily text. Windows just happens to not have a graphical menu. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: CFT: Graphics support for /boot/loader
Oliver Fromme wrote: Julian Elischer wrote: BTW most of these things seem to have ESC drop out of graphics mode.. do you have something like that? (or maybe ESC should go to loader prompt...?) Good question. The screen layout isn't final, of course, and I'm open to suggestions. (Also, there will be a short descriptive text for the countdown and how to pause it.) I think it might make sense to provide an additional action using the Esc key that leaves graphics mode and displays the old text menu instead. What about F8? That's what I'd guess a majority of people would instinctively reach for to get to a boot menu. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs tag renaming after repo copy
Simon L. Nielsen wrote: For other intersted parties I got OK from John Polstra to put his script online with std. BSD license so it can now be found at http://people.freebsd.org/~simon/scripts/Fixtags . In case anyone is interested I put the script I use for repo-copies at FreeBSD.org online as http://people.freebsd.org/~simon/scripts/cvs_repo_copy . The script probably need to be adjusted to local config and use at your own risk etc - but it hasn't done anything bad for me yet :-). Thanks for these. Any reason they couldn't be added to the repository in src/tools/tools/repocopy/ or similar so those who are interested don't have to worry about having a stale version in the future? -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated procstat(1)
Robert Watson wrote: On Wed, 28 Nov 2007, Skip Ford wrote: - -a now means all processes, Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a per-process tool. I was, but then I read your e-mail and became convinced that the first patch that would be submitted against procstat(1) would be a -a patch. :-) Yep, would've happened. Now the first patch submitted will be a -w interval patch... :-) - A new -k has been added, which prints the kernel thread stacks for threads in a process (although not swapped out or actively running threads). This is extremely useful for answering questions of the sort But *why* is the process blocked in UMA. It has both a simple mode (-k_, which lists just kernel function names, and a slightly more detailed mode (-kk), which adds the offset into the function. This is excellent. Does this absolutely have to depend on DDB and KDB? Currently, yes, as stack(9) is conditional on DDB, and the MD bits of stack(9) are defined in db_trace.c (and in some cases, depend on DDB definitions, such as DDB types, although I think not critically so). I've also been pondering breaking out stack(9) from DDB but haven't done that yet. Maybe that will be today's task, as I'd like -k to work without the kernel debugger, as it has use significantly beyond kernel debugging. That'd be great if it worked without DDB. It just feels like it should. This tool is a very nice addition. Thanks for writing it and for asking for feedback, then putting up with the responses. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated procstat(1)
Skip Ford wrote:
Robert Watson wrote:
On Wed, 28 Nov 2007, Skip Ford wrote:
- -a now means all processes,
Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a
per-process tool.
I was, but then I read your e-mail and became convinced that the first
patch that would be submitted against procstat(1) would be a -a patch. :-)
Yep, would've happened. Now the first patch submitted will be a
-w interval patch... :-)
I couldn't resist implementing a crude interval arg just for kicks.
Here's the output of find(1) every second. This is so cool:
$ procstat -k -w 1 948
PIDTID COMM KSTACK
948 100099 find mi_switch thread_suspend_check userret
syscall Xint0x80_syscall
948 100099 find mi_switch sleepq_switch sleepq_wait _sleep
bwait bufwait breadn bread ffs_read VOP_READ_APV ufs_readdir VOP_READDIR_APV
getdirentries syscall Xint0x80_syscall
948 100099 find mi_switch turnstile_wait _mtx_lock_sleep
fdalloc falloc kern_open open syscall Xint0x80_syscall
948 100099 find mi_switch sleepq_switch sleepq_wait _sleep
bwait bufwait breadn bread ffs_read VOP_READ_APV ufs_readdir VOP_READDIR_APV
getdirentries syscall Xint0x80_syscall
948 100099 find mi_switch critical_exit intr_execute_handlers
atpic_handle_intr Xatpic_intr0
948 100099 find mi_switch ast doreti_ast
948 100099 find mi_switch sleepq_switch sleepq_wait _sleep
bwait bufwait breadn bread ffs_read VOP_READ_APV ufs_readdir VOP_READDIR_APV
getdirentries syscall Xint0x80_syscall
948 100099 find mi_switch turnstile_wait _mtx_lock_sleep
fdalloc falloc kern_open open syscall Xint0x80_syscall
948 100099 find mi_switch critical_exit intr_execute_handlers
atpic_handle_intr Xatpic_intr0 priv_check vn_stat vn_statfile kern_fstat fstat
syscall Xint0x80_syscall
948 100099 find mi_switch sleepq_switch sleepq_wait _sleep
bwait bufwait breadn bread ffs_vget ufs_lookup VOP_CACHEDLOOKUP_APV
vfs_cache_lookup VOP_LOOKUP_APV lookup namei kern_lstat lstat syscall
948 100099 find mi_switch sleepq_switch sleepq_wait _sleep
bwait bufwait breadn bread ffs_read VOP_READ_APV ufs_readdir VOP_READDIR_APV
getdirentries syscall Xint0x80_syscall
For someone who isn't intimately familiar with the kernel, this is really
a nice feature for this tool.
I'm attaching the very crude interval patch just because it seems rude
not to, but you probably either don't want it or will do it differently
and either is perfectly fine. If you do implement it on your own, don't
bother printing a header per screenful since it would be most useful for
kstacks and that output usually spills over to multiple lines anyway.
--
Skip
diff -u src~/usr.bin/procstat/procstat.c src/usr.bin/procstat/procstat.c
--- src~/usr.bin/procstat/procstat.c 2007-11-27 10:23:39.0 -0500
+++ src/usr.bin/procstat/procstat.c 2007-11-28 07:01:23.0 -0500
@@ -106,13 +106,14 @@
main(int argc, char *argv[])
{
struct kinfo_proc *kipp;
- int ch, i, name[4], tmp;
+ int ch, i, name[4], tmp, interval;
size_t len;
long l;
pid_t pid;
char *dummy;
- while ((ch = getopt(argc, argv, abcfkhstv)) != -1) {
+ interval = 0;
+ while ((ch = getopt(argc, argv, abcfkhstvw:)) != -1) {
switch (ch) {
case 'a':
aflag = 1;
@@ -150,6 +151,10 @@
vflag = 1;
break;
+ case 'w':
+ interval = atoi(optarg);
+ break;
+
case '?':
default:
usage();
@@ -166,6 +171,7 @@
/* Must specify at least one of -a and a list of pids. */
if (!aflag argc 1)
usage();
+loop:
if (aflag) {
name[0] = CTL_KERN;
name[1] = KERN_PROC;
@@ -233,5 +239,11 @@
/* Suppress header after first process. */
hflag = 1;
}
+
+ if (interval) {
+ sleep(interval);
+ goto loop;
+ }
+
exit(0);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated procstat(1)
Robert Watson wrote: I've updated the procstat(1) kernel patch and userland tool; the updated version can be found at: http://www.watson.org/~robert/freebsd/20071127-procstat.tgz The new version includes a number of changes from the old version, including: - -a now means all processes, Thanks. :-) I'm a little surprised. You seemed pretty dedicated to a per-process tool. I personally would change it to allow either the all flag or a list of pids, rather than at least one of. For pathname, command-line, and credential information, the output will likely not change between showing the pid in the all output and the list output so you're just outputting it twice. If one really wants the same pid to be output multiple times for threads, kstack, or file descriptors, then I'd expect procstat -k 0 0 0 0 0 to be more useful for that. I would think a mistake in usage has been made if a list of pids is specified along with the all flag. But, no real harm is done by doing it the current way. - Threads and processes are now sorted by pid and then tid. If processes are specified manually by pid, they are not sorted, although their threads will be. Nice. - A new -k has been added, which prints the kernel thread stacks for threads in a process (although not swapped out or actively running threads). This is extremely useful for answering questions of the sort But *why* is the process blocked in UMA. It has both a simple mode (-k_, which lists just kernel function names, and a slightly more detailed mode (-kk), which adds the offset into the function. This is excellent. Does this absolutely have to depend on DDB and KDB? The last of these required new kernel changes, including an MD component. I've tested the MD parts only on i386, although I have quick hacks at what they should look like on amd64, arm, powerpc, sparc64, sun4v. I don't promise these compile or work, but they might do. In sys/amd64/amd64/db_trace.c on line 537, change SWWAPPED to SWAPPED. The newly introducted function stack_save_td() doesn't panic in the MD powerpc code like it does for other arches. I have no idea if this is correct, it just doesn't match the others. Unfortunately, I can only test i386. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: The main missing feature right now, from my perspective, is signal information, but are there other pieces of detailed process information we could usefully be displaying? I'm not sure I want to get into teaching procinfo about generating stack traces, which is something the Solaris tools can do, but perhaps there are other things we could be displaying. The functionality I'd use most if implemented would be process trees. But, I wouldn't really call it a missing feature since we already have parent pids in ps(1). I'm not so sure generating a tree is something your tool should do either. A lot of OSes seem to have such a tool, but I don't know if they provide more information than we could put together just using ps(1) and your tool once committed. Think I'll play around with creating a kern.proc.tree, just to see if I can, so a tool could dump it with a few lines, but I think it doesn't belong. Although it occurs to me that, in many ways, it would be nice to be able to generate a kernel stack trace for each user thread--often when debugging a hung process, that's one of the pieces of information I'd really like to have, as just seeing a generic wchan sleep on a lock is not very useful. That would be invaluable, and isn't functionality we can gain currently by scripting other tools. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Thomas Hurst wrote: * Skip Ford ([EMAIL PROTECTED]) wrote: It would be interesting to know for sure, though, if Solaris uses hardlinks and, if so, what their utility is called. Nope. They *do* use hardlinks in that they have 32bit wrappers in /usr/bin etc which dispatch to the relevent architecture, but the commands themselves are all seperate. Indeed, and each utility is quite complex as compared to what ours would be if split. I would just rename procstat(1) to pargs(1) then hardlink the others since ours are much less complex, but I'll take anything at this point. As for the procstat(1) code itself, I've found one bug and have two sugestions: 1) procstat_args() doesn't use a local variable and the buffer doesn't get cleared between calls: $ procstat -a 797 PID ARGS 797 audacious $ procstat -a 795 797 PID ARGS 795 xterm -xtsessionID 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ Other option's functions are not similarly affected. 2) I think it should handle requests for information about pid 0 instead of requiring at least pid 1 as it currently does. Solaris suggests '/proc/*' to see all processes. If we use `ps axopid=` then it aborts on the swapper (pid 0) immediately. 3) Similarly, I think all of the sysctl(3) calls within the individual option functions (procstat_bin(), procstat_args(), etc.) should just go ahead and print the header and pid, then print any sysctl(3) error in the PID's row instead of erroring out. We're either about to finish executing anyway if that was the only pid requested, or we're moving on to another pid that has nothing to do with the previous pid. There's not really any reason to stop processing further pids. This also affects attempting to list all pids since it currently stops processing pids as soon as one doesn't exist. A global error variable could just be incremented with every call and returned at process exit, that way it'd still be meaningful for single PIDs. Since this is a per-process tool, I think it needs to complete procstat -c `ps axopid=` if at all possible. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Sun, 18 Nov 2007, Skip Ford wrote: As for the procstat(1) code itself, I've found one bug and have two sugestions: 1) procstat_args() doesn't use a local variable and the buffer doesn't get cleared between calls: $ procstat -a 797 PID ARGS 797 audacious $ procstat -a 795 797 PID ARGS 795 xterm -xtsessionID 11c0a801030001185368263000768 797 audacious essionID 11c0a801030001185368263000768 $ Other option's functions are not similarly affected. 2) I think it should handle requests for information about pid 0 instead of requiring at least pid 1 as it currently does. Solaris suggests '/proc/*' to see all processes. If we use `ps axopid=` then it aborts on the swapper (pid 0) immediately. 3) Similarly, I think all of the sysctl(3) calls within the individual option functions (procstat_bin(), procstat_args(), etc.) should just go ahead and print the header and pid, then print any sysctl(3) error in the PID's row instead of erroring out. We're either about to finish executing anyway if that was the only pid requested, or we're moving on to another pid that has nothing to do with the previous pid. There's not really any reason to stop processing further pids. This also affects attempting to list all pids since it currently stops processing pids as soon as one doesn't exist. A global error variable could just be incremented with every call and returned at process exit, that way it'd still be meaningful for single PIDs. Actually, I think I've fixed all of the above in p4 with some changes yesterday; I'll do a new code drop for you to try: http://www.watson.org/~robert/freebsd/20071118-procstat.tgz Yes, I like it. We must be thinking alike, which is ultimately bad news for you, I'm afraid. The bug mentioned first above is still present, and the other bug I mentioned outside of this thread also is, AFAIK. Other than those, I like it. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Bjoern A. Zeeb wrote: On Fri, 16 Nov 2007, Skip Ford wrote: How about renaming procstat(1) to proc(1), rolling up all of calling it proc(1), I think, is actually not a good idea either. That is way more confusing for people who still think about /proc and do not know the difference between (1) or (4). I like the procstat as it aligns well with other things like fstat netstat sockstat systat vmstat gstat iostat pmcstat ... I admit we also have some *info tools like ffsinfo/diskinfo/rpcinfo/.. but ``pinfo'' seems to better fit the *stat category of tools;-) I am not able to find anything but a simple C wrapper for /proc/*/stat for linux on the web easily (which I suppose could as well be a sh skript) and cannot even find something like procstat on the linux machines I have access to. But there seems to be a procinfo that seems to as well extract information from /proc/ on linux. So having pinfo or procinfo might more confuse people to expect something differently and even worse might mean to be the same tool with compatible command line. While thinking we should try to aling with other OSes and not confuse users coming from non-BSD worlds, procstat to mee seems to be the thing that would best fit for our tree. I don't mind the name procstat(1), I just think we already have one that happens to be abbreviated ps(1) instead of being spelled out. If we end up with hardlinks for a proc tool family of utilities, users will be pointed to the actual tool they need rather than proc(1) so I don't think new user confusion would be that great. But, the same argument also really nullifies my argument for the name as well. If we have hardlinks, I care much less about the name of the base utility since it won't be used everyday. With hardlinks, pinfo(1), proc(1), and procstat(1) are all fine with me. The OP in this thread would then just use pfiles(1) to get a list of open files, same as Solaris, no matter what we call it. It would be interesting to know for sure, though, if Solaris uses hardlinks and, if so, what their utility is called. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? Either of those options works for me. If I were the first person ever to make the decision, I'd go with pinfo(1). However, Linux doesn't have separate utilities like Solaris but does have a procinfo(8) utility in addition to their ps(1). Their procinfo(8) displays system status as gathered from procfs. In other words, anything that's not process related that's available via procfs gets displayed with procinfo(8). So, needless to say, it isn't per-process like ours would be nor does it provide anywhere near the same type of information as pinfo(1) currently (or ever) would: http://www.linuxcommand.org/man_pages/procinfo8.html So, even though the Solaris way of separate utilities seems like overkill to me, that's what I'd vote for following. If that's what you decide should be done and you want a hand, I can do the work. Just let me know the names of the utilities and supply Solaris manpages if they have matching commands, and I can convert your code so you can be working on bigger and better things. But, again, even pinfo(1) would be better than procstat(1) to me so if that's what you decide, I don't have a problem with that. At least our two utilities wouldn't have essentially the same name. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). FWIW, it looks like on Solaris, there are a series of psig(1), pstack(1), ptree(1), etc, tools for similar sorts of per-process inspection purposes. I think I prefer bundling it into a single tool, but it's certainly a similar idea. Maybe I should just rename procstat(1) to pinfo(1) and be done with it? How about renaming procstat(1) to proc(1), rolling up all of the Solaris proc tools functionality into that (someday), then creating hardlinks for all of the individual utilities? I just found the Solaris manpage for their proc tools and I really like how they've done it. The first command listed on that page is proc but then it isn't listed in the synopsis and no man page is listed in the links. So, that plus their single proc tools manpage makes it look to me like that's what they actually do, use a single utility with hardlinks. I've never used Solaris or seen the source so I could be wrong, but that's how it looks from the manpage. That's a great solution, IMO. Plus, it would buy more time. It could go in immediately to all branches then be improved later without breaking anything. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Tue, 13 Nov 2007, Yuri wrote: Thank you for letting me know about this new feature procstat. But is there any workaround in 6.3? I need to port one package that needs to lookup file names by FDs to the current FreeBSD and need some solution now. If the port uses a script to extract the data, a tool like lsof may do the trick. However, I'm not sure there are any native APIs to query that data as shipped in 6.3. Once I've had some reasonable feedback on procstat(1), Well, the header file procstat.h is still missing from the tarball AFAICT so I don't know how many people are using it. Not sure what type of feedback you want, but I've been using it since you posted the link and it works as advertised. I like being able to see the vm map without using procfs. I don't like having a procstat(1) utility along with a ps(1) utility. procstat seems short for process status as does ps. Seems like procstat(1) should be a library with ps(1) the frontend, or ps(1) should be merged with procstat(1). Plus, the name procstat sounds an awful lot like a certain part of the body that makes me uncomfortable in my chair. Do you really want to spend the rest of your life asking people to see their procstat output? ;-) But, it works fine and provides access to information that's not readily available by other means. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get filename of an open file descriptor
Robert Watson wrote: On Wed, 14 Nov 2007, Skip Ford wrote: Robert Watson wrote: On Tue, 13 Nov 2007, Yuri wrote: Thank you for letting me know about this new feature procstat. But is there any workaround in 6.3? I need to port one package that needs to lookup file names by FDs to the current FreeBSD and need some solution now. If the port uses a script to extract the data, a tool like lsof may do the trick. However, I'm not sure there are any native APIs to query that data as shipped in 6.3. Once I've had some reasonable feedback on procstat(1), Well, the header file procstat.h is still missing from the tarball AFAICT so I don't know how many people are using it. Whoops! While you have obviously extracted or recreated the file, here's a URL for everyone else: http://www.watson.org/~robert/freebsd/20071115-procstat.tgz I recreated the file and am running it on RELENG_7. It applies with a few small offsets. I don't like having a procstat(1) utility along with a ps(1) utility. procstat seems short for process status as does ps. Seems like procstat(1) should be a library with ps(1) the frontend, or ps(1) should be merged with procstat(1). Plus, the name procstat sounds an awful lot like a certain part of the body that makes me uncomfortable in my chair. Do you really want to spend the rest of your life asking people to see their procstat output? ;-) You are more evil than previously understood. :-) Just try saying procstat with a straight face now... I agree regarding the duplication with ps(1) -- however, I'm generally of the opinion that ps(1) is overburdened as tools go, and that the goals are actually somehwat different--procstat(1) intentionally doesn't have the ability to generate a list of processes, for example, taking pids explicitly as the argument; likewise, historically ps(1) has not been interested in printing more than one line per process (although I think -h changed this). I'll do a bit more investigation as to how easily it can be wedged in, and do recognize the concern here. I understand, and I sort of knew that from the beginning which is why I didn't provide feedback immediately. I don't have a suggestion as to what I think should be done. While procstat(1) currently takes a list of pids, I wouldn't be surprised if somebody adds code to list all processes, unless you block it. I think it would be useful, especially since some of it's options produce single-line per pid output, such as credentials. The two utilities do provide different information, it's just a little odd to have two utilities with basically the same name. But I can't think of a more appropriate name for procstat(1). -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build /* only */ the required kernel modules
Pietro Cerutti wrote: Adding netgraph/bluetooth and firewire/fwe in the MODULES_OVERRIDE list won't build the parent netgraph and firewire modules, but adding netgraph and firewire will build lots of unneeded and unwanted modules. netgraph/netgraph and firewire/firewire. -- Skip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Finding MTU
Dennis George wrote:
Can anybody tell me how to find the MTU (Maximum Transmitting
Unit) in freeBSD programatically...
The full source for ifconfig(8) is available. No need to ask
anyone...
http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ifconfig/ifconfig.c?rev=1.106content-type=text/x-cvsweb-markup
However, here's a small program, probably taken from the sources
above at some point, that prints the MTU for ed0.
#include sys/ioctl.h
#include sys/types.h
#include sys/socket.h
#include net/if.h
#include err.h
#include stdio.h
#include string.h
#include unistd.h
int
main(void)
{
int s, af = AF_INET;
char *name = ed0;
struct ifreq ifr;
if ((s = socket(af, SOCK_DGRAM, 0)) 0)
err(1, socket);
ifr.ifr_addr.sa_family = AF_INET;
strcpy(ifr.ifr_name, name);
if (ioctl(s, SIOCGIFMTU, (caddr_t)ifr) 0)
warn(ioctl (get mtu));
fprintf(stdout, MTU of %s is %d.\n, name, ifr.ifr_mtu);
close(s);
return(0);
}
--
Skip
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off by one bounds
Maxim Konovalov wrote: On Fri, 20 Aug 2004, 12:36-0700, Ted Unangst wrote: errors in freebsd 4.10 found by Coverity's analysis. ip_icmp.c:ip_next_mtu, i == sizeof, dir = 0 If i == sizeof then mtutab[i] == 0 If i == sizeof then mtutab[i] is out of bounds, off by one. There is no mtutab[sizeof mtutab / sizeof mtutab[0]]. This isn't specific to RELENG_4. -- Skip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: off by one bounds
Maxim Konovalov wrote: On Sat, 21 Aug 2004, 13:19+0400, Maxim Konovalov wrote: On Sat, 21 Aug 2004, 05:00-0400, Skip Ford wrote: Maxim Konovalov wrote: On Fri, 20 Aug 2004, 12:36-0700, Ted Unangst wrote: errors in freebsd 4.10 found by Coverity's analysis. ip_icmp.c:ip_next_mtu, i == sizeof, dir = 0 If i == sizeof then mtutab[i] == 0 If i == sizeof then mtutab[i] is out of bounds, off by one. There is no mtutab[sizeof mtutab / sizeof mtutab[0]]. This isn't specific to RELENG_4 After the second thought I still think it is not a error. mtu is always = than the minimal value in mtutab[] that is why i is always less than (sizeof mtutab) / sizeof mtutab[0]). What do you think? I have no idea if it can actually be triggered. Callers may never invoke it with the necessary parameters but if they do, the function doesn't handle it. If mtu is 0 and dir = 0 then mtutab is accessed out of bounds. -- Skip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
