Re: ifmcstat(8) setgidness
On Wed, Jun 27, 2001 at 06:29:15PM -0700, Dima Dorfman wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: On Wed, Jun 27, 2001 at 01:29:28AM -0700, Dima Dorfman wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: On Tue, Jun 26, 2001 at 03:04:07PM -0700, Dima Dorfman wrote: Hi folks, Is there a particular reason, other than the desire for more setgid programs, that ifmcstat(8) is setgid kmem? It seems that there's no reason anyone but root would want to use it, anyway. OpenBSD and NetBSD already nuked its setgid bit; any reason why we shouldn't follow suit? $ ifmcstat kvm_openfiles: Permission denied I don't follow. Yes, it needs access to kmem to work. However, I don't see why anyone other than root would need to run it, so why is it setgid? root can access kmem either way. Could you please elaborate on why it should be restricted to root only? Because it looks like it doesn't provide any information that anyone other than the administrator would find useful (if I'm seeing things, please let me know), and the less setgid programs in the system the better our overworked security officer(s) sleep at night :-). Then why not make it installed with BINMODE=550 at least? OpenBSD's and NetBSD's commitlogs are too terse. This is quite an understatement! I meant these particular logs. If you don't find these terse, my apologies: : revision 1.2 : date: 2001/06/23 00:50:33; author: deraadt; state: Exp; lines: +1 -1 : only root need apply : revision 1.2 : date: 2001/06/26 17:10:33; author: itojun; state: Exp; lines: +2 -2 : drop setgid. suggested by deraadt Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
E.B. Dreger wrote: [ ... wrapped fd using functions in libc_r ... ] So it's a thunk/kludge not only to enforce proper behavior, but also to prevent the process from blocking and stalling other threads? This makes sense. It also permits locks on the descriptors, to ensure that one thread does not modify a descriptor out from under another thread while it is blocked on some outstanding operation. [ ... ] The reason that I asked is because I'm writing a program that uses rfork() in the same manner as the new rfork_thread(). I couldn't understand the need to wrap kevent(2), bind(2), or accept(2)... In my mind, I was thinking data integrity, trying to prevent processes in the same thread family from stepping on one another. Blocking is not a problem; where I can't use non-blocking calls, I use a worker thread. The threads scheduler is in user space. It converts a blobking call into a non-blocking call plus a context switch. THus blocking _IS_ a problem. I guess that I was looking at man pages and bits of libc_r code without understanding the pthread implementation. I knew that it was userland, but I thought that it created multiple processes... if this is not the case, then I was apparently comparing apples to mangoes. This is not the case. The user space threads library does what the original idea of threads was intended to do, before people started treating it as the only hammer they had to pound on the SMP problem with in order to achieve SMP scalability: it utilizes the full quantum of the process, and minimizes context switch overhead. Kernel threads don't do either of these things well, in almost all existing implementations out there. Am I correct that libc_r does _not_ use multiple processes to create threads? Yes. All threads run in a single process. The threads are not intended as a workaround for the SMP scalability problem. Note that you are not going to be able to combine your rfork approach with this, if your resulting processes end up running on different CPUs: this is because the locking primitives in the libc_r library do _NOT_ use the lock prefix on the cmpxchg instruction, which means that multiple processors are not forced to a rendevous, there's no IPI, and the TLB and L1 cache shootdown isn't moderated by the cache MP 1.4 specification cache coherency protocol, and thus the locks it uses are _NOT_ MP safe. If you need kernel threads, look at the Linux kernel threads in the ports collection (it's a kernel module that builds and installs as a package). You probably don't, since performance of kernel threads is really only about a 20% increment, if you implement them the SVR4 or Solaris (pre-2.7) or Linux way. It's probably better to implement with FreeBSD threads as they currently exist, and get massive SMP scalability when KSE's are brought into the source tree. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: interrupt on to Kernel
vinu pattery wrote: Could some body let me know, how to hack the FReeBSD kernel to learn the exact sequence of steps which happen when the device driver interrupts the FreeBSD Kernel for resources. Is there a trace debugger available, with which i can find out the steps. It's not clear what you mean by interrupt the Kernel for resources... the only resources you can grab at interrupt are things that you pre-allocated, things you get from a zalloci() from a previously established interrupt safe zone in the zone allocator (e.g. mbufs), and CPU time. As far as your tracing question: man ddb; you can set breakpoints in the kernel, and step through them. You probably _don't_ want to do this in an interrupt routine, but you could. You may want to look at the FreeBSD Handbook, and at the device driver and bus articles on: http://www.daemonnews.org/ There is also a (fairly old) Device Driver Writer's Guide: http://freebsd.dei.uc.pt/tutorials/ddwg/ddwg.html -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NGPT 1.0.0 port to freebsd
http://freshmeat.net/projects/ngpt http://www.sharma-home.net/~adsharma/projects/freebsd/ngpt-1.0.0-freebsd.tar.gz Notes: - The project has gotten more Linux specific since the last port (0.9.4) There are a lot of ugly hacks that need cleanup. - Please commit 27489 to help this port - There were many deviations from the freebsd pthread.h (specifically the omission of const int vs size_t etc) - The main point of this port is to have a reasonable native freebsd pthread implementation till the scheduler activations stuff is ready. - Java heads: does this help to pass the JCK ? Is that the main reason we can't have a binary FreeBSD JDK distribution ? I've read -java for several months now and I still can't find the answer. To test the above port: - make test_pthread; ./test_pthread - You may want to turn off debugging in pth_p.h - Tested only on a UP machine (my laptop) so far. Needs SMP testing. The earliest I can do it is this weekend. Disclaimer: - I've mainly done the monkey work of fixing compile errors and making sure that the test program works. Haven't had a chance to look at the implementation specifics yet. I didn't like some design decisions in 0.9.4. - Someone here had a makecontext() patch. I think commiting it would surely help. The way GNU pth does context creation is really inefficient, in order to be portable (read the pth paper). -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: processes private data
On Thu, Jun 28, 2001 at 07:48:21PM +0100, Doug Rabson wrote:
On Thu, 28 Jun 2001, Nicolas Souchu wrote:
Hi folks,
I have a char driver that must be opened by more than one process. The minor
index is not sufficient for this. Is there any process private data (void *)
in the devfs structure (or the opposite) I could point to with the minor index
of my device?
The only way I know of to do this is to get a new struct file with
falloc() and install your own fileops. You can then set p-p_dupfd to the
new file descriptor and return ENXIO. The caller will magically use the
new struct file. For an example, see streamsopen() in
sys/dev/streams/streams.c.
Ok, it seems to do part of the job. But this won't change the content of the
file struct. Does anything ensure that the f_data of the freshly allocated
struct file won't be used by vfs? Is the new struct file only local to my
device driver?
Otherwise, I could write my own falloc() which would allocate a struct file
compatible with the original one like this:
struct my_file {
struct file original;
void *my_private;
...
};
Nicholas
--
Alcôve Technical Manager - [EMAIL PROTECTED] - http://www.alcove.com
Open Source Software Developer - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: FW: Linux Applications Over PPP
rod person wrote: here is my ppp.conf. also try using ppxp from the ports, which is what I use in X. either way I have no problems Rod My ppp.conf file is pretty much identical to yours, the only difference being that I don't have the ident user-ppp VERSION (built COMPILATIONDATE) line. I tried inserting this into my ppp.conf, but it generated an error. I suspect the problem is not in my ppp.conf file - I think it is more subtle. For some bizarre reason, Linux apps don't seem to recognise my tun0 interface... John. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FW: Linux Applications Over PPP
rod person wrote: here is my ppp.conf. also try using ppxp from the ports, which is what I use in X. either way I have no problems Rod My ppp.conf file is pretty much identical to yours, the only difference being that I don't have the ident user-ppp VERSION (built COMPILATIONDATE) line. I tried inserting this into my ppp.conf, but it generated an error. I suspect the problem is not in my ppp.conf file - I think it is more subtle. For some bizarre reason, Linux apps don't seem to recognise my tun0 interface... John. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Linux Applications Over PPP
Hi, Six million *.rpm files later, I've finally got the Linux version of Mozilla working properly. However, neither the Linux versions of Mozilla or Opera seem to be able use my PPP connection - they simply can't connect to anything, even when I'm fully connected and browsing using the FreeBSD version of Mozilla. Why is this? What setting do I need to alter to enable Linux apps to use my PPP connection? Regards, John. ppp.conf (username/password hashed out!): # # PPP Sample Configuration File # Originally written by Toshiharu OHNO # Simplified 5/14/1999 by [EMAIL PROTECTED] # # $FreeBSD: src/etc/ppp/ppp.conf,v 1.2 1999/08/27 23:24:08 peter Exp $ # default: # # Make sure that device references the correct serial port # for your modem. (cuaa0 = COM1, cuaa1 = COM2) # set device /dev/cuaa0 set log Phase Chat LCP IPCP CCP tun command set speed 57600 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT OK-AT-OK ATE1Q0M0 OK \\dATDT\\T TIMEOUT 40 CONNECT set timeout 120 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add default HISADDR enable dns anytime: set phone 08089933001 set authname set authkey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: processes private data
On Fri, 29 Jun 2001, Nicolas Souchu wrote: On Thu, Jun 28, 2001 at 07:48:21PM +0100, Doug Rabson wrote: On Thu, 28 Jun 2001, Nicolas Souchu wrote: Hi folks, I have a char driver that must be opened by more than one process. The minor index is not sufficient for this. Is there any process private data (void *) in the devfs structure (or the opposite) I could point to with the minor index of my device? The only way I know of to do this is to get a new struct file with falloc() and install your own fileops. You can then set p-p_dupfd to the new file descriptor and return ENXIO. The caller will magically use the new struct file. For an example, see streamsopen() in sys/dev/streams/streams.c. Ok, it seems to do part of the job. But this won't change the content of the file struct. Does anything ensure that the f_data of the freshly allocated struct file won't be used by vfs? Is the new struct file only local to my device driver? Otherwise, I could write my own falloc() which would allocate a struct file compatible with the original one like this: When you get a new struct file from falloc(), VFS has nothing to do with it. As you can see from the streamsopen() code, you can change f_ops (which by default points at badfileops) and f_data (defaults to zero) to point at your own functions and data. The point is that you are creating a new file. The VFS-owned file which ended up calling the open driver entrypoint will be discarded in favour of your new one. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Serial port control
Jason Borkowsky wrote: I am looking to find a simple way to control a serial port through BSD (such as raising and lowering DTR for a specified duration). I thought I had it using ioctl() and wrote a simple program to test it, but it seems I don't have a full understanding of ioctl(). Does anyone know of any pre-written utilities I can use? Or where to get some really detailed information about ioctl()? Thanks! After several responses, I thought I had it. From a software point of view, my program, included below, works fine. But from a hardware point of view, the signals I am trying to lower, RTS and DTR, are staying high. Can anyone try to compile the below program and do a serial port test with an RS-232 tester and see if anyone actually sees RTS and DTR going low? Sorry for bothering everyone with this again, but this is driving me nuts and I can't figure out the problem now. Thanks! Nausicaa/p0 (77 ~): gcc -o serialioctl serialioctl.c Nausicaa/p0 (78 ~): sudo ./serialioctl Password: Current Serial Settings: Ring RTS DTR DSR Current Serial Settings: Ring DSR Nausicaa/p0 (79 ~): uname -a FreeBSD Nausicaa.mitre.org 4.3-RC FreeBSD 4.3-RC #2: Tue Apr 10 10:50:19 EDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NAUSICAA i386 Seems to work for me. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: An netgraph firewall module ? Is this possible / good performing ?
Nicolai Petri wrote: Hi hackers, I've used some time writing a custom natd like daemon which makes som speciel packet processing. One of the issues with the natd approach is the large amount of context-switches it gives. This can be a real performance problem on very loaded networks. Would it be possible to do this with netgraph instead. And what is the pro's and con's for this approach. As a second step in developement how should protocol verification (ftp/smtp/whatever) be added to a netgraph firewall approach in a structured and dynamic extendable way ? Unfortunatly, the netgraph code does not have a hook into the IP code so at this time you cannot pass packets into the IP protocol and have them then go to netgraph. You could however put a filter onto the ethernet interface, but then you'd have to take into account the 14 byte header too. Best regards, Nicolai Petri To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Fri, Jun 29, 2001 at 10:55:39AM -0400, [EMAIL PROTECTED] wrote: In a message dated 6/28/01 11:16:31 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Because my motherboard is 20 times faster, has VGA support,doesnt require an add-on board to do fast encryption and costs about the same as yours. Thats why. Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(Warning: rather long message) Date: Fri, 29 Jun 2001 00:50:30 -0700 From: Terry Lambert [EMAIL PROTECTED] [ ... wrapped fd using functions in libc_r ... ] [ fd locking, to prevent chopping feet from beneath ] As-needed serialization to prevent breakage = proper behavior. I should have been more clear. The threads scheduler is in user space. It converts a blobking call into a non-blocking call plus a context switch. THus blocking _IS_ a problem. Bad wording on my part again; perhaps a problem that I [think that] I have handled is better. I'm use nb calls if possible; else I have a long-running worker thread. After my recent question regarding AIO, it looks like it's time to bite the bullet and use that as well. [ ... thinking that pthreads used multiple processes ... ] This is not the case. So I've learned. I'm glad that I didn't use pthreads, then. :-) The user space threads library does what the original idea of threads was intended to do, before people started treating it as the only hammer they had to pound on the SMP problem with in order to achieve SMP scalability: it utilizes the full quantum of the process, and minimizes context switch overhead. Kernel threads don't do either of these things well, in almost all existing implementations out there. Agreed on all counts. I'm tempted to continue eschewing the pthread library. I've unrolled code, and store state info in a purpose-specific FSM control block. Maybe I reinvented the wheel, but it wasn't that difficult. Am I correct that libc_r does _not_ use multiple processes to create threads? Yes. All threads run in a single process. The threads are not intended as a workaround for the SMP scalability problem. A good thing, IMHO. I was starting to look at libc_r to check my work; I _prefer_ launching multiple processess for SMP scalability, and having an untainted threading model. Note that you are not going to be able to combine your rfork approach with this, if your resulting processes end up running on different CPUs: this is because the Running processes on multiple CPUs is one goal. [ libc_r locks don't assert lock, not MP-safe ] So the lock prefix is the only way to enforce cache coherency? Do you have handy a good reference on IPIs, other than the kernel APIC code (and, of course, Google and NorthernLight searches)? Good to know, but, I'm not using libc_r... I was looking at existing code to help me double-check mine as I go. I'm synchronizing processes with a giant lock token that each process cooperatively passes to the next... to simplify: who_has_lock++ ; who_has_lock %= process_count ; Each processes' critical path first checks to see if it holds the token; if so, it performs the tasks that require it, such as locking a finer-grained lock or mutex. It then passes the token, and continues through its critical path. If a thread has nothing to do, I nanosleep(2) to prevent the critical path from degenerating to an extended spin. I'm considering using socketpair(2)s, with a process blocking indefinitely on read(2) until another process write(2)s to awaken it... If you need kernel threads, look at the Linux kernel threads in the ports collection (it's a kernel module that builds and installs as a package). You probably don't, since performance of kernel threads is really only Correct me if I'm wrong, but the only place in my model that really might benefit from kthreads would be the scheduling? i.e., rather than screwing around with nanosleep(2) or socket calls, I could cut the cruft and interact more directly with the scheduler via kthread mechanisms? about a 20% increment, if you implement them the SVR4 or Solaris (pre-2.7) or Linux way. It's probably better to implement with FreeBSD threads as they currently exist, and get massive SMP scalability when KSE's are brought into the source tree. KSEs... where can I read up? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bridging with pcmcia cards
thank you - this was helpful. One last question - when you say that bridging cannot work with wi cards because they do not support promiscuous transmission, this makes me wonder two things: 1. Do you mean the wi driver does not support this, or you mean the actual physical card itself is limited in this way 2. I know that there are two major firmware differences between old lucent cards and new lucent cards, and that is that the old ones can be _actually_ set to SSID of and then pick up base station in range. Is it possible that (if the answer to #1 above is it's a hardware problem) that the old revision cards are better at this, or are they all like this ? thanks a lot. I was actually _only_ interested in just plain old options BRIDGE bridging, and not being a virtual AP (so far). Julian Elischer wrote: bridging is not a function of it being a pc-card.. This is true, particularly with netgraph bridging. actually bridging may already work with wi cards also netgraph bridgiung may also work... Bridging cannot work with wi cards, since they do not support promiscuous transmission (that is, sending frames with other than their own MAC address). Moreover, anyone seriously desiring to bridge wi cards very likely wants to actually do something that is more than bridging -- they probably want to be an access point (ala Apple's virtual airport functionality). The difference between that and just bridging is that the wireless clients can see each other with certainty (that is, no hidden node issues) and they can turn on power saving (that is, having the receiver duty cycle be less than 100%). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
On Fri, Jun 29, 2001 at 03:19:47PM +, E.B. Dreger wrote: The threads scheduler is in user space. It converts a blobking call into a non-blocking call plus a context switch. THus blocking _IS_ a problem. Bad wording on my part again; perhaps a problem that I [think that] I have handled is better. I'm use nb calls if possible; else I have a long-running worker thread. I hope you understand that when the worker thread blocks, it's the process that blocks, and none of the other threads can run until the end of the syscall. After my recent question regarding AIO, it looks like it's time to bite the bullet and use that as well. G'luck, Peter -- If this sentence were in Chinese, it would say something else. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Fri, 29 Jun 2001 18:33:52 +0300 From: Peter Pentchev [EMAIL PROTECTED] The threads scheduler is in user space. It converts a blobking call into a non-blocking call plus a context switch. THus blocking _IS_ a problem. Bad wording on my part again; perhaps a problem that I [think that] I have handled is better. I'm use nb calls if possible; else I have a long-running worker thread. I hope you understand that when the worker thread blocks, it's the process that blocks, and none of the other threads Yes. it's the process that blocks, and none of the other threads ^ can run until the end of the syscall. Again, I am *not* using pthreads. Worker thread = totally separate process, created via rfork(2). One process blocks, others continue running. To reiterate: I'm *not* using pthreads or libc_r. I wanted to check my work, and began looking at libc_r code, under the faulty ass-umption that it ran multiple processes. Now that I know that threads are implemented in a single process, and that blocking calls are thunked to non-blocking calls, the locking that I originally questioned makes sense. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Java (Was Re: NGPT 1.0.0 port to freebsd)
On Fri, Jun 29, 2001 at 09:05:25AM -0600, Nate Williams wrote: With the current license, this won't be installed as part of the base kernel. (GPL and/or LGPL) I understand it'll continue to be a port. Am I hearing that it is unacceptable even as a temporary solution because of the license ? It's been answered time and time again over the past months, so you must not be paying attention. The binary distribution hasn't been created because we don't have a legal license to do so (yet). Yes, I've been reading that for a long time now, but it (what Sun is doing) doesn't make any sense to me. Are Sun's reasons (a) Technical ? Passing of JCK etc ? (b) Political ? Yet another competitor to Solaris ? From your posting it appears that it's technical (not passing JCK), as well as political (not getting the license to run JCK). What is their answer reg: blackdown.org doing the same ? May be getting Zdnet to publish an article on this is the right way to go ? The bug parades and votes didn't seem to help much. In summary, a Java binary distribution of JDK1.2.2 will come out *very soon* after a usable license with Sun has been signed. Hopefully, we'll have a JDK1.3 binary distribution soon after, as Greg Lewis has made alot of progress on it and has it limping along right now. That's good to hear. Eagerly awaiting the news. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
CPU affinity hinting
(Cross-posting again... I'm willing to be larted with a herring if this is unacceptable for the content presented.) I was thinking about CPU affinity on SMP systems the following is on-list brainstorming. Take a two-way box running 10 httpd and 10 smtpd processes. Assuming equal CPU time requirements, it would make sense to bind httpd to one CPU, and smtpd to the other. Simple, but not realistic. Maybe smtpd requires more CPU time. Fine... limit one processor to smtpd, run leftover smtpd on the other CPU, and run httpd _only_ on the processor handling leftover smtpd. Or consider ten instances of a single program that uses four processes, sort of like squid * 10: It would make more sense to have similar processes grouped on the same CPU. After watching processes switch CPUs via top, I got to thinking... could there be, and would it be useful to have, a mechanism where processes could tell the kernel my magic number is 6819732, and the kernel would try to keep all processes with said magic number on the same CPU? Is this solution worse than the problem (cache thrash and switching CPUs)? I suppose that the kernel could do a quick, numerically-simple hash of the ELF metadata, as opposed to program-specified magic. This would handle the httpd/smtpd case, with less fear of magic number collisions, but not rfork(2)ed threads. Or, instead of hashing ELF metadata, the kernel could compute a hash based on all IP ports bind(2)ed by the program within the first few seconds of operation. (Obviously unsuitable for short-lived programs, but those could probably be handled via least-busy CPU assignment.) Perhaps a hybrid approach: cpu_hint = hash(elf_metadata, hint) % num_cpus ; where hint is specified by the process in a group? Thoughts? Criticisms? Flames? Beatings with a stinky fish? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Java (Was Re: NGPT 1.0.0 port to freebsd)
With the current license, this won't be installed as part of the base kernel. (GPL and/or LGPL) I understand it'll continue to be a port. Am I hearing that it is unacceptable even as a temporary solution because of the license ? It's been answered time and time again over the past months, so you must not be paying attention. The binary distribution hasn't been created because we don't have a legal license to do so (yet). Yes, I've been reading that for a long time now, but it (what Sun is doing) doesn't make any sense to me. Are Sun's reasons (a) Technical ? Passing of JCK etc ? (b) Political ? Yet another competitor to Solaris ? Sun is very picky about the license they want to give us. In particular, due to a recent fight in court they had with an well-known company in the Pacific Northwest, the type of license they are proposing protects them from just about everything, but doesn't give us enough lee-way to actually distribute the license. The difficulty has been trying to appease Sun's lawyers w/out overlying restricting the team's ability to create and maintain the JDK long-term. (In other words, we don't want to have to go through this over and over again for each new JDK release). From your posting it appears that it's technical (not passing JCK), Passing the JCK/TCK is simply an excercise that we haven't done yet. Basically, once you pass the TCK, you must ship the *EXACT* version of the binary without any modifications. Since we are still doing development of the port, it seemed a waste of time to run the TCK when we may have to run it again if/when the license is signed. (Running the TCK is a long, drawn out process that one doesn't want to repeat if at all possible.) well as political (not getting the license to run JCK). What is their answer reg: blackdown.org doing the same ? Blackdown was given access to the JDK before the recent lawsuit, and as such has 'special' privileges that they are no longer willing to grant to new licensees. May be getting Zdnet to publish an article on this is the right way to go ? The bug parades and votes didn't seem to help much. Actually, it's the reason that Sun is doing the dance with us right now. The whole Java affair has been a series of mis-steps by all parties (myself, BSDi, and Sun), so no one party shares the entire blame. The most recent issue was the BSDi/WindRiver acquisition, which left us w/out any legal advisors (unless we wanted to pay out of the pocket, which would have cost upwards of $2K to solve, not something I can affort). We're hoping to have something for you in the near future. Unfortunately, my Sun contact went on vacation yesterday before I could get some stuff ironed out, and when he gets back from vacation, I'm going on vacation, so nothing can get done with this for at least another month. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
On Fri, Jun 29, 2001 at 03:44:03PM +, E.B. Dreger wrote: Again, I am *not* using pthreads. Worker thread = totally separate process, created via rfork(2). One process blocks, others continue running. I can't see how you make shure that on SMP systems all CPUs have the same meaning from memory content. Normaly you would use a mutex or similar before accessing a data range from another thread which also enshures that the CPU specific caches and buffers are syncronised. If you don't do this it may happen that you write a variable and another thread uses this variable using another CPU before the first CPU has writen this memory seeable for others and works with an outdated content. A fresh rforked process with the same virtual memory should at least see the version at the time of the rfork, so there is no problem if you don't modify the common used content after rfork. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
Date: Fri, 29 Jun 2001 20:33:51 +0200 From: Bernd Walter [EMAIL PROTECTED] I can't see how you make shure that on SMP systems all CPUs have the same meaning from memory content. Normaly you would use a mutex or similar before accessing a data range from another thread which also enshures that the CPU specific caches and buffers are syncronised. If you don't do this it may happen that you write a variable and another thread uses this variable using another CPU before the first CPU has writen this memory seeable for others and works with an outdated content. Passing a token between threads. When a thread has the token, it may assert a lock or a mutex on an object. Again, I subscribe to threads being lightweight; cooperative sharing is better than preemptive or trying to grab a lock before another thread does. Any good references on MP standard? Is the lock prefix the only way to force cache coherency? Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
On Fri, Jun 29, 2001 at 06:44:29PM +, E.B. Dreger wrote: Date: Fri, 29 Jun 2001 20:33:51 +0200 From: Bernd Walter [EMAIL PROTECTED] I can't see how you make shure that on SMP systems all CPUs have the same meaning from memory content. Normaly you would use a mutex or similar before accessing a data range from another thread which also enshures that the CPU specific caches and buffers are syncronised. If you don't do this it may happen that you write a variable and another thread uses this variable using another CPU before the first CPU has writen this memory seeable for others and works with an outdated content. Passing a token between threads. When a thread has the token, it may assert a lock or a mutex on an object. Again, I subscribe to threads being lightweight; cooperative sharing is better than preemptive or trying to grab a lock before another thread does. A Token may not be enough because writes may be reordered. Usually a mutex is a lock with some kind of memory barrier. If you can fetch the lock on a CPU you know that the CPU previous owning the lock has flushed everything up to the point of coherence of what was written until the lock was released. Memory barriers and the read-modify-write operations (or locked operations like on ALPHA) are accessible from user code - but I don't know of any platform independend functions. Any good references on MP standard? Is the lock prefix the only way to force cache coherency? A good explanation for this kind of thing was in Programming with POSIX Threads in Chapter 3.4 Memory visible between threads. I know you are not usung pthreads but the memory problems are the same. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
(Personal CCs trimmed; back to Bernd and cross-posting -smp and -hackers) Date: Fri, 29 Jun 2001 21:18:18 +0200 From: Bernd Walter [EMAIL PROTECTED] Passing a token between threads. When a thread has the token, it may assert a lock or a mutex on an object. Again, I subscribe to threads being lightweight; cooperative sharing is better than preemptive or trying to grab a lock before another thread does. A Token may not be enough because writes may be reordered. Usually a mutex is a lock with some kind of memory barrier. But it _is_ locked. The thread_with_token++ ; thread_with_token %= num_threads ; was oversimplified. It's more like xorl %ecx,%ecx movl thread_with_token,%eax incl %eax cmpl %eax,num_threads movzl %ecx,%eax lock movl %eax,thread_with_token to pass the token, where thread_with_token is in shared memory. Each process does the above. When a process has the token, it's safe to claim mutexes and such without worry of another thread (without token) accessing simultaneously. Mutex/lock ops also have lock asserted. If this is inadequate, then I need to do some head-scratching. If you can fetch the lock on a CPU you know that the CPU previous owning the lock has flushed everything up to the point of coherence of what was written until the lock was released. Here is where I want to learn more about cache coherency, inter-processor interrupts, and APIC programming. I'd imagine that the latter two are lower-level than I'd be using, but I still want to know the how and why beneath the scenes. Memory barriers and the read-modify-write operations (or locked operations like on ALPHA) are accessible from user code - but I don't know of any platform independend functions. Nor do I. Any good references on MP standard? Is the lock prefix the only way to force cache coherency? A good explanation for this kind of thing was in Programming with POSIX Threads in Chapter 3.4 Memory visible between threads. I'll have to check it out. I [believe that I] understand about the inherent races in SMP, but more reading is always better... However, I'm still interested in x86-specific coherency mechanisms. Any info? I know you are not usung pthreads but the memory problems are the same. Correct. I just wanted to make certain that we were on the same page, no pun intended. Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: CPU affinity hinting
Date: Fri, 29 Jun 2001 13:14:58 -0700 From: Matthew Rogers [EMAIL PROTECTED] Why not just use First in line, Next processor available ? Then you wouldn't care what processor did which task. That was my question: Would the added complexity of CPU affinity hinting be worth the reduction in cache misses and switching processes, by preventing long-running processes from constantly switching CPUs? FILNPA is fine for short-lived processes, but longer-running ones switch CPUs, perhaps unnecessarily. Hmm, maybe even have each processor a dedicated memory space, and programmable functionality. Oops, that's a Field Programmable Gate Array, and there going to make Legacy computing look stupid. FPGAs, . Transputers, . Neuromatrix, . In my mind, you have a need for multiprocessing Non-specific and Specific tasking. In some ways we are multiprocessing anyway on some level. Videocard 3d processing, sound card. You mean that Winmodems and main memory-based video aren't the keys to high performance? You mean that Intel is being silly when they justify faster chips by saying now you can eliminate three $20 DSPs by buying our latest architecture? :-) So why do we need a GOD chip, ie the chipset controlling access to processors and busses ? That's because that's the way it was done before the 286. Time to leave the bus. :) Arguably so from a hardware standpoint. But, in the mean time, I was trying to think of ways to help SMP performance. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc_r locking... why?
On Fri, 29 Jun 2001, Terry Lambert wrote: E.B. Dreger wrote: If you need kernel threads, look at the Linux kernel threads in the ports collection (it's a kernel module that builds and installs as a package). You probably don't, since performance of kernel threads is really only about a 20% increment, if you implement them the SVR4 or Solaris (pre-2.7) or Linux way. It's probably better to implement with FreeBSD threads as they currently exist, and get massive SMP scalability when KSE's are brought into the source tree. just a quick question... I konw KSE will brought in after SMPng. but it will be really helpful to konw when it will first appear in the source tree? or what other OS can help with SMP vs pthread problem? thx. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CPU affinity hinting
On Fri, Jun 29, 2001 at 09:14:06PM +, E.B. Dreger scribbled: | Date: Fri, 29 Jun 2001 13:14:58 -0700 | From: Matthew Rogers [EMAIL PROTECTED] The issue is a lot more complicated than what you think. This actually is a big issue in our future SMP implementation. There are two types of processor affinity: user-configurable and system automated. We have no implementation of the former, and alfred-vm has a semblance of the latter. Please wait patiently. Michael -- +---+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Quick question on kgdb
if I wish to use Kgdb, I build the kernel with the following set of steps from http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-building.html Since I make my own modifications to the source code I do the following Change to the /usr/src directory # cd /usr/src Compile the kernel. # make buildkernel KERNCONF=MYKERNEL Install the new kernel. # make installkernel KERNCONF=MYKERNEL MYKERNEL has the DEBUG=-g options for the make (I modified /usr/src/sys/i386/conf/MYKERNEL) when I load up the installed kernel in / with 'gdb -k kernel' .. it says debugging symbols not found Am i loading up the right file ?. Is is supposed to have the symbols in it? Regards -AG __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: CPU affinity hinting
Date: Fri, 29 Jun 2001 21:44:43 -0500 From: Michael C . Wu [EMAIL PROTECTED] The issue is a lot more complicated than what you think. How so? I know that idleproc and the new ipending / threaded INTs enter the picture... and, after seeing the HLT benchmark page, it would appear that simply doing nothing is sometimes better than doing something, although I'm still scratching my head over that... This actually is a big issue in our future SMP implementation. I presumed as much; the examples I gave were trivial. I also assume that memory allocation is a major issue... to not waste time with inter-CPU locking, I'd assume that memory would be split into pools, a la Hoard. Maybe start with approx. NPROC count equally-sized pools, which are roughly earmarked per hypothetical process. For example: If MAXUSERS=80 -- NPROC=1300, a machine with 256 MB might use 192 kB initial granularity for mmap() requests, giving 128 MB to each processor as a first approximation. Now, no locking is needed on mmap() until a given CPU's pool hits low water, and steals from another pool. This would hopefully be infrequent, particularly assuming that memory allocations would be distributed roughly equally between CPUs. I'm assuming that memory allocations are 1:1 mappable wrt processes. Yes, I know that's faulty and oversimplified, particularly for things like buffers and filesystem cache. There are two types of processor affinity: user-configurable and system automated. We have no implementation of the former, Again, why not hash(sys_auto, user_config) % NCPU? Identical processes would be on same CPU unless perturbed by user_config. Collisions from identical user_config values in unrelated processes would be less likely because of the sys_auto pertubation. Granted: It Is Always More Complicated. (TM) But for a first pass... and alfred-vm has a semblance of the latter. Please wait patiently. Or, if impatient, would one continue to brainstorm, not expect a response (i.e., not get disappointed when something basic is posted), and track -current after the destabilization? :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Quick question: AIO / SMP / process-based threading
Quick question(s): 1. Is AIO SMP-safe? 2. If not, how could one force coherency? (Read and rewrite locked a word from each cache line?) Is it worth the effort, or should one not use AIO across process boundaries? I'm asking primarily about 4.x, unless anyone has good guesses of how 5.x will be. ;-) I'll also keep an eye out for KSEs... thanks to Terry and others for alerting me to those. (KSEs really answer most of my recent questions, but I don't think that I can wait that long, nor do I have the kernel background to really offer any assistance in the KSE project...) TIA, Eddy --- Brotsman Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Quick question: AIO / SMP / process-based threading
On Sat, Jun 30, 2001 at 05:47:49AM +, E.B. Dreger scribbled: | 1. Is AIO SMP-safe? AIO is not safe, SMP or not. | 2. If not, how could one force coherency? (Read and rewrite locked |a word from each cache line?) Is it worth the effort, or should |one not use AIO across process boundaries? Don't use it. | I'm asking primarily about 4.x, unless anyone has good guesses of | how 5.x will be. ;-) | | I'll also keep an eye out for KSEs... thanks to Terry and others | for alerting me to those. (KSEs really answer most of my recent | questions, but I don't think that I can wait that long, nor do I | have the kernel background to really offer any assistance in the | KSE project...) | KSE won't be available for a long time. -- +---+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fastforwarding?
On Thu, Jun 28, 2001 at 10:32:50PM +0200, Dag-Erling Smorgrav wrote: Wes Peters [EMAIL PROTECTED] writes: The description there isn't very forthcoming. fastforwarding caches the results of a route lookup for destination addresses that are not on the local machine, and uses the cached route to short-circuit the normal (relatively slow) route lookup process. The packet flows directly from one layer2 input routine directly to the opposing layer2 output routine without traversing the IP layer. And more importantly, without traversing ipfw or ipfilter. In other words, don't use this on a firewall. Doesn't this match exactly what's documented in the inet(4) manpage? : IPCTL_FASTFORWARDING (ip.fastforwarding) Boolean: enable/disable the use : of fast IP forwarding code. Defaults to off. When : fast forwarding is enabled, IP packets are for- : warded directly to the appropriate network inter- ^ : face with a minimal validity checking, which : greatly improves the throughput. On the other : hand, they bypass the standard procedures, such as ^^^ : IP option processing and ipfirewall(4) checking. ^^ : It is not guaranteed that every packet will be : fast-forwarded. BTW, Wes, I'm still waiting for a working example of an indirect route with also indirect gateway. All I can get myself here with such a route is: arplookup 5.6.7.8 failed: host is not on local network arpresolve: can't allocate llinfo for 5.6.7.8rt where 5.6.7.8 is that indirect gateway. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
