Re: deny ktrace without read permissions?
> > PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have > read permissions for the user attempting to execute them. > > The intent of this change is to prevent a user from seeing how an > executable with '--x--x--x' perms works by ktrace'ing its execution. > > My question to the -hackers is: is this a useful semantic? Would it break > anything if added? If we make kernel auditing based upon KTRACE (which may or may not happen), this is not a useful change since we need to be able to 'audit' system calls regardless of whether or not KTRACE is used. If this kind of addition is done, then it'll have to be removed since system auditing must occur and be essentially 'independant' of what options are used. If adding auditing has a negative effect on the successful completion of a system call, then it's not going to be used. (There are certain things that can't be avoided, such as additional CPU/memory use, but it should not effect whether or not the syscall is completed.) Also, I believe that KTRACE should be allowed since security through obscurity isn't a good reason to avoid letting the user see the syscall. If security is an issue, KTRACE shouldn't be in the system kernel. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
> jk> The intent of this change is to prevent a user from seeing how an > jk> executable with '--x--x--x' perms works by ktrace'ing its execution. > > jk> My question to -hackers is: is this a useful semantic? Would it break > jk> anything if added? > > nw> If we make kernel auditing based upon KTRACE (which may or may not > nw> happen), this is not a useful change since we need to be able to 'audit' > nw> system calls regardless of whether or not KTRACE is used. If this kind > > This particular change should not affect the future auditing tool. The future audting tools may depend on KTRACE. > The [execve] system call will still be logged as having been > attempted; the control flow remains the same as for the current > ``no execute perms'' case but with a stricter check if KTRACE'ing > is on for the process. Right, but the system requires KTRACE as a pre-requisite for IDS, therefore we've changed the behavior of the system by adding IDS (which brings in KTRACE as a side-effect). What once was considered 'ok' previously is now not OK when IDS is added (exec'ing binaries that don't have the read permission on them..) > nw> If security is an issue, KTRACE shouldn't be in the system. > > Yes, but /if/ KTRACE is present, today's code allows you to bypass > the lack of read permissions on an executable. That shouldn't be > allowed. The current behaviour could be regarded as a security > hole actually :). Naw. You have to reverse engineer the entire piece of code to figure out what it's doing. Knowing the syscalls is not giving you a whole lot of information. > Part of the confusion comes from the meaning of the 'x' bit when > KTRACE'ing is also permitted. Ordinarily the 'x' bit determines > if a user can execute a file. But should execute permissions also > imply the ability to trace the execution of the process? Because 'execution' is almost the same thing as 'trace' (you can't have one w/out the other), then yes. > If so, the value of a permission mask like '--x--x--x' is weakened > because although you cannot read the file, you can 'see inside' it, > indirectly. Very indirectly. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: deny ktrace without read permissions?
> The PR proposes (and the patch given earlier implements) tighter > security on the premise that security in the presence of KTRACE > should be at least as tight as without KTRACE. It achieves this > by requiring read permissions on an executable before it can be > KTRACE'd. As other have pointed out, if you're good enough to reverse engineer a program from just it's syscall, you're probably good enough to stick in a new shared library that allows you to 'reverse engineer' w/out requiring KTRACE. Again, security through obscurity is never a good solution, and this is just that wrapped in different clothes. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
> > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid executables > > in FreeBSD. > > But the point being made is that they are not ignored for executables > which have no read access. And from there, read access can be gained, > because at that point, you have code running in the process's address > space. That's right. In other words, there really is no way of protecting executable files from being read if someone is motivated enough. And, in an open-source OS like FreeBSD, it's not a viable solution in any case Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: yet more ways to attack executing binaries (was Re: deny ktrace without read permissions? )
> > > > LD_LIBRARY_PATH, LD_PRELOAD and LD_DEBUG are ignored for setuid > > > > executables > > > > in FreeBSD. > > > > > > But the point being made is that they are not ignored for executables > > > which have no read access. And from there, read access can be gained, > > > because at that point, you have code running in the process's address > > > space. > > > > That's right. In other words, there really is no way of protecting > > executable files from being read if someone is motivated enough. > > > > And, in an open-source OS like FreeBSD, it's not a viable solution in > > any case > >The only option, as I've mentined previously in this thread, > that I can think of, would be to have an option when building > various linker code to disable searching in $LD_LIBRARY_PATH if > the library being looked for is in the standard library paths. Except that's only *one* of the ways. There's still ptrace and /proc, so you'd have to hunt them down as well. However, assuming you've hunted them all down, you may be removing useful functionality from the system that is currently used, so it's not worth it. SEF's solution of doing a 'setuid(getuid());' is a good solution that solves the problems listed, and doesn't require any modifications to the system. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > :So, I've a box that I have an ipfw ruleset on. The firewall should not be > > :changeable during runtime, and the box runs at securelevel=3. > > : > > :In order to prevent DoS disk-fill attacks, I also have specified > > :IPFW_VERBOSE_LIMIT. FWIW, as you pointed out below, this was put in specifically to avoid a DoS attack. > > :Now, the problem is, in securelevel 3, you cannot zero a rule's counter, > > :so basically once you are up and running, you get to log IPFW_VERBOSE_LIMIT > > :events and then you lose logging (ideally I'd zero nonzero rules once every > > :N minutes). > > : > > :Comments? > > > > Playing devil's advocate, someone might be using those counters for > > accounting purposes. That's about as worse a scenario as I can think > > of, and I can't imagine this sort of situation would be prevalient. > > > > I'd say that the counters should be clearable at high secure level. > > Then there should be a separate counter for logging purposes...? I do not > care if the accounting counters do not clear (ever), since things like MRTG > are designed to deal with that situation. MRTG? > However, it seems bad that you > would not be able to clear your counter for logging purposes, just in case > you actually _did_ mean that you want bad packets to be logged. *grin* > I will also note that it would be acceptable, to me at least, to maintain a > global (rather than per-rule) limit for the verbose limit. In general, I > would think that someone who uses the limit facility is trying to avoid a > DoS style disk-space attack. Agreed, see above. > Having a per-rule limit means that you > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" limit > (assuming an attacker exploits multiple rules) rather than a limit of > "IPFW_VERBOSE_LIMIT". I disagree. I have *tons* of firewall rules, and I don't want to have to recompile my kernel if I modify my script at a later point and make the rules 'more verbose'. Case in point, I may at one time want to 'log' all connections to a particular port, and then later ignore (no longer log) all the connections to that port *except* to a particular host. Or, the reverse may be true. In these cases, I don't want to have to recompile my kernel to allow 'more logging' of the information. I think a 'per-rule' limit works best, instead of a global limit. This also works well in the case of rootkit attempt breakins, since they tend to hit one rule multiple times, and then another multiple times, etc... With a 'global' limit, I may end up 'limiting out' on the first rule, and then miss all the rules hit later on with the attack. > It also makes it more difficult to code in a bunch > of "log" rules, since your periodic "zero" script has to know the number of > each one, and if you just do an "ipfw zero rule1 rule2 rule3" then you > get a bunch of > > /kernel: ipfw: Entry rule1 cleared. > /kernel: ipfw: Entry rule2 cleared. > /kernel: ipfw: Entry rule3 cleared. > > each time you do this. Or, you do like I do, and have a cronjob 'zero' out the entire log ruleset everynight right after it sends the results to me to analyze. However, at times (during breakins I happen to catch, or during ruleset debugging sessions) I still want to have control over individual rules. > I would rather see something like > > /kernel: ipfw: logging limit reached, suspending. > # /sbin/ipfw zerolog > /kernel: ipfw: logging limit reset, resuming. This is essentially what I do. But, you can do 'ipfw zero' which accomplishes the same thing. However, this is really a side-issue. The last thing I'll say is that I think a 'global' counter is a bad idea, and this is from using IPFW for years in a real/deployed FreeBSD firewall situation. It would cause me more trouble than it's worth, and provide 'less' flexibility than currently exists (which I use). The real issue from your first email is '*should* ipfw rules be 'zero-able' at securelevel 3'. I'm of two minds. The paranoid administrator can't think of any bad things that could occur, but I can imagine something bad happening if someone were allowed to do this, although it's not completely concrete. I don't have the brain-cells to dedicate to thinking about the full implications of a 'bad-guy' zeroing out my rules. On the other, the firewall administrator who actually has to use this darn system is less worried about breakins and such, thinking that if someone compromised my system at high securelevels, they could do more damage to my system in other ways than by zeroing out my firewall numbers. But, then again if we're in securelevel 3, we shouldn't let *anyone* do anything to the system, since we're paranoid about anything negative happening to my system. In other words, I'm not sure what is the 'right' thing to do here. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > Having a per-rule limit means that you > > > actually have a "IPFW_VERBOSE_LIMIT * number_of_rules_specifying_log" > > > limit > > > (assuming an attacker exploits multiple rules) rather than a limit of > > > "IPFW_VERBOSE_LIMIT". > > > > I disagree. I have *tons* of firewall rules, and I don't want to have > > to recompile my kernel if I modify my script at a later point and make > > the rules 'more verbose'. > > Huh? > > I think you completely missed what I said - or maybe the opposite. > > Right now, if you have ten "log" rules, I can make your system log up > to 10 * IPFW_VERBOSE_LIMIT rules (assuming I can generate violations for > each rule). If you have 200 rules, it becomes 200 * IPFW_VERBOSE_LIMIT - > again assuming I can generate appropriate violations. > > This eats up a grossly variable amount of disk space, which seems contrary > to the whole concept of IPFW_VERBOSE_LIMIT. If I'm getting attacked such that I'm logging data, I *want* as much information on the attack as possible. I realize this when I setup my IPFW_VERBOSE_LIMIT 'limits' as well as the logging rules. If an attack takes is 1 rule 100 times, and the other 10 rules 1 time, I'd like to see all of this. With a 'global' limit set to 100, I wouldn't see these kinds of hits. Also, from analyzing attacks for years, most attacks have a pattern that is *best* seen from seeing it hit a number of rules. By settin a per-rule limit, you 'generally' can determine that an attack is going to have a signature the same as the previous 'n' hits on that rule, but you want to see the rest of the attack. I don't care to see a scan of the IMAP 1000 times when right after they finish scanning it they also try to attack my POP3 port 1000 times. Rather, I'd rather see the first 100 attempts on the IMAP port, then the first 100 attempts on POP3, then the first 100 attempts on port 7, etc... You get *better* information on per-rule limits than on a global limit. > If I'm an admin, I'm going to think "Well lets see, I want to store a > month of bad packets in it. If you're an admin on today's internet, you'd realize that there is *NO* way to get save a month worth of bad packets. Heck, at least once/week I can't even store a day's worth of bad packets (I assume when we say bad packets, we're talking about the > I zero > my counters every five minutes and there is a limit of 100 per five mins, > and the average line length is 80 (or whatever) so therefore I need 80 * 100 > * 12 * 24 * 30 or 70MB for my worst case scenario." Not. If the attack is the same, then the syslog error reporting will same something like (this is a real message, with IP addresses change to protect the guilty..): Jun 29 16:43:09 ns /kernel: ipfw: 64000 Deny UDP 1.2.3.4:53 4.3.2.1:54927 out via ed0 Jun 29 16:43:44 ns last message repeated 3 times If you've got seperate attacks, then you've got too much stuff you're logging. > Now given 200 rules, I can fill his disk in substantially less than a day. If you're logging that much information, then you're logging too much information. In any case, you've got information overload, so adding a global limit on the rules means you're losing as much (or more) information than you're logging, which is just as bad (or worse). If you're worried about logging too much information, then don't reset your counters every 5 minutes. Besides, you're losing information if you're max'd out every 5 minutes anyway, so it really doesn't matter when you zero out your counters. > I don't know what you mean by "make the rules 'more verbose'" but what I > am advocating is not any change in what currently exists... I am talking > about limiting the number of entries possible in a manner that would seem > to be more consistent with the intent behind IPFW_VERBOSE_LIMIT. IPFW_VERBOSE_LIMIT is a per/rule limit. This is what is intended. Most attacks don't hit the entire system on every rule in order to do a DoS attack. Even so, each rule with eventually 'limit-out' and the system will no longer log packets. This is a 'bad thing' from a security standpoint, since at that point we are losing information. The idea behind IPFW_VERBOSE_LIMIT is to avoid DoS attacks, while still allowing *MAXIMUM* data collection when a DoS attack is not happening. It's not there to make your logfiles small. If you want small logfiles, turn of IPFW logging altogether. (I'm actually serious here.) > > Case in point, I may at one time want to 'log' all connections to a > > particular port, and then later ignore (no longer log) all the > > connections to that port *except* to a particular host. Or, the reverse > > may be true. In these cases, I don't want to have to recompile my > > kernel to allow 'more logging' of the information. > > Huh? Why would you have to recompile your kernel? Assuming securelevel < > 3, which is required regardless... you just delete the less restrictive > rule and replace it with a more restrictive rule. I want *
Re: securelevel and ipfw zero
> > You get *better* information on per-rule limits than on a global limit. > > No, you simply get a finer-grained ability to select. Which is almost always better. > > > If I'm an admin, I'm going to think "Well lets see, I want to store a > > > month of bad packets in it. > > > > If you're an admin on today's internet, you'd realize that there is *NO* > > way to get save a month worth of bad packets. Heck, at least once/week > > I can't even store a day's worth of bad packets (I assume when we say > > bad packets, we're talking about the > > If I'm an admin on today's internet (and I am), of course I realize that > I'm not going to save a month worth of all bad packets, but I _can_ choose > to hold onto a reasonable amount of logging information, which is what we > are discussing. Sure, but you can't call 'tossing 4/5 of the information that I receive in a totally arbritary manner' useful logging information. A global count would allow you to log information in a totally arbitrary manner. In that case, why have separate log rules? You may not ever get to see them if the limits are hit, so why not just one single rule to catch everything you want to log, since there's no guarantee that you'll see any logged information from the other rules. You might get something, but it's totally arbitrary and based upon known 'scripts' on what information is logged. Finer grained logging gives you *better* information, since it's more detailed. If you don't care about details, then why are you logging at all? > That is part of the _point_ of the IPFW_VERBOSE_LIMIT option... it > allows you to sample the beginning of each 5 minute period, and you > ought to be able to calculate the space required in a manner that > allows you to guarantee that you have sufficient space. I can't speak for the author, but as one of those involved in the discussion this wasn't even on the radar screen. The purpose of the option was to make DoS attacks less likely. It wasn't intended to provide you a good 'sampling' of attack packets on your system. Security is not effectively done by sampling. Sampling is too easy to thwart, and too often misses intrusions that are easily done by not doing sampling. :) And, because IPFW is so low-cost, there is very little reason to do sampling. Sampling is often done when 'real-time' monitoring is too expensive. What I'm hearing is that you want to change FreeBSD from doing 'real-time' monitoring to doing polling. The latter can be implemented from the former, but not vice-versa. We would be losing flexibility and usefulness by moving towards a 'polling' model. My advice to you is to quit 'polling' for packets (because as you've implied, you're not interested in the most of the information anyway), and use a *MUCH* smaller limit on your rules, and limit the number of rules you have, and you'll have almost the same result. > Now, if you're on an OC3c and you want to set IPFW_VERBOSE_LIMIT to 10, > and you reset the counter every 5 minutes, you still _ought_ to be able to > determine that you require 2GB of disk space per day to keep those records. Great, but why even log data when you *plan* on throwing much of it away, in a totally arbitrary fashion. Why even bother? > (And if you're getting 100K rejectable packets every 5 minutes, something > is seriously wrong) Rejectable != log it. I reject alot of packets (most of them) and I don't care to log them. People do stupid things that aren't worthy of being logged, and there are alot of stupid people on the net doing things that aren't malicious that I don't care about. And, if you've got 100K 'logged' packets every 5 mins, then you better plan on having 2GB of disk-space/day if you care about saving them. Otherwise, if you don't have that much disk space, then don't reset every 5 minutes, since you can't keep the information. Either way you throw away information. With per-rule limits you have a much better idea on what kinds of information you are throwing away. (Fine-grained control). > > If you're logging that much information, then you're logging too much > > information. In any case, you've got information overload, so adding a > > global limit on the rules means you're losing as much (or more) > > information than you're logging, which is just as bad (or worse). > > No. You're not necessarily logging too much information. I do log a whole > bunch of shouldn't-happen scenarios, because if they do happen, it means > something is either horribly broken or somebody is doing something horribly > wrong. You might not see that happening since you're global rule was hit in the first 30 seconds by someone doing a POP3 scan of your entire network, followed by a breakin you missed. > I don't want an event such as an outbound source 10-net address to > happen... in theory it can't because I filter at my borders and use no > 10-net stuff internally. But I damn well want to know if it happens > ANYWAYS. You will h
Re: securelevel and ipfw zero
> :Instead of zeroing it, how about raising the logging limit to (current + > :whatever the limit was) > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > : gr...@freebsd.org _ __ ___ | _ ) __| \ > > The way I see it either some piece of software is monitor the counters, > in which case the sysad does not need to clear them and does not need to > look at log messages, or the sysad is monitoring the stuff manually and > using the log messages. In the one case the counters don't need to be > cleared (and, indeed, should not be), in the other case the sysad may > want to clear them due to the manual monitoring. How do you figure? Currently, the kernel will quit 'logging' denied packets when the counter reaches a specific (compiled-in) number. Once that number is hit, you get 'hits', but no details as to what the signature of the hits are. The current 'signature' includes all of the IP information and such, which is invaluable (necessary?) for determing who's doing bad things (or not). This is in the kernel, and currently there is no way of modifying the counters in high securelevels. It doesn't matter if it's a human or a computer monitoring them, once the limit is reached alot of useful information is lost since the kernel no longer produces this information. # ipfw add 110 deny log tcp from any to any 110 via ed0 in Once the compiled in limit is reached, the kernel only says that we've got a hit, but it doesn't tell me who/when this happened. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> :That doesn't mean we shouldn't allow people to have an unsophisticated setup, > :just because a sophisticated one is available. It would be useful to have > :a per-firewall-rule counter, decrement it on each match if logging and > :set, and be able to reset to something higher. > : > : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ > > There may be some confusion here. I am advocating that we *allow* the > zeroing of counters at secure level 3. Sorry Matt, I missed that in my previous posting as well Ignore my previous followup. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> I like the ability at secure level 3 to only reset the counters forward.. > It fits in with such things as the "append only" flag. Then we'd have to implement per-rule counters that default to IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very different setup than what we currently have. (Another thing I just thought of is that this could cause DoS attacks on the system if a user compromised root and then set the limit to a very high number.) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> ipfw allows you to clear counters. It is a feature that already exists. > > However, it does not allow you to do it if you are sitting at secure > level 3. > > Why not? I can't think of any good reason why clearing the counters > should be disallowed when sitting at a higher secure level. The counters > are nothing more then statistics. Clearing statistics is not a security > threat. I just thought of a bad thing. If you allowed the counters to be zero'd (or advanced) at securelevel == 3, then a 'malicious user' could write a cronjob to continually reset them and cause a DoS attack on the system (or in the case of advance, reset them to ridiculously high values), thus filling up the disk. However, one could argue that *IF* they have root, they could just as easily fill the disk with garbage and cause the same attack, ie; # dd if=/dev/zero of=/var/log/misc > The discussion should simply be about that. Not all this garbage > about adding new features. There's a feature that does not seem > to impact security, secure level disallows it, why? I'm not convinced there aren't other security implications from zero'ing (or advancing) the counters. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposal for new syscall to close files
> Peter Jeremy writes: > > > If it ever gets > > >committed (I don't think it's particularly useful myself), > > That's 2 against, 1 (me) for. > > Three against. 4 against. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > How do you figure? Currently, the kernel will quit 'logging' denied > > packets when the counter reaches a specific (compiled-in) number. > ^ > Then what is > > net.inet.ip.fw.verbose_limit: 0 Well I'll be. You learn something new everyday. :) > made for and why does it help changing it? 8-) Ahh. However, unfortunately, this 'limit' changes *all* of the per-rule counters, when in fact you may only want to change a single counter. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > If you have someone going berzerk as "root" on a firewall you're definitely > going to have a completely different set of headaches. Why should someone > start DoS attacks after capturing a firewall? It's like painting the > fingernails before amputating the hand. So it was a bad example. If I had enough brain cells to boil a cup of water for my soup I'd be able to come up with more 'viable' issues where modifying the counters is a bad thing. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > One could argue that accounting numbers in a firewall shouldn't be > > > > trusted, but I won't argue that point since the firewall is often the > > > > most 'natural' place to stick network accounting software. > > > > > > If you can't trust something in the kernel, then you just can't trust > > > anything at all. > > > > It isn't the kernel that's zero'ing the counters. :) > > Accounting numbers in a kernel firewall _should_ be trustable, and on that > basis, one can clearly make an argument for separating the logging count > from the accounting count - which should never be zero'ed, at least in > securemode. One could argue that 'logging counters' in a firewall _should_ be trustable as well. You've argued against it, but I'm not convinced that your opinion (or mine) is enough to consider it a 'bug'. > I'm not saying your desire for per-rule counters is invalid, I'm just not > of that same mindset. But it does seem clear that it would be useful to > have a mechanism to restart the logging after an IPFW_VERBOSE_LIMIT > throttle. It would be useful. But, is it's usefulness more important than being able to rely on 'logging counters' being valid? (You argue no, but I'm not convinced...) Again, it's not a fix, it's a feature. Not being able to mess with counters (logging or otherwise) is a feature. It may be a feature that you can do without, but that decision is not to be made lightly. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > I like the ability at secure level 3 to only reset the counters forward.. > > > It fits in with such things as the "append only" flag. > > > > Then we'd have to implement per-rule counters that default to > > IPFW_VERBOSE_LIMIT but that could be changed to anything. That's a very > > different setup than what we currently have. > > > > (Another thing I just thought of is that this could cause DoS attacks on > > the system if a user compromised root and then set the limit to a very > > high number.) > > This is already possible via sysctl, the VERBOSE_LIMIT variable may be > altered. Can this be altered in securelevel==3? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > Again, it's not a fix, it's a feature. Not being able to mess with > > counters (logging or otherwise) is a feature. It may be a feature that > > you can do without, but that decision is not to be made lightly. > > I'm _saying_ to create a completely separate counter which has nothing to > do with accounting. See above. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > Again, it's not a fix, it's a feature. Not being able to mess with > > > > counters (logging or otherwise) is a feature. It may be a feature that > > > > > > you can do without, but that decision is not to be made lightly. > > > > > > I'm _saying_ to create a completely separate counter which has nothing to > > > do with accounting. > > > > See above. > > I did see above. If the sole purpose of a counter is to turn _off_ a > feature to prevent DoS attacks, and it is clearly desirable that the > admin (or a representative entity such as a monitoring system) would > want to be able to re-enable the logging under those same terms at some > admin-specified interval, how exactly would you choose to implement this? What was originally intended and what it's used for now are two different things. I'd like to see people other than you, I, and Matt discussing this. Other people who use this feature of IPFW that have an opinion one way or the other should speak up. A group of two very opinionated people doesn't make a consensus, or necessarily the 'right' decision. :) :) :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> If it will get ALL of you to give it a rest, how about: > per-rule logging limits > logging limit raising > logging limit resetting > Which would all NOT affect the statistics? We need more input from people who use the code, to make sure they don't depend on the current 'features', or can live with changes to them. Implementing it is the easy part, making sure it's the right thing to do is the hard part. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> And then ... securelevel == 3 I think it is better NOT to permit > 'sysctl -w', 'ipfw *' AND a logging limmit, just process the logfile > faster to avoid DoS The real issue we are dealing with is what happens at securelevel == 3. What you are saying is that people shouldn't be allowed to modify *anything* at securelevel == 3, correct? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > Implementing it is the easy part, making sure it's the right thing to do > > is the hard part. > > Well, the easy part is done, except for raising limits. Look: > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > ipfw: Entry 1 logging count reset. > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > ipfw: limit 2 reached on rule #1 > > Nice? :) Depends on how it effects the speed of the system and if it makes the code too complex. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > Implementing it is the easy part, making sure it's the right thing to do > > > > is the hard part. > > > > > > Well, the easy part is done, except for raising limits. Look: > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > ipfw: Entry 1 logging count reset. > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: 1 Deny ICMP:8.0 127.0.0.1 127.0.0.1 out via lo0 > > > ipfw: limit 2 reached on rule #1 > > > > > > Nice? :) > > > > Depends on how it effects the speed of the system and if it makes the > > code too complex. :) > > None and no. Beauty is in the eye of the beholder. Let's suspend judgement on it until we actually get a chance to review it, pride in your work not withstanding. :) :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> Index: src/sys/netinet/ip_fw.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
> retrieving revision 1.114
> diff -u -r1.114 ip_fw.c
> --- ip_fw.c 1999/06/19 18:43:28 1.114
> +++ ip_fw.c 1999/07/28 06:29:07
> @@ -106,6 +106,7 @@
> static int add_entry __P((struct ip_fw_head *chainptr, struct ip_fw
> *frwl));
> static int del_entry __P((struct ip_fw_head *chainptr, u_short number));
> static int zero_entry __P((struct ip_fw *));
> +static int resetlog_entry __P((struct ip_fw *));
> static int check_ipfw_struct __P((struct ip_fw *m));
> static __inline int
> iface_match __P((struct ifnet *ifp, union ip_fw_if *ifu,
> @@ -184,8 +185,8 @@
>
> /* check for matching type in the bitmap */
> if (type < IP_FW_ICMPTYPES_MAX &&
> - (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * 8)] &
> - (1U << (type % (8 * sizeof(unsigned))
> + (f->fw_uar.fw_icmptypes[type / (sizeof(unsigned) * NBBY)] &
> + (1U << (type % (sizeof(unsigned) * NBBY)
> return(1);
>
> return(0); /* no match */
These are good bugfixes, and should be committed seperately.
> @@ -302,14 +303,15 @@
> struct ifnet *rif, struct ifnet *oif)
> {
> if (ip) {
> + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl);
> static u_int64_t counter;
> - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+
> ip->ip_hl);
> - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+
> ip->ip_hl);
> - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip +
> ip->ip_hl);
> - int count;
> + u_int64_t count;
These are mostly change for changes sake, and make it difficult to see
the functional changes. Please limit your changes to changes, and not
just to add stylistic differences. While I may agree with them, they
detract from the review process.
[ Rest deleted ]
Can you resend them to me in private email after you remove the
white-space/stylistic changes? Thanks!
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > @@ -302,14 +303,15 @@
> > > struct ifnet *rif, struct ifnet *oif)
> > > {
> > > if (ip) {
> > > + struct tcphdr *const tcp = (struct tcphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct udphdr *const udp = (struct udphdr *)((u_int32_t *)ip+ip->ip_hl);
> > > + struct icmp *const icmp = (struct icmp *)((u_int32_t *)ip+ip->ip_hl);
> > > static u_int64_t counter;
> > > - struct tcphdr *const tcp = (struct tcphdr *) ((u_int32_t *) ip+
> > > ip->ip_hl);
> > > - struct udphdr *const udp = (struct udphdr *) ((u_int32_t *) ip+
> > > ip->ip_hl);
> > > - struct icmp *const icmp = (struct icmp *) ((u_int32_t *) ip +
> > > ip->ip_hl);
> > > - int count;
> > > + u_int64_t count;
> >
> > These are mostly change for changes sake, and make it difficult to see
> > the functional changes. Please limit your changes to changes, and not
> > just to add stylistic differences. While I may agree with them, they
> > detract from the review process.
>
> These were changes that were necessary to make ipfw readable enough that
> I could work with it in this area. They aren't just to clean it up, or
> just for change's sake. They need to stay in.
C'mon now, re-ording the lines is *certainly* not necessary to work.
*rant on*
Brian, FreeBSD isn't your private playground for playing around, this is
a group project, and you gotta follow the rules, or you don't get to
play with the rest of the folks
*rant off*
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > These were changes that were necessary to make ipfw readable enough that > > > I could work with it in this area. They aren't just to clean it up, or > > > just for change's sake. They need to stay in. > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > That's true. I sure didn't do that. Sure looks like you did. There are white-space and re-ordering modifications in the diffs you sent out. If you didn't do them, who did? > > *rant on* > > Brian, FreeBSD isn't your private playground for playing around, this is > > a group project, and you gotta follow the rules, or you don't get to > > play with the rest of the folks > > The rules don't say "leave the code that you work with in a bigger mess than > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > done to get work done, very often. You have to learn to deal with that. No, cleanups occur *separately* from code additions. The code is *very* readable now, and just because you have stylistic differences doesn't mean you get to change them because you like them. In particular, the changes I pointed out are not 'cleanups', but style changes. I repeat, this isn't your personal playground. Play by the rules or don't play at all. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > *rant on* > > > Brian, FreeBSD isn't your private playground for playing around, this is > > > a group project, and you gotta follow the rules, or you don't get to > > > play with the rest of the folks > > > > The rules don't say "leave the code that you work with in a bigger mess than > > when you started." Cleaning up code is a fact of life, and it _NEEDS_ to be > > done to get work done, very often. You have to learn to deal with that. > > > > > *rant off* > > and so it should remain, changes that provide readability to > code should be committed, the only time documentation of code > is wrong is when it it is incorrect. The changes pointed out do *NOT* make the code more readable. They just move statements around for no reason, and change whitespace. > Increasing the size of the cvs repo is not a consideration when > worthwhile docs can be incorperated, especially when the person > who needs to maintain it requires changess for readability. Brian is *NOT* the maintainer, he is the author of a patch to it. Doesn't anyone care for keeping the source code consistant *AND* maintainable for multiple people, as well as maintaining a history of *CHANGES* for people to review in the future? Or is this Linux, where we don't give a rip and whatever the current patch does to the rest of the tree is fine, since the more code we have the better? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > > These were changes that were necessary to make ipfw readable enough > > > > > that > > > > > I could work with it in this area. They aren't just to clean it up, or > > > > > just for change's sake. They need to stay in. > > > > > > > > C'mon now, re-ording the lines is *certainly* not necessary to work. > > > > > > That's true. I sure didn't do that. > > > > Sure looks like you did. There are white-space and re-ordering > > modifications in the diffs you sent out. If you didn't do them, who > > did? > > I refuse to justify putting variables in a function I changed in the > right place. This and other obnoxious responses to valid responses makes me want to ask for your commit privileges. You obviously don't care what anyone else has done. > > In particular, the changes I pointed out are not 'cleanups', but style > > changes. > > When you make code readable, it's a cleanup. The code is *NO* more readable by you re-ordering lines and changes whitespace. Grow up and quit acting like a child who doesn't wanna follow the rules. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: securelevel and ipfw zero
> > > > In particular, the changes I pointed out are not 'cleanups', but style > > > > changes. > > > > > > When you make code readable, it's a cleanup. > > > > The code is *NO* more readable by you re-ordering lines and changes > > whitespace. > > This is so very objective. That's why it considered a 'stylistic' change, and not a functional change. And, that's why stylistic changes are not allowed to be mixed with functional changes. I quote from a recent article involving Brian early last week. -- From: "Jordan K. Hubbard" Subject: Re: cvs commit: src/usr.sbin/inetd builtins.c Date: Fri, 23 Jul 1999 19:25:26 -0700 > > I realize that stack space is not really an issue. Do you think I care > > about the possible savings of a few bytes? The issue is that variables > > should be declared _in_the_proper_places_, so that's where they go in > > my code. And yes, this is my code. I didn't appreciate Sheldon "restyling" > > it, because that makes it harder for /me/ to maintain. > > Having your own private coding style is arguably OK; using it > in other's code is definitely not. Please stick to the coding style > of the module you are editing. Actually, I hadn't even considered that point but Mark's entirely correct. You don't get to pick your own style in the middle of code that someone else has written, you stick to the SAME style even if it's totally style(9) non-conformant and icky in the extreme. -- You don't get to change styles even if it's non-conformant. > > Grow up and quit acting like a child who doesn't wanna follow the rules. > > quit acting like and old fart that fears change. (*) Fears change? Not quite. I was willing to write the necessary changes myself if necessary (see previous email on this thread), but I wanted to make sure it was both desirable (beyond one's person POV), as well as it wouldn't negatively effect other users of the system. > afaik, Brian is the mainter of ipfw, it should be noted so, so that > if his changes break something it comes down on his head. Trust > me to say something if that occurs. Brian is *NOT* the maintainer of IPFW, and thinking that is silliness. If you think that, then you're confused. Being the last person to commit something doesn't make you the committer, and even more so committing one change to the code doesn't make you the committer. I've committed two things to it, so I win by default in that case. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: So, back on the topic of enabling bpf in GENERIC...
> This is a clear security vs functionality issue and I need to get a > good feel for which "cause" is ascendent here in knowing which way to > jump on the matter. Can we now hear the closing arguments from the > pro and con folks? I thought we decided that the networking gurus we're going to make it possible to send out broadcast packets on an unconfigured interface so that DHCP would work, so that bpf wasn't required. I thought that was the over-riding reason for adding bpf to the kernel. Otherwise, BPF is mostly (completely) un-necessary for general purpose computing machines. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Please support FreeBSD 3.x as host OS]
[ VMWare ] > what's needed is customer presence. If people could send me an email address where I could send and state my interest in a VMWare port for FreeBSD (I would of course pay for a copy of VMWare if it existed), I'll do it. The stuff on the WWW page is too 'generic', and I'd rather get it in the hands of someone who will do something about it. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> > ---Steve Tarkalson said: > > > this is solved by one of two methods: > > >1-) require the caller of gethostbyaddr() to supply a pointer to > > >a hostent struct which will be filled. > > > or 2-) the library uses thread specific storage which is re-used in > > >each call. > > > > > You could malloc() a struct hostent for each call to > > gethostby*(), each time registering the hostent in some list along with the > > thread's PID. If the same thread calls gethostby*, use the same buffer, or > > allocate a new one if another thread calls it. Have a static function be > > called > > atexit to free all the mallocs. > > Yuk! > > If you're writing a multithreaded program, a slightly different API for > gethostbyname() is likely to be the least of your worries. Agreed. gethostbyname_r() on solaris requires the caller to provide the address to write into, which is IMO the correct solution. Yes, it's a different API. But, the other alternatives are worse. The user must be able to control his memory allocation. For example, in a typical networking application, gethostbyname() could be called thousands or millions of times, and allocating memory everytime that can't be cleaned up until the program exits is completely unacceptable. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: libcompat proposition
> : There > : is simply no reason to assume that anything under a gnu directory is GPLd, > : or that anything GPLd is going to be under a gnu directory (which it's not.) > > I'm afraid there is. It has been stated many times in the past that > all GPL'd software resides under gnu. This is true in the big > (/usr/src/gnu) and in the small (src/sys/gnu). The gnu directory name > is magic in the minds of many people, and has been for a long time in > the FreeBSD project. While much of the actual software lives in > /usr/contrib, those parts that are under GPL are still built in > gnu/ It is confusing, despite your assertions to the contrary. > That's just how FreeBSD has operated for as long as I can recall, > certainly back to the 1.0 time frame. This decision was made before *any* releases were made, and should continue. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > Both struct timespec and struct timeval are major mistakes, they > > make arithmetic on timestamps an expensive operation. Timestamps > > should be stored as integers using an fix-point notations, for > > instance 64bits with 32bit fractional seconds (the NTP timestamp), > > or in the future 128/48. ... > > > Extending from 64 to 128bits would be a cheap shift and increased > > precision and range could go hand in hand. > > I doubt we need more than 64 bit times. 2^63 seconds works out to > 292,279,025,208 years, or 292 (american) billion years. I think Poul's point is that in the future seconds is probably way too coarse grained. Computer's are getting faster all the time, and in the future we may need 64 seconds, plus an additional 64 bits for the fractions of a second, which will be necessary for accurate timekeeping. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > Matt doesn't represent the FreeBSD project, and even if he rewrites > > the VFS subsystem so he can understand it, his rewrite would face > > considerable resistance on its way into FreeBSD. I don't think > > there is reason to rewrite it, but there certainly are areas > > that need fixing. > > You are misinformed as far as I know.. From discussions I saw, th > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > Kirk's right-hand-man. Which discussions are these? Are they archived somewhere? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
> implemented at least up to 3.2-stable. How could one ensure that their > threads in an application can be "equally" distributed to all the > processors in FreeBSD? You can't. > Are there any documents on FreeBSD 3.*'s thread > support(both kernel and user level)? FreeBSD has no kernel 'thread' support, only user level. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: pthread_set_concurrency()
> > FreeBSD has no kernel 'thread' support, only user level. > > That's not strictly true. The fact is we have both kernel and user > threads but no mapping between the two... The kernel already > internally use some threads. Your definition of kernel threads and mine are obviously quite different. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: select/poll implementation
> I had always wondered how select/poll worked (actually see the end of the > mail to see the broader question), so I pulled up select() and family > and started reading and chasing stuff around. I think that I fully > understand (much praise to whoever wrote most of that, it was incredibly > easy to read) everything from sys_generic.c. Sean Fagan walked me through the code a couple of years ago, and after our discussion he decided to submit this to Dr. Dobbs. The article should be available in their archives somewhere to explain these things in some detail, and should answer the questions you have. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD XFS Port & BSD VFS Rewrite
> > Matt doesn't represent the FreeBSD project, and even if he rewrites > > the VFS subsystem so he can understand it, his rewrite would face > > considerable resistance on its way into FreeBSD. I don't think > > there is reason to rewrite it, but there certainly are areas > > that need fixing. > > You are misinformed as far as I know.. From discussions I saw, th > main architect of a VFS rewrite would be Kirk, and Matt would be acting as > Kirk's right-hand-man. Which discussions are these? Are they archived somewhere? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> > [...] > > 2. value ) instead of value) for case statements > > [...] > >case $? in > > - 0) > > + 0 ) > >;; > > - 2) > > + 2 ) > >exit 1 > >;; > > - 4) > > + 4 ) > >reboot > >echo "reboot failed... help!" > >exit 1 > >;; > > [...] > > Why?!? I like the existing "case" style _much_ better, > it's more readable and emphasizes the structure. And it is more conformant to 'style(9)', which says that the case statements line up with the switch statement. (Although that's for C code, in this case I believe the sh code can be compliant indirectly...) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
[ I'm nit-picking here, feel free to ignore ] > Doug--- /usr/src/etc/rc Thu Aug 26 20:56:36 1999 > +++ rcFri Aug 27 09:52:39 1999 > @@ -8,24 +8,25 @@ > # and the console is the controlling terminal. > > # Note that almost all the user-configurable behavior is no longer in > -# this file, but rather in /etc/defaults/rc.conf. Please check this file > +# this file, but rather in /etc/defaults/rc.conf. Please check that file > # first before contemplating any changes here. > Sentences are supposed to have two spaces before you start the next sentence. Thanks for doing this! Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: StarOffice giveaway of source code
> > I have the feeling that "Software Licensing Program" speaks . > > You can read about the Sun Community Source License on their web site now. > It is the same license that brings the JDK to FreeBSD. *NOT* As we read it (The JDK folks), the CSL doesn't allow us to release the JDK on FreeBSD, so we signed a different license (the one from JDK1) that allows us to re-distribute binaries on the WWW. Besides, the CSL didn't come into play until JDK2, and we don't (yet) have a JDK2 for FreeBSD. :( Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CFD: "bogomips" CPU performance metric
> There was such a thing in 386BSD and FreeBSD1.0 I remember no such thing doing a 'bogomips' to compare against Linux. Certainly not in 386BSD. Nate > > I certainly thing it was a worth-while thing. > I'd try make the loop as similar to the Linux one so that they are > comparable. > > On Thu, 2 Sep 1999, Nick Sayer wrote: > > > Linux generates a meric of CPU performance as a byproduct of calibrating > > a delay loop. > > We don't require doing any such thing, and so adding it would be purely > > cosmetic. > > However, I allege that cosmetic things aren't in and of themselves evil, > > so long as > > they don't break anything in the process. > > > > I would like to generate a number that will hopefully be reasonably > > compatible with > > the one Linux spits out. The best method I have come up with is to have > > a similar > > (the same?) count down loop in assembler. Have it count down from > > 1,000,000 and > > see how much nanotime() has gone by. NANSPERSEC/nansused = bogomips. > > A 1 bogomips machine will take an extra second to do this (anything > > likely to be > > even able to run FreeBSD should exceed 1 BM - yes, ha ha), and a kBM CPU > > > > can do it in 1 ms. Perhaps in the future a prescaler might be required, > > but > > this whole thing is just really chrome anyway. > > > > Would anyone scream and projectile-vomit if I added this to identcpu.c? > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> : I'd really like to see the sio driver code being able to support PCI > : devices... > > Might be a good time have a sys/dev/sio and have pccard, cardbus, pci > and isa attachments there. Yes, I did say cardbus, since I have seen > cardbus PCI modems that are NOT winmodems. But, they should be PCI/non-Winmodem, as Kevin pointed out, so we shouldn't need cardbus seperately from pci. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> "Matthew N. Dodd" wrote: > > On Sun, 5 Sep 1999, Warner Losh wrote: > > > Might be a good time have a sys/dev/sio and have pccard, cardbus, pci > > > and isa attachments there. Yes, I did say cardbus, since I have seen > > > cardbus PCI modems that are NOT winmodems. > > > > And MCA and EISA attachments. > > Well, it seems Bruce objects to this.. I don't know why though. My guess is that he's worried that we'll end up with lots of additional 'indirection' through the system, thus slowing down the ability to service interrupts in a quick manner. Also, don't fast interrupts depend on the ISA bus? Fast interrupts are a requirement for *any* machine to run at a reasonable speed, old/slow or new/fast, it doesn't make any difference. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> : But, they should be PCI/non-Winmodem, as Kevin pointed out, so we > : shouldn't need cardbus seperately from pci. > > Just the attachment... Ahh, OK. I'm not familiar enough with the new code to know how exactly it's organized. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> > 3. Needlessly cross-posted (watch your cc lines, loser! :). > > On a different topic, does anyone know of a good X mailer > (currently I am using exmh) : > > 1. user friendly > 2. filtering capability > 3. thread topic support XEmacs + VM works very well for me, but Emacsen have a fairly large footprint. Then again, anything implemented in X is fairly large, so it's no worse than most other X applications, and it's highly configurable, as with all things in emacs. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
> Nate: it's a while since I looked at VM on XEmacs. I found its > layout cluttered and it's key sequences awkward. How configurable > is it, really? Do you use it as it comes out of the box? Really configurable, and no, I don't use it in an out-of-the-box configuration. I remap many of the keybindings, as well as have it setup to deal with procmail filtered email, which works very well. For more information, talk to me offline. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
> Just to toss in my 0.02 cents, I've been using exmh for a while and > am on one hand very satisfied with it, on the other hand it's handling > of mime and html is not good, so I'd be very interested in discussing > this topic too. VM doesn't do HTML/MIME very well, although I understand in later versions of XEmacs they've incorporated some packages that handle things better. (I'm still using XEmacs 19.16, from the dark ages...) Mime handling works, but is clumsy, and HTML is almost non-existent. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> > > I strongly disagree. Spitting "unresolved references" is *not* a way to > > > tell the user that he doesn't have the right libraries. > > > > I strongly disagree. This is much better than version bump. After all, > > we can add suggestion to upgrade libraries to the "unresolved references" > > message. For what it's worth, I agree with Marcel. Version bumps should be discouraged, but not totally avoided. Carrying around old libraries with older version numbers is *hardly* a burden for the users, and those folks who are running old versions of FreeBSD will not be effected at all since they will continue to keep the old libraries around. I say a version bump is the better solution, since the linker will 'Do The Right Thing'. Yes, we shouldn't version bump every time someone has a whim, ending up with 10 version bumps/week, but neither should we avoid them altogether and cause the Linux syndrome of programs refusing to work because they have the *wrong* version of glibc2.3 (or whatever) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> > > Yes, we shouldn't version bump every time someone has a whim, ending > > > up with 10 version bumps/week, but neither should we avoid them > > > altogether and cause the Linux syndrome of programs refusing to work > > > because they have the *wrong* version of glibc2.3 (or whatever) > > > > This is starting to sound like what would help is tighter release > > management. If changes were held back long enough for a single version > > bump to cover multiple changes, the situation would be improved. > > I'm more tempted to revert to the major/minor versioning. ELF has no minor revision number (IMO a mistake, but it's not my call). Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> > For what it's worth, I agree with Marcel. Version bumps should be > > discouraged, but not totally avoided. > > What is the reason to not avoid the version bump? Because if you don't have the latest/greatest library (old machines), newer programs that are compiled against the latest/greatest will refuse to work, even though the user is using the correct 'version' of the library. As Marcel pointed out, the violates POLA. If you are running the wrong version of the library, the system should complain about it. Version bumps aren't the spawn of the devil, but they should be avoided else we end up with libc.so.234456, like in NetBSD. :( > > Carrying around old libraries > > with older version numbers is *hardly* a burden for the users, and those > > folks who are running old versions of FreeBSD will not be effected at > > all since they will continue to keep the old libraries around. > > Version bumps are problem for vendors and users of binary-only > products (vendors usually request users to install old libraries), Why is this a problem? It's the *exact* same problem as faced above, except that there is no indication there is a problem because the version number is correct. > users of obsolete versions of FreeBSD (who cannot get a binary linked > with their libc, and has no chances to make them running) Specious argument. FreeBSD has *always* provided backward compatability libraries. We've still got compatability libraries from FreeBSD 1. > and people > who maintain a lot of FreeBSD boxes running different versions of > FreeBSD, who will have to build their own binaries several times. They'll have to do this anyway, unless they build it on the 'oldest' box available, at which point the binary will work on all of the newer boxes anyway because of the compatability libraries. > I hate old libraries because they are binary-only programs without a > maintainer. Old libraries are difficult if not impossible to fix or > improve. For (quite benign) example, look at PR bin/13623. Old binaries are binary-only programs w/out a maintainer as well. This is just pure silliness. If you want a 'fix', then rebuild/relink your application. This is trivial to do. > It goes without saying that changes in existing interfaces must include > a version bump. Conclusion: don't change any existing interface. Wrong, then the kernel and/or source ends up being so bloated with 'old interfaces' for *NO GOOD REASON* that the software becomes un-maintainable. Forward progress means that sometimes you change existing interfaces when the pain in doing so is so small to be inconsequential, which is the case with shlibs. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for Ope
> > VM doesn't do HTML/MIME very well, although I understand in later > > versions of XEmacs they've incorporated some packages that handle things > > better. (I'm still using XEmacs 19.16, from the dark ages...) > > Does it do IMAP? It doesn't even do POP, I use fetchmail/procmailrc to get my email, which works *MUCH* better than anything else I've found. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: A Challenge
> The box is just going to be running NATD and IPFW, maybe DHCLIENT. > > Mr. NT is been told he can try and break-in, crash what ever this box > from the internet side. > > I am asking for links, pointer to make sure this is configured as > secure/solid as possible. I will be installing 3.3-STABLE over this > weekend (9/11/1999). I really want to make sure we win. Turn off inetd on the computer, since you have no need for external services. In any case, if you install a recent version of FreeBSD, I doubt Mr. NT is capable of crashing FreeBSD from externally. Just make sure he doesn't have an account on it, since it's much easier to cause Denial Of Service attacks if you don't spend alot of time setting up limits and such. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How can I send signals to a network interface
> > I know that in some other Bsd flavours you can use the sysctl functions = > > which is part > > of the ifnet struct. In FreeBsd I didn't find anything similiar to it. > > Sysctl functions aren't "part of the ifnet struct". You can define > sysctls for your driver, if you wish, but that's the wrong way to go > about doing it. Especially since sysctl's are still not yet able to deal with multiple interfaces very easily. (Feel free to correct me if I'm wrong). Therefore, if you have two 'network interfaces' that are serviced by the same driver, it's hard to not have a sysctl change effect them both. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: dlopen failure
> - > and here's the ld line for the shared object I am loading; > > ld -Bshareable -o $@ $< -u _floor ../../lib/libV.a > /usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a This is probably unrelated to the bug (but it might be related). Are the object files libV.a and libmsqlclient.a compiled -fPIC? I know libm.a isn't, so the library work as a shared library. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ifconfig: changing mac address
> Is it possible to change the mac address of an ethernet card using > ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Seti project / stats reset, new version available
> For people who have idle cpu to spare, this is a good time to start > putting those cycles to good use with the Seti project! Where would would find informatio on said project? Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: GPS receivers for xntpd (off-topic)
> : [ gps talk ] > :... > > I've been very impressed with the newer ( last 5 months ) Garmin > handhelds. The older ones only had 8 channel receivers. The newer > ones have 12 channel receivers sensitive enough that the units often > work indoors. FWIW, the Garmin 12XL is a *very* nice unit. I've used it for almost 2 years now (work related), and have nothing but high-praise to speak about it. The Garmin 12 is also nice, but does not allow for an external antenna. (We use them for clock synchronization at a macro-level of +-1sec, which is adequate for our applications.) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Matt's Commit status (was Re: 3.2-stable, panic #12)
[ Some history: I'm not a core member (I gave that up responsibility years ago), but I was one of the three weirdo's that started up FreeBSD back when I had no life. My opinions are my own, and don't reflect the core team. I don't know the exact reasons why the core team removed Matt's commit priv's, but I can make some good guesses. Regardless, I felt this posting needed to be sent, especially since many folks in the 'peanut gallery' such as myself have followed up with their opinions. For what it's worth, I often-times I often reflect the same kind of development style I'm seeing in Matt, so take it for what it's worth. (The things that most annoy you are often the same as your own behavior.) ] Matthew Dillon writes: > I have to say, though, that in order to fix these bugs I really do > need my commit privs back. If people want these things fixed, > complain to core. I have the time to fix the bugs with commit > privs, but I just don't have the time or inclination to fix them > without. What's wrong with the current 'review' scheme? > It is just too much stress > keeping a patch that should be committed in a day or two on the table for > two weeks and then have to beg people to deal with it. Umm, all patches should be reviewed by someone even if you have commit privileges. Getting commit privileges won't speed up your commits anymore than they do today, since reviews should still be occurring. > I am getting > wholely sick and tired of it, and I have better things to do then try > to maintain a pipeline of fixes that constantly get stopped up. See above. > I *want* to fix these and other bugs, but I am effectively being > prevented from doing so because some core members freak out over > the speed at which I program and the amount of rewriting I > sometimes do. The problem I had with you was your inability to work with others, and your constant riding roughshod over other people's work and code w/out fulling understanding (or caring to understand) the reasons for the design decisions. You were attempting to make 'FreeBSD' into 'MattBSD' from my point of view. Case in point, John Dyson's comments explanation to the mailing list for many of his design decisions explained to even an uninformed person like me that some of the changes you've made were penalizing FreeBSD, not helping it in some cases. > I will point out that all the rewriting I've done so far has been ^^^ I'd call it 'much', since 'some' if it was wrong and hid existing bugs and/or introduced instabilities. Some bugs are to be expected, but IMO some of the 'cleanups' were ill-conceived and have done very little to add stability or reliability to the system. (In particular, some of the casting bugs were downright wrong, and Bruce went through and cleaned up a number of them after the fact.) > to the ultimate benefit of the project in hind sight, resulting in > better commented, cleaner, and more reliable code and catching > more bugs. 'Most' of what you have done is good stuff, but unfortunately from my point of view, you aren unable to accept the fact that 'some' of what you are doing is not helpful and/or wanted, and it's an all-or-nothing situation. This is not conducive to a group project, nor to the long term success of FreeBSD. Yes, NFS is *MUCH* better than it was before. Yes, many bugs have been fixed. But, in the process of this you made alot of people angry due to your behavior and unflexible development style. While this might be acceptable if you have no peers, in a group of peers this doesn't work. No-one likes a lone-ranger who no-one else can work with, and that is the kind of impression that your behavior left in my mind. And, this isn't the kind of behavior that will benefit FreeBSD IMO. Again, these are my *opinions*, based on my observations that took place during his 'commit' status. I have a personal desire to see FreeBSD succeed I consider it partly 'my baby' given my long history with it. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
[ None of the below is assumed to be taken as reflecting any situation that occurred in FreeBSD. This is a *common* problem that exists in every software program, and any reflection on what happened in FreeBSD is by coincedence in that it's a software program. My comments apply as easily to my situation with the laptop support changes I made as it done to *any* other portion of the system. ] > The biggest mistake that programmers working on a large project make is > when they do *not* rewrite portions of the code that need to be > rewritten. Most good software engineering books would disagree with you. The *BIGGEST* mistake the most programmers make is re-writing functional code to conform to their style of programming, rather than understand why the original programmers did it the way they did it. NIH is *FAR* too common of a problem. Bugs *rarely* require a complete re-write of the code. This isn't to say that often-times it's *easier* to just re-write it from scratch than it is to understand what the original code was doing in the first place, but this often leads to errors that were fixed by the original authors in a non-obvious manner being brought back in. The above problem is almost always a problem with the original author not doing a proper job of documenting the work, but it doesn't justify ripping everything out and starting over from scratch. I know of *NO* programmer who does not delight in completely ripping out and replacing existing code with code that he has written from scratch. It's great fun, and it allows the person to feel better about the system, themselves, and make sure that they can debug the existing code better. I do it all the time. But, I know for a fact that it's rarely the right thing to do, especially when the folks who 'went before me' aren't 1st year CS students, but are seasoned professionals who have a clue and didn't do things on a whim. Almost *ALL* of the BSD kernel code (and most of the userland code as well) falls into the class of code that is written by seasoned professionals. They are not infallible, but they almost always have a reason for why they did things the way they did. Does it mean you should never re-write entire portions of code? Of course not, but it should never be taken lightly, and *IF* the original programmers are there and willing (and capable) to explain things to you, then that should be taken advantage of, and not ignored. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-stable, panic #12
> | I know of *NO* programmer who does not delight in completely ripping out > | and replacing existing code with code that he has written from scratch. > | It's great fun, and it allows the person to feel better about the > | system, themselves, and make sure that they can debug the existing code > | better. I do it all the time. But, I know for a fact that it's rarely > > I guess you don't really know me. I've always taken great pleasure in > fixing other peoples code. Does that mean you *don't* like writing your own code from scratch? I never said that people don't *also* enjoy figuring out other people's code, but it's often *much* less fun when you are the person responsible for maintaining it long-term. > I also like code without coments, it forces me to understand the actual > written code and derive the concept from it vs. assuming the concept that > has been described. Comments for me are to describe "black magic" ie. > bizare side-effect/hardware bugs. *Ewww* You *are* a special guy, aren't you. *grin* I need comments in my own code because I look at so much code nowadays that I forgot even why *I* did things at a later point. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
> > > We're adding some machines at work for (essentially) cgi > > > processing only. It was never considered to use anything less than 2 cpu > > > boxes, and the current round of testing is going so well that we're > > > seriously considering 4 cpu boxes because they are not that much more > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > In short, increasing SMP efficiency should really be a priority > > > for N>2 systems. > > > > Agreed. But this is a BIG job, because to do that you have to solve the > > "one big kernel lock" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. In my neck of the woods (doing lots of multi-threaded stuff), that is the definition of 'fine-grained' locks, vs. 'coarse-grained' locks. What we have now is a big 'coarse-grained' lock. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
[ Trimmed CC list a bit ] > > :* even if you are not willing to pay that price, there _are_ people > > :who are quite willing to pay that price to get the benefits that they > > :see (whether it's a matter of perception or not, from their > > :perspective they may as well be real) of such a scheme. > > > > Quite true. In the embedded world we preallocate memory and shape > > the programs to what is available in the system. But if we run out > > of memory we usually panic and reboot - because the code is designed > > to NOT run out of memory and thus running out of memory is a > > catastrophic > > situation. *ACK* This is unacceptable in many 'embedded' systems. > There's a whole spectrum of embedded devices, and applications that > run on them. That definition works for some of them, but definitely > not all. > Totally agreed. A previous poster brought up the fact that *some* embedded systems are built to deal with 'out of memory' situations, and that the 'total' amount of memory used in the system can be used by other parts of the system. For performance reasons, a particular application may choose to 'cache' data, but in low memory situation it can 'free' up alot of memory. You don't want to put hard-coded limits the process simply because if the memory is there you want it to be able to use it, but you *certainly* don't want to go through a reboot just to get memory back. [ And, I don't want to write my own OS to do this for me. :) ] (However, I agree that for general purpose computing, over-commit is the way to go. But, *BSD is not just for general purpose computing, although that is it's primary market.) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
> :> > Quite true. In the embedded world we preallocate memory and shape > :> > the programs to what is available in the system. But if we run out > :> > of memory we usually panic and reboot - because the code is designed > :> > to NOT run out of memory and thus running out of memory is a > catastrophic > :> > situation. > : > :*ACK* This is unacceptable in many 'embedded' systems. > > Don't confuse a watchdog panic from other conditions. If the embedded > system software is supposed to deal with a low-memory condition and can't, > the failsafe is all that's left between it and infinity. > > The statement that the kernel's overcommit methodology somehow prevents > one from being able to build embedded systems on top of it is just plain > incorrect. The embedded system is perfectly capable of implementing its > own memory management to avoid the filesafe provided by the kernel. It is. But, it's not the most effecient/effective way of doing it. Sometimes it's best to let the 'kernel' do the things it does best, and let the users worry about the things they do best. The kernel manages memory alot more effeciently than any userland process can do, so why not let it? > Most of the embedded work I've done -- mainly remote telemetry > units running with flash and a megabyte or so of ram -- panic and > reboot if they run out of memory. Most of the work we've done wouldn't allow this, especially if we were using an OS like FreeBSD with a fairly long bootup time. Especially if it can be avoided. Yes, we could (and did) do our own memory management, but it seems to me that the kernel has alot more information available to it and would do it better than I could. Then again, maybe I'm totally confused about how the VM system 'does its thing', and in reality it's no better at it than our code, just alot more complex for no reason. :) :) :) Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
> :Most of the work we've done wouldn't allow this, especially if we were > :using an OS like FreeBSD with a fairly long bootup time. Especially if > :it can be avoided. > : > :Yes, we could (and did) do our own memory management, but it seems to me > :that the kernel has alot more information available to it and would do > :it better than I could. Then again, maybe I'm totally confused about > :how the VM system 'does its thing', and in reality it's no better at it > :than our code, just alot more complex for no reason. :) :) :) > : > > The kernel just isn't the best place to do this. The level of > sophistication required to satisfy the larger set of programming > is much greater then anything discussed here. The last thing that the > kernel should be doing is returning NULL from malloc() to a program > which is operating within its specifications. You and I disagree on this statement. Returning NULL is completely acceptable, and is the 'specification' for many OS's, including FreeBSD if you set user/process limits. > That doesn't help anyone, least of all the programmer who now has > to deal not only with the complexity of the project he is working > on, but must also deal with the potential that the OS will step in > at any time and give him an error that he must deal with in a > sophisticated fashion even when his software is operating > properly. Returning NULL isn't an error, it's an indication that there is no more memory. Don't think if it as an error, think of it as a hint. General purpose computing tends to make one think that out-of-memory condition is an un-acceptable situation, and the program must exit. FreeBSD exacerbates this by rarely returning NULL and randomly killing off processes which may/may not be involved in the memory fracus. > > The same goes for non-embedded work. Why is it that programs generally > exit when they encounter a memory allocation failure? Because programmer's are lazy. Really, and I do it all the time as well. But, that's because on 'general purpose' computing hardware, re-starting the process or having to wait for a reboot is 'acceptable'. But, to many of my collegues who are running simulations that are running for DAYS and WEEKS, they write code that 'saves the state' of the system when they can't get critical memory, *THEN* abort the application. Yes, it's possible that the process of saving state *may* not work if the system is *really* low on memory, but then again it may work. But, more times than not it *does* (appear) to work, and the work is not lost. > with memory allocation errors" provides no solution. 98% of the source > code in the BSD code base will exit if a memory allocation fails, and > I don't know anyone who wants to go through and somehow "fix" it all > (and one could argue what the "fix" should be when something like grep or > a shell has a memory allocation failure). To require that this code be > made twice as sophisticated as it is already in order to deal with a > non-overcommit model reliably is a fantasy. Who said anything about using the bsd code base in an embedded system? Also, you *can* use limits for that stuff. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
> :Returning NULL isn't an error, it's an indication that there is no more > :memory. Don't think if it as an error, think of it as a hint. > > It's only a hint if it is returned due to the process resource limit > being hit. If it is returned due to the system running out of swap, > it would be an error. Not necessarily. > This creates a dependancy between two completely independant processes > possibly owned two totally unrelated users. This is not acceptable, > and is precisely why this sort of behavior does not occur. In embedded systems, there are no such things as 'independant' processes that are given unlimited access to the system. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
Jason Brazile writes: > > : I want to construct a portable Makefile to build a java application. > > > > That's not possible. Java specifies a half assed make system as part > > of the language, so it is nearly impossible to use another make system > > on top of it unless you are willing to live with a whole slew of > > problems. That's not true. I built a 100K line application using make w/out any problems. (It builds on Win9X, NT, FreeBSD, and Solaris). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: make bug? (dependency names with '$')
> > > > I want to construct a portable Makefile to build a java application. > > > I've played with Java and Make in the past, but I found that spawning a new > instance of the Java compiler is more expensive than compiling a pretty big > bunch of files. gcc starts up a lot quicker than a JVM. Jikes is your friend. We switched from using javac because of this. Nate ps. This should probably be moved to freebsd-java. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
> Jason Brazile <[EMAIL PROTECTED]> writes: > > I want to construct a portable Makefile to build a java application. > > Don't bother. > > a) use jikes instead of javac, it's much faster and gives better > diagnostics. Agreed. > b) to rebuild, just list all the source (.java) files on the jikes > command line. Jikes will figure out what needs rebuilding and what > doesn't. If there are too many files, list them all (each on one > line) in a text file (e.g. 'sources') and specify '@sources' on > the command line. Disagree. If you want it to be portable, don't use a non-standard extension to a tool, such as jikes dependency features. We used jikes for our day-day development, but move back to using 'javac' for our Q/A and final builds. That way we can complain to Sun when things don't work. ;) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
> > Disagree. If you want it to be portable, don't use a non-standard > > extension to a tool, such as jikes dependency features. > > > > We used jikes for our day-day development, but move back to using > > 'javac' for our Q/A and final builds. That way we can complain to Sun > > when things don't work. ;) > > So what's the problem? javac also automatically builds dependencies, > it's just not as good at it as jikes. Not in a way that's usable my make. Jike can be used to build external dependency files. > Also, my experience is that unless you're paying Sun significant > amounts of $$, their reaction to bug reports is to close their eyes, > hum real loud and hope they go away. True, but Sun is no different than anyone else in that regard. I have found the individual developers somewhat more easy to work with, if you can get a contact within Sun. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
[ Memory overcommit ] > One important way to gain confidence that you're little box won't > silently crash at the worst possible time for the customer is to > be able to *prove* to yourself that it can't happen, given certain > assumptions. Those assumptions usually include things like "the > hardware is working properly" (e.g., no ECC errors) and "the compiler > compiled my C code correctly". > > Given these basic assumptions, you go through and check that you've > properly handled every possible case of input (malicious or otherwise) > from the outside world. Part of the "proof" is verifying that you've > checked all of your malloc(3) return values for NULL.. and assuming > that if malloc(3) returns != NULL, then the memory is really there. > > Now, if malloc can return NULL and the memory *not* really be there, ^^^ I assume you meant 'can't' here, right? > there is simply no way to prove that your code is not going to crash. Even in this case, there's no way to prove your code is not going to crash. The kernel has bugs, your software will have bugs (unless you've proved that it doesn't, and doing so on any significant piece of software will probably take longer to do than the amount of time you've spent writing and debugging it). And, what's to say that your correctly working software won't go bad right in the middle of your program running. There is no such thing as 100% fool-proof. > This memory overcommit thing is the only case that I can think of > where this happens, given the basic assumptions of correctly > functioning hardware, etc. That is why it's especially annoying to > (some) people. If you need 99.999% fool-proof, memory-overcommit can be one of the many classes of problems that bite you. However, in embededed systems, most folks design the system with particular software in mind. Therefore, you know ahead of time how much memory should be used, and can plan for how much memory is needed (overcommit or not) in your hardware design. (We're doing this right now in our 3rd generation product at work.) If the amount of memory is unknown (because of changing load conditions, and/or lack-of-experience with newer hardware), then overcommit *can* allow you to actually run 'better' than a non-overcommit system, though it doesn't necessarily give you the same kind of predictability when you 'hit the wall' like a non-overcommit system will do. Our embedded OS doesn't do memory-overcommit, but sometimes I wish it did, because it would give us some things for free. However, *IF* it did, we'd need some sort of mechanism (ie; AIX's SIGDANGER) that memory was getting tight, so the application could start dumping unused memory, or at least have an idea that something bad was happening so it could attempt to cleanup before it got whacked. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
> >Even in this case, there's no way to prove your code is not going to > >crash. > > Sure. But you can at least prove that all crashes are the result of bugs, > not merely design "features". 'Proving' something is correct is left as an excercise for the folks who have way too much time on their hand. At my previous job (SRI), we have folks who work full-time trying to prove algorithms. In general, proving out simple algorithms takes months, when the algorithm itself took 1-2 hours to design and write. Another thing is that crashes may have occurred because of invalid input, invalid output, valid but not expected input, etc... Again, memory overcommit is only *one* class of bugs that is avoided. The phrase "can't see the forest for the trees" jumps to mind. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is mkdir guaranteed to be 'atomic' ??
> >is mkdir(3) guaranteed to be atomic? > > Yes. > > >Are there filesystem type cases where this might not be the case > >(NFS being my main concern ) > > No. Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir call returns, you have no guarantee that the remote directory has been created (caching, errors, etc...) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is mkdir guaranteed to be 'atomic' ??
> > > >Are there filesystem type cases where this might not be the case > > > >(NFS being my main concern ) > > > > > > No. > > > > Yes. NFS doesn't guarantee atomicity, because it can't. If the > mkdir > > call returns, you have no guarantee that the remote directory has > been > > created (caching, errors, etc...) > > I can handle it if there is a case where both fail, but is there a > case where both can SUCCEED ?? What do you mean 'both succeed'? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is mkdir guaranteed to be 'atomic' ??
> > > I can handle it if there is a case where both fail, but is > there a > > > case where both can SUCCEED ?? > > > > What do you mean 'both succeed'? > > My understanding is that, on non-broken filesystems, calls to > mkdir(2) either succeed by creating a new directory, or fail and return > EEXIST (note: excluding all other types of errors :-)) > > However, NFS seems to have issues, so the question is: could both > mkdir(2) calls actually succeed and claim to have created the same > directory (even if it is?), or is one ALWAYS guaranteed to fail, as on > a normal fs. You're implying that you are making two calls to create the same directory. Am I correct? The answer is 'maybe'? Depends on the remote NFS server. Matt or one of the other NFS gurus may know more, but I wouldn't count on *anything* over NFS. If you need atomicity, you need lockd, which isn't implemented on FreeBSD. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
> You cant strong-arm companies into making their intellectual properly > rights publicly available. its a losing argument. Strange, in that it worked for a number of video-card vendors when XFree86 either dropped support and/or never supported the card in question. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -R for make update ?
> > > Is there any specific reason why one needs to be able to > > > write a lock to the CVS repo when running 'make update' > > > to get a freshly checked out source? > > > > Yeah: you aren't running your CVS server in "pserver" > > mode, and so are trying to do a lock, either in your > > local copy, or over NFS. > > > > If you run your repository in pserver mode, the CVS server > > will be connected to over the network, instead of attacking > > your CVS repo directly, and you won't have the problem you > > are seeing, since the cvs server will be able to get the > > lock, no problem. > > It will also be freakishly slow, and use massive amounts of temp > space. No slower than cvs using rsh/ssh, although it does tend to create alot of inodes in /tmp. (It doesn't create alot of temp space, other than what is used to create the directories...) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
> I've had several marketing types approach me recently for details as > to whether or not Microsoft was using the BSD TCP/IP stack and/or user > utilities, and though it's always been "common knowledge" in the > community that they were, when I set about to "prove" it I found it to > be less easy than I'd thought. I've strings'd various binaries and > DLLs in my copy of Windows 98 but have yet to find anything resembling > proof. Does anyone out there have any details or discovery techniques > for confirming or disproving this assertion either way? It would be > very useful (for us) from a PR standpoint to know. I think the nmap folks noticed that the stack in Win98 (I don't remember if it was in Win2K as wll) behaved almost exactly like the BSD stack in ways that weren't mandatory. Their conclusion was that it had to be based on the BSD code to get such similar behavior, since no other stack behaved in this manner. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
> > http://www.microsoft.com/windows2000/interix/interixinc.asp > > Plenty of GNU stuff there, though it doesn't say so explicitly. > > Of course, they say it's all meant only for "legacy Unix" stuff. > > Can you substantiate your claim there is "plenty of GNU stuff" in > Interix, or are you just talking out your ass as usual? That's uncalled for Wes. Interix contains *lots* of GNU code, but to be fair to M$, the company that developed Interix was acquired by M$ long before Linux was as big of a threat to it's business as it is now. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NGPT 1.0.0 port to freebsd
[ It would have been helpful to have a one-line description of what NGPT is at the top of this, rather than requiring the folks to go to a URL. ] > - The main point of this port is to have a reasonable native freebsd > pthread implementation till the scheduler activations stuff is ready. With the current license, this won't be installed as part of the base kernel. (GPL and/or LGPL) > - Java heads: does this help to pass the JCK ? Nope. I suspect we could pass the JCK/TCK today, but we haven't run the tests yet due to legal reasons. > 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. 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). However, there is (and has been) ongoing work with Sun to get something in place. The BSDi->WindRiver acquisition did *NOT* help things, as it forced us to start over from scratch as a number of folks at WindRiver who were aiding the Java team are no longer involved (as they were laid off). 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. Nate 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: Status of encryption hardware support in FreeBSD
> > > > 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. > > > > Your premise that "embedded appliances" are somehow doomed to use pitifully > outdated processors is simply wrong. Who said anything about pitifully outdated processors. I can buy a heck of alot of CPU horsepower w/out buying the latest/greatest CPU. As a matter of fact, in almost all cases, the best bang for the buck would be for processorts that you imply to 'pitfully outdated'. > Embedded MBs with speeds enough to eliminate the requirement for 1) a > slot and 2) an external board are available for less than the delta in > cost. That's simply not true. If you are building 'truly embedded' systems (ie; 100K+ boxes), you're not going to be using 'off the shelf' PC parts. You're going to be specifying particular parts to be used, and in general the difference in cost of $1-5 for the CPU makes a *huge* difference in the price-point you are trying to make. Often times it's easier to build a hierarchy of products, with each individual tier having the same 'basic' setup (keeping costs low), and by adding additional 'special purpose' boards, you can increase the functionality of the box by only increasing the costs trivially. > So, logically speaking, anyone > with a requirement for crypto would simply chose a faster embedded MB > solution. You seem to have a different definition of embedded than many others do Bryan. Have you ever been involved with specifying and building embedded systems products, or are you just talking out of the side of your mouth? Nate 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
> > > Your premise that "embedded appliances" are somehow doomed to use > pitifully > > > > > outdated processors is simply wrong. > > > > Who said anything about pitifully outdated processors. I can buy a heck > > of alot of CPU horsepower w/out buying the latest/greatest CPU. > > > > As a matter of fact, in almost all cases, the best bang for the buck > > would be for processorts that you imply to 'pitfully outdated'. > > I think you've missed the fact that the '486 solution requires an > add-on board (priced at $80.) and the faster cpu solution doesnt. That > adds a lot of margin to get a faster MB, more than enough to > compensate for the board. Not necessarily. The upgraded motherboard also requires a faster processor, and the two parts added together are almost certainly going to be more than $80. In any case, that's just one example. There are many more examples where a PIII-400 is more than adequate to do most of the processing, if you don't have to do encryption. If you involve encryption, we're talking alot more CPU, memory, and such. You can easily get an add-on board for *much* cheaper than to upgrade your memory, mboard, and CPU. Nate 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
> > > I think you've missed the fact that the '486 solution requires an > > > add-on board (priced at $80.) and the faster cpu solution doesnt. That > > > adds a lot of margin to get a faster MB, more than enough to > > > compensate for the board. > > > > Not necessarily. The upgraded motherboard also requires a faster > > processor, and the two parts added together are almost certainly going > > to be more than $80. > > > > There is nothing more annoying than someone who argues subjects he clearly > knows nothing about. I agree. :) > You are way off on your pricing. Way off. A 633 Celeron > is under 50. Q1 for petes sake. The cost difference would be less than $20. > in quantity. It would be less than $80. Q1. That's just CPU. You've left off the motherboard, as well as the memory and other supporting hardware required for the CPU to do the work. > Theres an old saying about being penny-wise and pound foolish. Using a > 486 in todays networking and cost environment is just plain moronic. See your first sentence. You *really* don't know what you are talking about. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF rtld and environment variables...
> Besides, have you even established that dynamically linked programs > load too slowly? I've certainly never heard any complaints along > those lines. Furthermore I would bet that the bulk of the dynamic > linking time comes from opening the shared libraries and mmapping > them, and there's nothing the RTLD can do about that. > > John, who spent weeks instrumenting and measuring the a.out RTLD years ago. And optimized it greatly after these weeks, in one of his first projects in FreeBSD. :) :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF rtld and environment variables...
> > Mike Smith wrote: > > > gzipped binaries are actually a terrible idea; they actually *waste* > > > space in most cases. > > > > Suprising, They saved space for a 200M disc in a 486 laptop with 3.[2,3,or4], > > No, that's the one case where they help. But people aren't trying to > squeeze whole systems into small disks anymore; Really? News to me... > they're trying to run > cut-down systems in tiny spaces (where the fact that you have to unpack > the entire binary into memory hurts), or disk space is so cheap that the > speed/swap hit is the only impacting factor. Methinks you generalize *way* too much, w/out knowing all the facts. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD,Posix,Linux Threading - Are they really useable?
> > PosixThreads are userland threads - if one thread blocks on i/o the > > whole process is blocked. Which makes PosixThreads rather useless. > >That is incorrect. FreeBSD's userland pthread implementation > does not block the whole process on I/O. POSIX does not specify > this behavior either. Actually, sometimes it does (for example when reading from an I/O device where select can't be used succesfully). > > FreeBSD Kernel-threads (dunno what they are called actually) can't be > > used natively!? (Searched the archives and found an explanation that the > > only way to access normal kernel SMP-thread functionality is to use > > LinuxThreads) > >FreeBSD's kernel threads are for separate threads of execution > in the kernel and aren't the same thing as threads for a user > process. You're missing the point. He's asking for 'kernel threads' so that multiple independant thread of execution for a given 'userland process' can be running simulataneously (virtually on a UP, and realistically on a MP). Currently, FreeBSD doesn't have any such thing, although there are a number of design documentations on how it would be done, if it were to be done. The recent work that Matt Dillon and Greg Lehey have been doing is intended to make this more possible. > > LinuxThreads: While they are kernel-threads, if one thread receives an > > uncought signal, all threads are killed (as they should be), but the > > resulting coredump is useless since it only captures the state of the > > last-killed-thread (or process or whatever you want to call it. > > LinuxThreads seems like just a big hack...). > >LinuxThreads on FreeBSD cannot be kernel threads because that > would require modifications to our scheduler which simply have > not been made. Not quite. LinuxThreads on FreeBSD *ARE* kernel threads, but they aren't part of the regular kernel because they aren't adequate, and they have the wrong license model to be used by default. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kevent()/kqueue() in a multithreaded environment
> > You normally wouldn't mix kqueue and threads; you'd use kqueue to > > *implement* threads. :-) > > > > AFAIK kqueue hasn't been made threadsafe, you'll have to bug > > [EMAIL PROTECTED] about it. Patches gladly accepted :) > > I may be just being stupid but I don't understand that last sentence. > > I thought kqueue() and kevent() were system calls... how can they > not be thread safe? I think there is a mis-communication here. They are thread 'safe', but if called, they block out all other 'threads' from running, so using kqueue doesn't allow for multiple threads to run 'concurrently'. In other words, a wrapper needs to be written so it can work in a 'threaded' environment effeciently. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CVS question
[ CVS has screwy behavior ] > CVS has a heuristic that does the wrong thing for this particular > file. [ Code and discussion deleted ] > I hope current > versions of CVS force the dates to be the same on an import. I > haven't checked to see whether that's the case or not. Suggestions like this would be good to send to the new CVS maintainers. Checkout www.cvshome.org, and send in a bug report, if you would please. You probably know CVS bugs better than many of the maintainers. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPC, shared memory, syncronization
> > > I don't know about the "bsd" or whatever way. If you're doing real > > > parallel programming and want real performance, you'll use a test-and-set > > > like function that uses the low-level machine instructions for same. > > > > That is exacly what I'm looking for! I found it to be overkill to > > involve the kernel just because I wanted to have a context switch during > > the "test-and-set". > > Precisely how do you expect to "have a context switch" without "involving > the kernel"? If your threads are implemented wholly in userland, you can easily do a context switch w/out involving the kernel. Our current pthreads library does this now, and the JDK's internal (green) threads implementation does it as well. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1
> > We are trying to create a dynamic library of extensions to PHP 4.02. > > This library implements a C++ class and has a C interface using the "Extern C" > > declaration. > > This library is linked with libstdc++.so.3 . > > > > If the library is called in a C program => no trouble. > > If the library is called from PHP with the "dlopen()" function => > > [Warning: Unable to load dynamic library > > '/users/em/ftp/php/test_cpp/debug/libphptest.so' - /usr/lib/libstdc++.so.3: > > Undefined symbol "__ti9exception" in > > /usr/local/httpd/htdocs/www/Iti_q/testso.php on line 2 > > This is because FreeBSD uses an archive library "libgcc.a" instead > of a shared library. That means that everything from libgcc which > is needed by your shared libraries had better already be linked into > the main program. The right solution is for us to use a shared > library for libgcc. At one point libgcc was shared (FreeBSD 1.*), and it caused way more problems that it solved. Nate (Note to eager committers: don't do this without > coordinating with obrien. There are ramifications that aren't > obvious.) > > As a work-around, try adding this to your main program. (I am > assuming it is a C++ program too.) > > extern void terminate(void); > void (*kludge_city)(void) = terminate; > > Another possibility would be to link explicitly with libgcc when > creating your dynamic library: > > cc -shared -o libphptest.so ... -lgcc > > That might cause other problems, but probably not. > > John > -- > John Polstra [EMAIL PROTECTED] > John D. Polstra & Co., Inc.Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1
> > At one point libgcc was shared (FreeBSD 1.*), and it caused way more > > problems that it solved. > > Do you remember any details? I analyzed it pretty thoroughly (I > thought) more than a year ago, and decided the shared library was the > best solution. If I remember right (and my memory is fuzzy for stuff that far bak) there were a couple of issues. 1) Speed. Shared libraries are slower than static libraries (PIC et. al), and the stuff in libgcc tends to be performance centric. 2) Ease of use. Everytime we upgrade or modify libgcc, it required keeping around the old libgcc.so. I don't think we had much experience with versioning back then, so we tended to either 'never' increment the versions or 'overdo' it. We weren't making releases nearly as often then, so keeping backwards compatability was more difficult as people tended to be running -stable instead of releases. Nowadays we handle backwards compatability better, so having N different versions of libgcc is still annoying, but easier to deal with (/usr/lib/compat). > At that time, I converted my -current system to using a shared libgcc > and ran it like that for 6 months at least without any problems. I > believe David O'Brien was also using a shared libgcc for a long time > without problems. There were no problems, it was just annoying. Many were of the opinion that 'not everything should be linked shared', since it tends to clutter up /usr/lib, and also tends to slow things down. Static linking isn't always bad > The non-shared libgcc used to work for us mainly because on the i386 > architecture practically nothing from libgcc was ever used. Aren't there quite a few 'math' routines inside libgcc (mods and diffs and all sorts of low-level 32/64 bit routines that are quite often used..) > That is no longer the case, because of all the exception support that > has been added to it for C++. If a shared library uses exceptions (as > does libstdc++) but the main program doesn't, you get undefined symbol > errors as the original poster reported. Using a shared libgcc > completely solves that. Ahh. Can't we just make the linker *always* add libgcc onto the end? Because it's a static library, if it's the symbol isn't used, then it won't be linked into the library? > Also, we _desperately_ need to switch away from the setjmp/longjmp > exception implementation and start using the now-standard DWARF2 > implementation. It makes a tremendous performance difference even in > programs that don't use exceptions at all. (I measured it once.) But > that in turn requires more support from libgcc, and exacerbates the > problems associated with using a non-shared libgcc. How so? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1
> [shared libgcc?] > > If I remember right (and my memory is fuzzy for stuff that far bak) > > there were a couple of issues. > > > > 1) Speed. Shared libraries are slower than static libraries (PIC > >et. al), and the stuff in libgcc tends to be performance centric. > > True. But if we just make it link against "-lgcc" then knowledgeable > users can always add "-static" if they know how to deal with the > consequences and they need the performance. Ahh, but -static implies the entire enchilada is linked static, which may not be the case. :( > > 2) Ease of use. Everytime we upgrade or modify libgcc, it required > >keeping around the old libgcc.so. I don't think we had much > >experience with versioning back then, so we tended to either 'never' > >increment the versions or 'overdo' it. > > Luckily, libgcc doesn't seem to be changing very often/much these > days. > > > Aren't there quite a few 'math' routines inside libgcc (mods and diffs > > and all sorts of low-level 32/64 bit routines that are quite often used..) > > I think most of the stuff that's actually used for C is just for the > relatively rare 64-bit operations on the i386. Bruce would know more. I know that the JDK uses them, but then again it also does 64-bit math, so that may be the case. :) > > Ahh. Can't we just make the linker *always* add libgcc onto the end? > > Because it's a static library, if it's the symbol isn't used, then it > > won't be linked into the library? > > I assume you mean always add it onto the end when building shared > libraries. That's problematic because the exception stuff uses some > static variables inside libgcc, and you end up with multiple copies of > them. Hmmm > > > Also, we _desperately_ need to switch away from the setjmp/longjmp > > > exception implementation and start using the now-standard DWARF2 > > > implementation. It makes a tremendous performance difference even in > > > programs that don't use exceptions at all. (I measured it once.) But > > > that in turn requires more support from libgcc, and exacerbates the > > > problems associated with using a non-shared libgcc. > > > > How so? > > Well, I should have made that a separate topic as it doesn't have that > much to do with whether libgcc is shared or not. But what I meant > was that the DWARF2 exception support uses more stuff from libgcc, so > you're more likely to run into an undefined symbol if libgcc is not > shared. Probably a bogus point for this discussion. Gotcha... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Automatic updates (was Re: How long for -stable...)
[ Culled the list way down, and moved it to -hackers ] > We could also look into providing an "update" command or something > which would pull either sources or binaries over from a snapshot box > and make the process of getting up to the branch-head a lot easier. > It's long been on my wishlist and I'm at the point where I'd be > willing to devote some BSDi resources to both writing the software > and setting up a build box for creating the relevant binaries on an > ongoing basis. Whoo hoo. Sounds like a *great* plan! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Automatic updates (was Re: How long for -stable...)
> > I think that we can do a lot with cvsupd. I've used cvsupd to grab > > binaries on an experimental basis and it seems to work great. I've > > Hmmm. Does cvsupd also move a target out of the way if it already > exists and it's in the process of replacing it? What if the target is > chflag'd but can be unprotected at the current security level? I know the author, and I'll bet you he could be convinced to modify it to do what we need. *grin* Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPFW bug/incoming TCP connections being let in.
I had blocked incoming TCP connections coming into my network using
IPFW, and I noticed that my brother was able to establish a Napster
connection, even though I had blocked it earlier.
I thought, no worries, I'll just block it at the port level.
I read a couple of articles, and noted that connections from to the
server should be blocked.
Easy enough, I'll just block my clients from establishing connections to
port .
Unfortunately, that doesn't work. Looking at tcpdump output, the
'server' appears to initiates a TCP connection from -> some random
port. My firewall rules do *NOT* allow incoming TCP connections to be
made to internal machines, since they only allow 'setup' packets to go
out.
So, how can Napster work? What happened to the 3-way handshake? I
could see an issue if the OS's were hacked to get around this and not
require a 3-way handshake, but the client in this case in a Win98 box.
I'm *really* confused, and more than a little concerned, since it
appears that somehow Napster is getting around the 3-way handshake.
Does Napster create 'raw' sockets that emulate TCP traffic?
In an attempt to attempt to debug what was going on, I stuck the
following rules in place;
00016 allow log tcp from ${client} to any out xmit ep0 setup
00017 allow log tcp from any to ${client} in recv ep0 setup
00018 allow log tcp from ${client} to any out xmit ep0 established
00019 allow log tcp from any to ${client} in recv ep0 established
00020 allow log tcp from ${client} to any out xmit ep0
00021 allow log tcp from any to ${client} in recv ep0
Then, I started up Napster and logged what showed up.
It was suprising (to me at least).
One would think that rules 16 or 17 *must* be hit first, because the
connection has to be initially established. However, it doesn't work
that way.
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 18 Accept TCP CLIENT-IP:1897 NAPSTER: out via ep0
ipfw: 19 Accept TCP NAPSTER: CLIENT-IP:1897 in via ep0
No 'setup' packets are sent at all.
Confused and concerned
Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
> > I had blocked incoming TCP connections coming into my network using > > IPFW, and I noticed that my brother was able to establish a Napster > > connection, even though I had blocked it earlier. > > > > I thought, no worries, I'll just block it at the port level. > > > > I read a couple of articles, and noted that connections from to the > > server should be blocked. > > > > Easy enough, I'll just block my clients from establishing connections to > > port . > > > > Unfortunately, that doesn't work. Looking at tcpdump output, the > > 'server' appears to initiates a TCP connection from -> some random > > port. My firewall rules do *NOT* allow incoming TCP connections to be > > made to internal machines, since they only allow 'setup' packets to go > > out. > > > > So, how can Napster work? What happened to the 3-way handshake? I > > could see an issue if the OS's were hacked to get around this and not > > require a 3-way handshake, but the client in this case in a Win98 box. > > The remote napster client sends a message through the central Napster > server, which relays the message to your Napster client to tell your > machine to make a connection to the remote machine. This much I undertand. However, I'm not making any downloads, so my client isn't (yet) connecting to another client. I'm trying to block connections to the server. How is the client connecting to the server? I don't see *any* TCP setup packets being sent out by my client, so how is the client communicating with the server via TCP? (I *AM* seeing TCP packets being sent out, but they are being sent as 'established' connections, before a setup packet is being sent.) > The regular 3-way handshake is occurring. It's just not initiated by the > machine you would expect. The only way my client can work is if it initiates the connection, but I don't see it initiating a connection to port . So, how then is the Napster server at port communicating with my client? > You'd have to block outgoing SYNs to any > outside host at port (but anyone who knows anything about ports could > change their port number and get around your block). That was what I did, but the rule is never being hit. However, there appears to be a connecting from my client to port on the server. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW bug/incoming TCP connections being let in.
> I had blocked incoming TCP connections coming into my network using > IPFW, and I noticed that my brother was able to establish a Napster > connection, even though I had blocked it earlier. *sigh* Thanks to Guy Helmer for being patient with me as I fretted about this. I just found out that Napster leaves a client running in the background, and even though I had added firewall rules to block new connections to the server, the old 'established' connection was still up and running. I didn't realize that was the case, so that everytime I 'restarted' Napster the packets were getting through. In fact, what had happened was that the 'GUI' was being stopped/restarted, but the network portion was running the entire time. Once Guy walked me through and showed me that things were indeed working correct, we rebooted the box and my rules worked fine. Sorry for the false alarm! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Blocking Napster (WAS: IPFW bug/incoming TCP connections being let in.)
> > > I had blocked incoming TCP connections coming into my network using > > > IPFW, and I noticed that my brother was able to establish a Napster > > > connection, even though I had blocked it earlier. > > > > *sigh* > > > > Thanks to Guy Helmer for being patient with me as I fretted about this. > > > > I just found out that Napster leaves a client running in the background, > > and even though I had added firewall rules to block new connections to > > the server, the old 'established' connection was still up and running. > > > > This might be helpful to you and others. Since napster uses what ever > ports it can find the best way is to block the servers. > > # Napster > $fwcmd add deny tcp from any to 208.178.163.56/29 via tun0 > $fwcmd add deny tcp from any to 208.178.175.128/29 via tun0 > $fwcmd add deny tcp from any to 208.49.239.240/28 via tun0 > $fwcmd add deny tcp from any to 208.49.228.0/24 via tun0 > $fwcmd add deny tcp from any to 208.184.216.0/24 via tun0 I had these rules in place, but it appears that there are new servers in place. I also had to to add > $fwcmd add deny tcp from any to 64.124.41.0/24 via tun0 (I'm guessing it's a class C, I just had hit two addresses in that block, so I blocked the entire class C.) The above is the reason I was trying to do a 'port' block of the Napster servers, because trying to keep up with IP addresses is a real pain in the butt... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
