Re: Improving GNU make compatibility in BSD make (+ patch)
In the last episode (May 31), Jos Backus said: > On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: > > Automake avoids the issue entirely by simply listing the dependencies > > itself, so > > > > > envuidgid: envuidgid.o > > > $(CC) $(LDFLAGS) -o $@ $^ > > > > becomes > > > > > $(CC) $(LDFLAGS) -o $@ envuidgid.o > > Ugly but portable, I guess. It would be better to be able to use pattern rules > instead; less duplication. It ends up creating a make variable for each target containing the object files (envuidguid_OBJECTS=envuidgid.o for example) and uses that on the dependency and link lines, so it's not too bad. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On 2002-05-31 20:08 -0700, Brooks Davis wrote: > On Fri, May 31, 2002 at 09:32:26PM -0500, Brandon D. Valentine wrote: > > On Sat, 1 Jun 2002, Giorgos Keramidas wrote: > > >Indeed. Brain cells shutting down already. I shouldn't read procmail > > >rules after I get sleepy. The 'f' flag of procmail seems like, aw mee > > >gods, so fine ;-))) > > > > Cool. If I might make another suggestion, you will likely get faster > > performance and in general make people happier if you only run this > > script against your own personal mirror of the CVS repo so as not to tie > > up anoncvs.freebsd.org. > > There's a rather serious problem with that idea... I'm actually not > sure even anoncvs.freebsd.org will work since I get commit mail pretty > close to instantly after I do a commit and I know my repository isn't up > to date by then. I'd be slightly suprised if anoncvs.freebsd.org was > either. Well, yep. I want to test this with a bunch of good ole' commits logs first, and make sure it works as expected. Then the plan is to integrate this to the CVSROOT scripts of FreeBSD and make sure one can choose whether diffs are sent by something similar to CVSROOT/access. If that works reasonably well, then perhaps we can have the following: cvs-all-diff A list like cvs-all is now, where anyone can subscribe and receive diff output as long as normal commit logs. This has the advantage that cvs-all remains as it is today, and those who want to also get patches in their mailboxen unsubscribe from cvs-all and subscribe to cvs-all-diff instead. committers Nothing changed in cvs-all, but let committers get diffs. This leaves things unchanged for cvs-all, but lets committers receive diffs too, while everyone who is subscribed in cvs-all continues to receive shorter mail. (Bandwidth is not cheap for some of the subscribers of cvs-xxx lists, so making them receive patches might be an overkill.) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: > That doesn't fix Tru64 make, which uses $> like BSD make, or Solaris > make, which has neither. In fact, based on this sample, I suggest you > submit a patch to the gmake people adding $>, which obviously is the > defacto standard :) That's a good idea, thanks. I just sent an e-mail coining the concept to [EMAIL PROTECTED] > Automake avoids the issue entirely by simply listing the dependencies > itself, so > > > envuidgid: envuidgid.o > > $(CC) $(LDFLAGS) -o $@ $^ > > becomes > > > $(CC) $(LDFLAGS) -o $@ envuidgid.o Ugly but portable, I guess. It would be better to be able to use pattern rules instead; less duplication. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
In the last episode (May 31), Jos Backus said: > On Fri, May 31, 2002 at 06:55:54PM -0700, Julian Elischer wrote: > > On Fri, 31 May 2002, Jos Backus wrote: > > > Fyi: it appears nobody is really interested in having BSD make > > > and GNU make converge a little, so I am not going waste any more > > > time on this. > > > what would you want to do? > > BSD make and GNU make use different symbols for .ALLSRC: GNU make > uses $^ and BSD make uses $>. All my tiny patch to BSD make does is > have BSD make treat $^ as $>. This fixes the problem of the mktool > Makefile which with this patch is executed properly by both make's. > Perhaps there is a better way to achieve this but I don't see it. > Since BSD make (or OpenBSD make, for that matter) doesn't currently > use $^ I thought it was a pretty safe and useful change. That doesn't fix Tru64 make, which uses $> like BSD make, or Solaris make, which has neither. In fact, based on this sample, I suggest you submit a patch to the gmake people adding $>, which obviously is the defacto standard :) Automake avoids the issue entirely by simply listing the dependencies itself, so > envuidgid: envuidgid.o > $(CC) $(LDFLAGS) -o $@ $^ becomes > $(CC) $(LDFLAGS) -o $@ envuidgid.o -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On Fri, May 31, 2002 at 09:32:26PM -0500, Brandon D. Valentine wrote: > On Sat, 1 Jun 2002, Giorgos Keramidas wrote: > > >Indeed. Brain cells shutting down already. I shouldn't read procmail > >rules after I get sleepy. The 'f' flag of procmail seems like, aw mee > >gods, so fine ;-))) > > Cool. If I might make another suggestion, you will likely get faster > performance and in general make people happier if you only run this > script against your own personal mirror of the CVS repo so as not to tie > up anoncvs.freebsd.org. There's a rather serious problem with that idea... I'm actually not sure even anoncvs.freebsd.org will work since I get commit mail pretty close to instantly after I do a commit and I know my repository isn't up to date by then. I'd be slightly suprised if anoncvs.freebsd.org was either. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg34751/pgp0.pgp Description: PGP signature
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 06:55:54PM -0700, Julian Elischer wrote: > what would you want to do? > > On Fri, 31 May 2002, Jos Backus wrote: > > > Fyi: it appears nobody is really interested in having BSD make and GNU make > > converge a little, so I am not going waste any more time on this. BSD make and GNU make use different symbols for .ALLSRC: GNU make uses $^ and BSD make uses $>. All my tiny patch to BSD make does is have BSD make treat $^ as $>. This fixes the problem of the mktool Makefile which with this patch is executed properly by both make's. Perhaps there is a better way to achieve this but I don't see it. Since BSD make (or OpenBSD make, for that matter) doesn't currently use $^ I thought it was a pretty safe and useful change. Thanks for caring! CC?=gcc OPT=-O2 -march=i686 #DEBUG=-g -pedantic -Wall -Werror LDFLAGS=-s CFLAGS=$(OPT) $(DEBUG) PROGS=envuidgid setugid tcpaccept tcplisten execlp bsok babysit BINMODE?=555 prefix=/usr/local bindir=$(prefix)/bin .c.o: $(CC) $(CFLAGS) -c $< all: $(PROGS) envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ setugid: setugid.o setonlygid.o $(CC) $(LDFLAGS) -o $@ $^ tcpaccept: tcpaccept.o signal_action.o $(CC) $(LDFLAGS) -o $@ $^ tcplisten: tcplisten.o $(CC) $(LDFLAGS) -o $@ $^ execlp: execlp.o $(CC) $(LDFLAGS) -o $@ $^ babysit: babysit.o signal_action.o file_lock.o $(CC) $(LDFLAGS) -o $@ $^ bsok: bsok.o $(CC) $(LDFLAGS) -o $@ $^ $(bindir): mkdir -pm 755 $(bindir) clean: rm -f $(PROGS) install: $(PROGS) $(bindir) install -m $(BINMODE) $(PROGS) $(bindir) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On Sat, 1 Jun 2002, Giorgos Keramidas wrote: >Indeed. Brain cells shutting down already. I shouldn't read procmail >rules after I get sleepy. The 'f' flag of procmail seems like, aw mee >gods, so fine ;-))) Cool. If I might make another suggestion, you will likely get faster performance and in general make people happier if you only run this script against your own personal mirror of the CVS repo so as not to tie up anoncvs.freebsd.org. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On 2002-05-31 21:18 -0500, Brandon D. Valentine wrote: >On Sat, 1 Jun 2002, Giorgos Keramidas wrote: >>On 2002-05-31 20:53 -0500, Brandon D. Valentine wrote: >>> Assuming your script works, here's the procmail hoodoo: >>> >>> :0 fw >>> * ^List-Id: >>> | /path/to/filter/script >> >>The problem with this is that I would have to hardwire the output >>folder name to the script, or pass it as a parameter. I've found two >>answers until now, by reading my manpages [beats head]. One is: > > Nonsense. With the rule I gave you your script should take the message > on stdin, modify it, and spit it back out on stdout where it will > continue to fall through the procmail rules. That's what the 'f' option > at the start of the rule is all about. You end up with two succesive > rules like this: > > :0 fw > * ^List-Id: > | /path/to/filter/script > > :0: > *^ List-Id: > cvs-all > > Make sense? Indeed. Brain cells shutting down already. I shouldn't read procmail rules after I get sleepy. The 'f' flag of procmail seems like, aw mee gods, so fine ;-))) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On Sat, 1 Jun 2002, Giorgos Keramidas wrote: >On 2002-05-31 20:53 -0500, Brandon D. Valentine wrote: >> Assuming your script works, here's the procmail hoodoo: >> >> :0 fw >> * ^List-Id: >> | /path/to/filter/script > >The problem with this is that I would have to hardwire the output >folder name to the script, or pass it as a parameter. I've found two >answers until now, by reading my manpages [beats head]. One is: Nonsense. With the rule I gave you your script should take the message on stdin, modify it, and spit it back out on stdout where it will continue to fall through the procmail rules. That's what the 'f' option at the start of the rule is all about. You end up with two succesive rules like this: :0 fw * ^List-Id: | /path/to/filter/script :0: *^ List-Id: cvs-all Make sense? Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding diffs to commit-mail on the fly
On 2002-05-31 20:53 -0500, Brandon D. Valentine wrote: > On Sat, 1 Jun 2002, Giorgos Keramidas wrote: > > >Given a script in Perl or awk > >or whatever that works like this one, how would you all integrate this > >with procmail to let it filter all the commit mail of FreeBSD? > > Assuming your script works, here's the procmail hoodoo: > > :0 fw > * ^List-Id: > | /path/to/filter/script > > Insert this rule into your .procmailrc anywhere above where you actually > filter cvs-all to a specific folder. The problem with this is that I would have to hardwire the output folder name to the script, or pass it as a parameter. I've found two answers until now, by reading my manpages [beats head]. One is: :0 H * ^sender: [EMAIL PROTECTED] | /path/to/filter freebsd-cvs-all But 'm not sure if this will let procmail lock the folder properly. My intention was to add something like: :0 H * ^sender: [EMAIL PROTECTED] * ! ^X-inline-diff: yes | /path/to/filter | formail -I 'X-Inline-Diff: yes' -s procmail :0 H * ^sender: [EMAIL PROTECTED] freebsd-cvs-all Reading up my formail/procmail manpage helped a bit. Off to yet more testing :) - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
what would you want to do? On Fri, 31 May 2002, Jos Backus wrote: > Fyi: it appears nobody is really interested in having BSD make and GNU make > converge a little, so I am not going waste any more time on this. > > -- > Jos Backus _/ _/_/_/Santa Clara, CA > _/ _/ _/ > _/ _/_/_/ > _/ _/ _/_/ > [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; > > 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: Adding diffs to commit-mail on the fly
On Sat, 1 Jun 2002, Giorgos Keramidas wrote: >Given a script in Perl or awk >or whatever that works like this one, how would you all integrate this >with procmail to let it filter all the commit mail of FreeBSD? Assuming your script works, here's the procmail hoodoo: :0 fw * ^List-Id: | /path/to/filter/script Insert this rule into your .procmailrc anywhere above where you actually filter cvs-all to a specific folder. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Fyi: it appears nobody is really interested in having BSD make and GNU make converge a little, so I am not going waste any more time on this. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Adding diffs to commit-mail on the fly
Hi Matt and everyone,
I remember that Matt had mentioned adding diffs of the commits to the
commit-mail, which would make it possible to quickly view what changed
without leaving the MUA and manually searching for the proper CVS
diff/rdiff incantation to view the diff.
The idea was resting at the back of my mind, and tonight I hacked this
Perl script that seems to mostly do what I want, when I pipe a single
message to it's STDIN in mbox format. Given a script in Perl or awk
or whatever that works like this one, how would you all integrate this
with procmail to let it filter all the commit mail of FreeBSD?
The code of the script is a bit clumsily written, but here it is for
anyone who cares to play with it. You can see a sample of the output
of this script, in mbox file format, at:
http://www.FreeBSD.org/~keramida/files/freebsd-rdiff.txt
- Giorgos
==
#!/usr/bin/perl
#
# A filter that copies all the lines from stdin unchanged, until it
# matches the magic FreeBSD commit-mail line that says files and
# revisions follow. When that line is matched, do our stuff until the
# line that matches /^$/; when all file changes are finished.
# If this is set to non-zero, then trim EOL whitespace from the
# lines of the commit log before copying it to STDOUT.
$mail_delete_eol_spaces = 1;
# Where would I find the CVSROOT that mirrors the FreeBSD repository?
$cvs_root_dir = "/home/ncvs";
# Copy all the lines of STDIN to STDOUT, until we find the part of the
# message that contains the file change list. Keep the changelist
# lines in an array, and then after the changelist is copied verbatim
# to STDOUT too, parse the changelist and call cvs(1) as needed to
# view diffs.
$in_changelist = 0; # set when we're reading changelist lines
@changeset = ();# start with an empty changeset array
while (defined($line = )) {
chomp $line;
if ($mail_delete_eol_spaces) {
$line =~ s/\s*$//;
}
if (($in_changelist eq 0) && ($line =~ m/^ Revision ChangesPath$/)) {
print "$line\n";
$in_changelist = 1;
} elsif ($in_changelist ne 0) {
if ($line =~ m/^$/) {
$in_changelist = 0;
&show_changeset(\@changeset);
} else {
unless ($line =~ m/^\s*$/) {
$line =~ s/^\s+//;
push (@changeset,$line);
}
}
print "$line\n";
} else {
print "$line\n";
}
}
sub show_changeset {
my $aref = shift;
die "No changeset" unless (defined($aref));
print "\n";
print "--- patch begins ---\n";
foreach $line (@$aref) {
($rev, $added, $deleted, $rcsfile) = &valid_changeline($line);
$lastrev = &rev_previous($rev);
$pipecmd = "cvs -q -d ${cvs_root_dir} rdiff -u -r$lastrev -r$rev $rcsfile";
open(CVSDIFF, "${pipecmd}|") or die "Could not open input pipe from CVS";
while (defined($in = )) {
chomp $in;
print "$in\n";
}
close(CVSDIFF);
}
print "--- patch ends ---\n";
}
sub valid_changeline {
my $line = shift;
die "No line passed" unless (defined($line));
($rev, $added, $deleted, $rcsfile) = split /\s+/, $line;
die "Invalid revision \[$rev\]"
unless &valid_rcsrev($rev);
die "Invalid number of added lines \[$added\]"
unless &valid_rcslines($added);
die "Invalid number of deleted lines \[$deleted\]"
unless &valid_rcslines($deleted);
die "No rcsfile specified in changeline \[$line\]"
unless (defined($rcsfile));
return ($rev, $added, $deleted, $rcsfile);
}
sub valid_rcsrev {
my $rev = shift;
die "No RCS version to validate"
unless (defined($rev));
my @foo = split /\./, $rev;
return 0 if ($#foo == -1);
foreach $k (@foo) {
return 0 if ($k = m/\D/);
}
return 1;
}
sub valid_rcslines {
my $num = shift;
die "No RCS lines to validate"
unless (defined($num));
return ($num =~ m/^[+-]?\d+$/);
}
sub rev_previous {
my $rev = shift;
die "No revision specified" unless (defined($rev));
die "Invalid revision number \[$rev\]" unless &valid_rcsrev($rev);
@parts = split /\./, $rev;
if (($#parts % 2) eq 0) {
# This is a branch revision number.
# Just delete the last part to find the branchpoint address.
$#parts--;
} else {
# This is a real revision number. Attempt to either reduce
# the last numeric value, or remove the two last parts (when
# possible) to find the last revision before a branch point
# when the last part is equal to 0.
$last = $parts[$#parts];
if ($last gt 1) {
$parts[$#parts]--;
} elsif ($#parts gt 1) {
$#parts -= 2;
}
}
return "" . join('.', @parts) . "";
}
Re: KLD mmap question
On Thu, 30 May 2002, Tom Tang wrote: > Thanks for the reply, I'll check it out. However > if you'll notice in my prev mail, I stated that I was > trying to contigmalloc 4K... Hard to believe that > the system doesnt have 4K lying around. Good point. Contigmallocing a page is pretty silly, since you get a page anyway. Why not just use normal malloc? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Broken IPv6 DNS servers (Was: Is gethostbyname2() reentrant?)
Yeah. I'm in the middle of the Mozilla code base as you probably remember, trying to fix the problem of these bad DNS servers. I did complain to the technical administrators for the ones that were giving me problems, but I've only received form letter replies and they are still broken. I also saw the recent sendmail thread on the same issue. It just isn't acceptable to users to have a 90 second wait for these broken DNS servers. I really wish we could come up with some fix below the application level. Mozilla was already using the apartment model for operating systems that do not have a reentrant gethostbyname2(). I did make a patch for Mozilla that lets it do async dns on systems that have a reentrant gethostbyname2(), but obviously that doesn't help on FreeBSD. Perhaps we can come up with some acceptable change to the gethostbyname2() implementation that will deal with these broken DNS servers without causing problems for the end users or violating the 'correct' behaviour. How about this change to the gethostbyname2() implementation. First it fires off an request and if it doesn't get a reply in 5 seconds, then fire off an A request to the same server. If it gets a reply to the A request, it writes a message to syslog complaining about a broken DNS server. If it doesn't get a reply to the A request, it can just do the standard timeout thing. This should give you correct results in the case the DNS server is really broken and speed up the results in the case where the DNS server just suffers from this bug. Admittedly, you could have a problem where the reply has been sent but lost or delayed for more than 5 seconds, but that seems like a lesser problem than making the user wait 90 seconds or failing to deliver email. We could make this algorithm dependent on a sysctl variable that is off by default, but you could turn it on if you are having lots of problems with IPv6 lookups. Any other suggestions? Please don't tell me to complain to the owner of the DNS servers. I have done that. If you feel that is the proper solution, please complain yourself to [EMAIL PROTECTED] who is the Technical Contact for vanguard's domain. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is gethostbyname2() reentrant?
Peter Haight wrote:
> >On May 31, Peter Haight wrote:
> >> If I link with libc_r can I use gethostbyname2() at the same time in two
> >> different threads?
> >
> >Pardon my ignorance, but how does re-entrancy affect this? It would seem
> >that you're interested in a function that doesn't block.
>
> The function returns a pointer to some sort of memory. I'm worried that the
> the two separate requests could possibly mess up each others memory. Maybe I
> have the terminology wrong.
The gethostbyname() is just a wrapper to the gethostbyname2() function,
that supplies the "address family" parameter automatically.
The memory is a static struct hostent which is declared and then has
it's address returned in /usr/src/lib/libc/net/gethostbyht.c .
So no, the calls are not permitted to occur concurrently.
You may be able to achieve concurent calls by calling ndispatch()
directly after assembling your own request, if you use the bind9
resolver libraries instead of the FreeBSD libc resolver code (it
depends on whether it's been made thread safe since the last time
I looked at the code).
Alternately, you can write your own resolver library.
If you are attempting to do this to make lookups faster (bounded by
the timeout for bad resolvers for INET6 addresses, for example ;^)),
you will need to do that.
If, on the other hand, the intent is only to permit outstanding
requests to exist simultaneously, and not necessarily truly
concurrently, you can go to "apartment model threading", and/or
serialize access to the interface ("rental model threading").
Serializing access is obvious. Apartment model establishes a
thread to do the lookup work, and you queue requests to that
thread; it services them (usually in FIFO order), and then posts
a wakeup on the result buffer for you, after copying them out.
Which model is best really depends on the structure of your code,
and your expecatation of whether or not truly reentrant routines
will end up being concurrent, or not.
At some point, I expect that DNSSEC will become widespread (Verisign
basically bought the top tier DNS, so it's reasonable to expect they
will force this to happen at some point). When that happens, we will
problably see most requests for recursive lookups and for DNS forwarders
become TCP requests instead of UDP requests, because of their size. So
I expect there will be a limit on the number of concurrent outstanding
unsatisfied requests that wil end up being smaller for TCP than you
might expect for UDP (e.g. each TCP will require an fd/socket pair; UDP
doesn't have that requirement).
That basically implies that, eventually, the apartment model for
threading is going to win (I rather expect that using threading to
scale is going to fall by the wayside, and be replaced with async NS
interfaces before that happens, so this whole thread thing is really
a "make-work" anyway).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: > On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: > > The biggest problem with GNU make that I've seen is re-expansion > > of variable variables. > > > > The suggested fix doesn't address that, so it won't fix the most > > common "compatability problem". > > So what? It fixes (in a backward-compatible way because ``$^'' isn't used in > BSD make) one incompatibility without which I have to have two different > Makefiles in the simple case I am thinking about. It's at least an incremental > improvement that doesn't break anything afaIcs. 1) Please see the references I cited. I believe "$^" is used in a BSD make, even if it's not in the FreeBSD make, and that in a future version of FreeNSD make, it ought to have the function of the BSD make that uses it, not GNU make. 2) I am not comfortable with changing FreeBSD make into GNU make. 3) I am not comfortable adding features to FreeBSD make which render makefiles, which are then written to use these newly added features, non-portable to other BSD systems. 4) There are *already* enough cases where people have written "sh" scripts with "bash" syntax, so that they *claim* they are "sh" scripts, but are in fact "bash" scripts. I would hate to see the same thing happen to "makefiles" to turn them into "gmakefiles". 5) What you've added is a synonym for something that's already there; it is better to change the makefile to use the existing syntax, then it is to change the "make" to add new syntax. 6) What are you going to do, when you need to compile on Solaris? 7) What are you going to do when you need to compile on AIX? 8) How is "make" different from "cc" or "tar"? If we are going to add the features, why not "just use GNU make instead"? 9) Why not "just use Linux instead"? That last is a reductio ad absurdum... but I really don't see what making this change accomplishes, other than making FreeBSD "toe the GNU line". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dmesg buffer preserved between reboots
In the last episode (Jun 01), Ruslan Ermilov said: > One of my remote i386 machines preserves the dmesg buffer between > reboots, and others not. What features cause this buffer to be > preserved? I saw this on Alphas, and thought that this was caused If your BIOS zeros out memory as part of a warmboot, you'll lose the dmesg buffer. I've got docked laptops that don't seem to ever zero the data, even on a power cycle. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is gethostbyname2() reentrant?
In the last episode (May 31), Peter Haight said: > >On May 31, Peter Haight wrote: > >> > >> If I link with libc_r can I use gethostbyname2() at the same time > >> in two different threads? > > > >Pardon my ignorance, but how does re-entrancy affect this? It would > >seem that you're interested in a function that doesn't block. > > The function returns a pointer to some sort of memory. I'm worried > that the the two separate requests could possibly mess up each others > memory. Maybe I have the terminology wrong. According to the manpage: BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Actually, gethostbyname2 uses nsdispatch to do the dirty work, and its manpage is even more explicit: BUGS The nsdispatch routines are not thread safe. This will be rectified in the future. You'll have to serialize access to it yourself. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
XFree86 4.2.0 & GeForce4 440 Go in Dell Latitude C840
Sorry for X off topic... Is anybody here got that combination running? I've seen that Linux world did that with Nvidia's help. How to port their solution into freebsd 4.5 box? Thanks in advance for any possible help, Igor ua3qrz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ICU_LEN with IO APIC
Bosko Milekic wrote: > On Fri, May 31, 2002 at 12:12:00PM +0300, Aaro J Koskinen wrote: > > Is there any particular reason why the number of interrupts is limited > > to 32 on APIC systems? Is it just a conservative guess on the number of > > interrupts anyone might want to need...? > > I'm not sure but perhaps this is historical (and now also required > again), but if we use a word to mask out interrupts than after 32 we > run out of bits. "Who needs more than 32 interrupts anyway?!" :-) Who needs more than 4? Foo on PCI. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dmesg buffer preserved between reboots
Hi! One of my remote i386 machines preserves the dmesg buffer between reboots, and others not. What features cause this buffer to be preserved? I saw this on Alphas, and thought that this was caused by the "soft" reboot, where (probably) memory contents is not destroyed. But I have never seen this before of i386's: [...] Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RELEASE #0: Mon Jan 28 14:31:56 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium 4 (1614.39-MHz 686-class CPU) [...] Can anyone shed some light on this? Thanks, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg34733/pgp0.pgp Description: PGP signature
Re: Is gethostbyname2() reentrant?
>On May 31, Peter Haight wrote: >> >> If I link with libc_r can I use gethostbyname2() at the same time in two >> different threads? > >Pardon my ignorance, but how does re-entrancy affect this? It would seem >that you're interested in a function that doesn't block. The function returns a pointer to some sort of memory. I'm worried that the the two separate requests could possibly mess up each others memory. Maybe I have the terminology wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is gethostbyname2() reentrant?
On May 31, Peter Haight wrote: > > If I link with libc_r can I use gethostbyname2() at the same time in two > different threads? Pardon my ignorance, but how does re-entrancy affect this? It would seem that you're interested in a function that doesn't block. -Clint To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: broadcast packets not reaching sender on if_hwassist capableinterfaces
On Fri, 31 May 2002, mark tinguely wrote: > > Summary: FreeBSD 4.3 Broadcast IP datagrams not looping on Broadcom GigE > card. > > > Also, why is the decision to loop the packet back made in ether_output > > rather than in ip_output? Off the top of my head I can't see any > > particular advantage, but perhaps there is. The disadvantage is that I > > will have to disable hardware assist for broadcast packets to make things > > work right. > > the bge sets the interface output to be ether_output() which is > called from the ip_output() after all thse flags have been set.. Two things I forgot to mention: 1. The driver we are using is a Broadcom propietary driver, not the BGE driver. 2. Our driver is mistakenly setting the device as being in SIMPLEX mode :-) And, I realized in the shower this morning, if you have to calculate the checksums on-board for any reason for that packet, there is no point in having the checksums calculated twice. > Are these packets that fail part of a IP fragment? m_copy does not copy > the hwassist flags. we see the same problem with multicast packets. > Bill Fenner wrote a simular multicast patch before FreeBSD 4.5-RELEASE, > but even that fix has not been included into the tree yet either. > In ip_output, we should either we need to copy the hwassist flag in > _copy or in the code that follows a m_copy, or force the checksum > calculations. Yes. We are investigating fixing our driver to make sure that it sets DUPLEX mode since our switch is capable of it. > if your packets are not part of a fragment, then let me know. Nope, but thanks for your reply. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: broadcast packets not reaching sender on if_hwassist capable interfaces
Summary: FreeBSD 4.3 Broadcast IP datagrams not looping on Broadcom GigE card. > Also, why is the decision to loop the packet back made in ether_output > rather than in ip_output? Off the top of my head I can't see any > particular advantage, but perhaps there is. The disadvantage is that I > will have to disable hardware assist for broadcast packets to make things > work right. the bge sets the interface output to be ether_output() which is called from the ip_output() after all thse flags have been set.. Are these packets that fail part of a IP fragment? m_copy does not copy the hwassist flags. we see the same problem with multicast packets. Bill Fenner wrote a simular multicast patch before FreeBSD 4.5-RELEASE, but even that fix has not been included into the tree yet either. In ip_output, we should either we need to copy the hwassist flag in _copy or in the code that follows a m_copy, or force the checksum calculations. if your packets are not part of a fragment, then let me know. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 01:38:17AM -0700, Terry Lambert wrote: > The biggest problem with GNU make that I've seen is re-expansion > of variable variables. > > The suggested fix doesn't address that, so it won't fix the most > common "compatability problem". So what? It fixes (in a backward-compatible way because ``$^'' isn't used in BSD make) one incompatibility without which I have to have two different Makefiles in the simple case I am thinking about. It's at least an incremental improvement that doesn't break anything afaIcs. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ICU_LEN with IO APIC
John Baldwin wrote: > > On 31-May-2002 Bosko Milekic wrote: > > > > On Fri, May 31, 2002 at 12:12:00PM +0300, Aaro J Koskinen wrote: > >> Hello, > >> > >> Is there any particular reason why the number of interrupts is limited > >> to 32 on APIC systems? Is it just a conservative guess on the number of > >> interrupts anyone might want to need...? > > > > I'm not sure but perhaps this is historical (and now also required > > again), but if we use a word to mask out interrupts than after 32 we > > run out of bits. "Who needs more than 32 interrupts anyway?!" :-) > > Actually, the historical value in stable is 24 because the same 32-bit word > shares the 8 softinterrupts with 24 hardware interrupts. I think the APIC > only has 32 interrupt pins however. Historically it was because ipending and friends were a 32 bit word. Even now, we have a stack of 32 bit bitfields in this area. It isn't uncommon to have 2 IO apics with 24 pins each. Fortunately there are rarely more than about 20 or so in use in total. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
On Fri, May 31, 2002 at 12:50:59PM +0200, Bjoern Fischer wrote: > > The second group is more for trying to keep hackers from gaining local > > access. The examples provided by systrace are for this group of > > programs. But, the same concept applies: the binary needs to run local > > and access local files and even write to files. A webbrowser still needs > > to execute xpdf, the user still needs to be able to specify what program > > to run for pdf's. You can limit the possibilities, but, the minimal > > capabilities a program needs to function is always enough for a hacker. > > I think you are wrong here. If there are normal user applications that > let local users compromise the system, the operating system is flawed. > And even if there is any, users who attempt to compromise the system, > or who behave grossly negligent regarding system security, are candidates > for rmuser(8) anyway. > > The target of systrace is not the local user (or unwelcomed "visitor" > disguised as a local user) who attempts to hack the system. This > will never work, since you always can install a not-sandboxed > version of the affected software with normal user privileges. > > systrace is not for sandboxing users but for sandboxing untrusted > binaries. Such as netscape for example. Of course you never would > run netscape as root. But you may even consider your "normal" user > privileges as too powerful (reading PGP-Keys, tampering .rhosts or > xauth, deleting you reports). You miss the point here. Lets say you are a user on a box and you run netscape. Lets say there is a bug in netscape, netscape could be considered untrusted, and evil hackers can exploit your netscape when you browse their site. This is completely the same issue as for setuid binaries, netscape needs local capabilities which are always enough for hackers to hack the system. It is an illusion to think that making hackers not being able to read the PGP-Keys are unable to hack the system. Netscape for instance needs to execute other binaries, the user should be allowed to specify which binaries. Netscape needs to write cache files, any hacker exploiting netscape can use that to create a new process which isn't systrace-profiled. I suggest getting over the illusion hackers won't be able to hack the system if you narrow them a bit, the binaries you run still need capabilities to correctly function, which are always enough to hack the system. (I ment remote hackers exploiting your bitchx and netscape, not local users) > > I have coded similar things for linux, the main problem is the > > performance hit. For every system call, you will need to check against > > the policy and systrace even provides regular expression filters etc. > > I don't expect a greater performance hit than ktrace. Far most system > calls are read() and write() anyway. this is very specific for the program, you can't make judgements like this without being sure for what applications this applies. Frank van Vliet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ICU_LEN with IO APIC
On 31-May-2002 Bosko Milekic wrote: > > On Fri, May 31, 2002 at 12:12:00PM +0300, Aaro J Koskinen wrote: >> Hello, >> >> Is there any particular reason why the number of interrupts is limited >> to 32 on APIC systems? Is it just a conservative guess on the number of >> interrupts anyone might want to need...? > > I'm not sure but perhaps this is historical (and now also required > again), but if we use a word to mask out interrupts than after 32 we > run out of bits. "Who needs more than 32 interrupts anyway?!" :-) Actually, the historical value in stable is 24 because the same 32-bit word shares the 8 softinterrupts with 24 hardware interrupts. I think the APIC only has 32 interrupt pins however. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ICU_LEN with IO APIC
On Fri, May 31, 2002 at 12:12:00PM +0300, Aaro J Koskinen wrote: > Hello, > > Is there any particular reason why the number of interrupts is limited > to 32 on APIC systems? Is it just a conservative guess on the number of > interrupts anyone might want to need...? I'm not sure but perhaps this is historical (and now also required again), but if we use a word to mask out interrupts than after 32 we run out of bits. "Who needs more than 32 interrupts anyway?!" :-) > A. > > -- > Aaro Koskinen > E-mail: [EMAIL PROTECTED]"I'm the ocean, I'm the giant undertow." > http://www.iki.fi/aaro Regards, -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[no subject]
auth 484c029e subscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HSFLinModem: Anyone want to help teach me how?
On Fri, 2002-05-31 at 03:43, Terry Lambert wrote: > Larry Rosenman wrote: > > Hello, > > I've just joined this list in the last few days, but was wondering > > if anyone out there wanted to help teach me how I/we could port the HSF > > LinModem code from LINUX to FreeBSD. I have one of the recognized PCI > > ID's in my Laptop, but don't even know where to start with interfacing > > with the FreeBSD kernel. > > > > I'm willing to do it, but I've never done Kernel programming before. > > I'm also very willing to help test. > > Start with the Rockwell supplied Linux drivers. They actually have > a BSD compatible source license, so they could be included with a > BSD ditribution in binary form, without making the kernel illegal > due to clause 6 of the GPL being incompatible with BSD licenses. > > Also, make sure that you have the right identification from Windows > or some other method. I have a modem in my laptop that most UNIX > software claims is an HSF, but is in reality an HCF (e.g. almost > all Sony laptops in recent history have a Rockwell (Connectix) HCF > in them). > > Note that Rockwell has HCF drivers for Linux, in source code, under > the same BSD-happy license, for download from their web site. I'm aware of this, and have the code, but I'm very confused as to how to connect the dots from the Linux code to the FreeBSD kernel and drivers. The PCI ID that FreeBSD mentions as unknown is one of the mentioned ones in the doc. Now, how do I determine what to do from here? As I said, I've never done kernel/driver stuff (But am willing to learn). This is on a Fujitsu Lifebook C-6651, if that matters, with the Intel chips (ICH). Thanks for the reply. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
At 12:50 31/05/2002 +0200, Bjoern Fischer wrote: >systrace is not for sandboxing users but for sandboxing untrusted >binaries. Such as netscape for example. Of course you never would >run netscape as root. But you may even consider your "normal" user >privileges as too powerful (reading PGP-Keys, tampering .rhosts or >xauth, deleting you reports). I think even more useful than sandboxing netscape would be sandboxing netscape (or other application) plugins. I'd certainly be much more willing to download and run the foo-reader plugin from 31337 enterprises if I knew that it would be unable to make any system calls beyond those necessary to interface with the owning application. Colin Percival To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandboxing untrusted binaries
Hi Frank, > The idea of sandboxing binaries is nice ofcourse but there is a > conceptual drawback. > > I think you can divide the programs you run in two groups: > > the group of extra privileged programs which need that for changing > passwords or for allowing users to log into their shell (ssh etc). These type of programs are not the target of systrace. Normally you have the sources for programs that need raised privileges, so these programs can be trusted. If you expect security risks when you set up larger applications that partially need root privileges, you probably want to use jail(8) or capabilities (FreeBSD-5?). > The second group is more for trying to keep hackers from gaining local > access. The examples provided by systrace are for this group of > programs. But, the same concept applies: the binary needs to run local > and access local files and even write to files. A webbrowser still needs > to execute xpdf, the user still needs to be able to specify what program > to run for pdf's. You can limit the possibilities, but, the minimal > capabilities a program needs to function is always enough for a hacker. I think you are wrong here. If there are normal user applications that let local users compromise the system, the operating system is flawed. And even if there is any, users who attempt to compromise the system, or who behave grossly negligent regarding system security, are candidates for rmuser(8) anyway. The target of systrace is not the local user (or unwelcomed "visitor" disguised as a local user) who attempts to hack the system. This will never work, since you always can install a not-sandboxed version of the affected software with normal user privileges. systrace is not for sandboxing users but for sandboxing untrusted binaries. Such as netscape for example. Of course you never would run netscape as root. But you may even consider your "normal" user privileges as too powerful (reading PGP-Keys, tampering .rhosts or xauth, deleting you reports). > I have coded similar things for linux, the main problem is the > performance hit. For every system call, you will need to check against > the policy and systrace even provides regular expression filters etc. I don't expect a greater performance hit than ktrace. Far most system calls are read() and write() anyway. Björn Fischer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ICU_LEN with IO APIC
Hello, Is there any particular reason why the number of interrupts is limited to 32 on APIC systems? Is it just a conservative guess on the number of interrupts anyone might want to need...? A. -- Aaro Koskinen E-mail: [EMAIL PROTECTED]"I'm the ocean, I'm the giant undertow." http://www.iki.fi/aaro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem: Too Many open files
Hi I'm getting a Too Many open files message on a FreeBSD 4.5-RELEASE machine of mine I originally had the disk in a AMD k5 150 machine with 48MB or RAM and it ran fine and the drive was on the Promise Ultra TX2 controller card and it all worked fine. Now that I've put the drive in a much bigger machine with 500 K6-2 with 512MB or ram it starts getting a Too many open files problem Even trying to run ls -l gives the messages all though my net access stays running as natd continues not matter what it seems it says its something to do with /dev/kmem but I'm not sure what this does with memory. I don't see any reason a bigger machine should fail where a smaller one worked fine maybe I should cvsup my kernel sources my current compile is Feburary 29 09:53am 2002 maybe a bit old. oh yeah the Hard disk is my trusty IBM 40GB the 7200RPM with 2MB Cache model which has always worked great. any help appreicated. Bri, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HSFLinModem: Anyone want to help teach me how?
Larry Rosenman wrote: > Hello, > I've just joined this list in the last few days, but was wondering > if anyone out there wanted to help teach me how I/we could port the HSF > LinModem code from LINUX to FreeBSD. I have one of the recognized PCI > ID's in my Laptop, but don't even know where to start with interfacing > with the FreeBSD kernel. > > I'm willing to do it, but I've never done Kernel programming before. > I'm also very willing to help test. Start with the Rockwell supplied Linux drivers. They actually have a BSD compatible source license, so they could be included with a BSD ditribution in binary form, without making the kernel illegal due to clause 6 of the GPL being incompatible with BSD licenses. Also, make sure that you have the right identification from Windows or some other method. I have a modem in my laptop that most UNIX software claims is an HSF, but is in reality an HCF (e.g. almost all Sony laptops in recent history have a Rockwell (Connectix) HCF in them). Note that Rockwell has HCF drivers for Linux, in source code, under the same BSD-happy license, for download from their web site. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
Jos Backus wrote: > So BSD make interpreting either `$^' or `$+' as its own `$>' would improve > compatibility with GNU make Makefiles. I am just not sure which of the two GNU > make variables maps better to our `$>'. This patch implements the former: The biggest problem with GNU make that I've seen is re-expansion of variable variables. The suggested fix doesn't address that, so it won't fix the most common "compatability problem". If we are going to evolve make into gmake (not a good idea, IMO), then probably the place to start is "any port that requires gmake" to get it working under "make". I'm not sure, but I believe the other BSD's, and "OpenPorts" have modified "make" syntax somewhat. It's probably a good idea to keep compatability with options in the "OpenPorts" camp, more than any other, if it ever evolves to fulfill its potential properly. I really hate that many autoconf/automake scripts generate code that can ony be run by gmake, and sometimes also requires that /bin/sh actually be "bash" instead of "sh". It also occurs to me (from experience with "perl"), that in any language where it's posible to do something in more than one way, it is then impossible to differentiate "the right way" from "the wrong way". 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
