From owner-freebsd-hackers Mon Nov 25 07:00:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA23073 for hackers-outgoing; Mon, 25 Nov 1996 07:00:21 -0800 (PST) Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com [149.174.206.133]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA23027 for ; Mon, 25 Nov 1996 07:00:09 -0800 (PST) From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com Received: by dub-img-3.compuserve.com (8.6.10/5.950515) id JAA09539; Mon, 25 Nov 1996 09:59:32 -0500 Date: Mon, 25 Nov 1996 09:54:25 -0500 Subject: NON-DELIVERY of: hackers-digest V1 #1659 To: "INTERNET:hackers@freefall.freebsd.org" Message-ID: <199611250959_MC1-C33-8F40@compuserve.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sender: owner-hackers-digest@freefall.freebsd.org Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by dub-img-4.compuserve.com (8.6.10/5.950515) id JAA13249; Wed, 20 Nov 1996 09:29:39 -0500 From: Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by mail.webspan.net (8.7.5/8.7.3) with ESMTP id JAA27555; Wed, 20 Nov 1996 09:25:08 -0500 (EST) Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA05019 for freebsd-hackers-digest-outgoing; Wed, 20 Nov 1996 06:00:08 -0800 (PST) Date: Wed, 20 Nov 1996 06:00:08 -0800 (PST) Message-Id: <199611201400.GAA05019@freefall.freebsd.org> To: freebsd-hackers-digest@FreeBSD.ORG Subject: hackers-digest V1 #1659 Reply-To: hackers@freefall.freebsd.org Errors-To: owner-hackers-digest@freefall.freebsd.org Precedence: bulk hackers-digest Wednesday, 20 November 1996 Volume 01 : Number 1659 In this issue: Re: Ipx to ip routing Re: split speed sio port? Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Kernel calls - args in registers Re: Who needs Perl? We do! Re: Who needs Perl? We do! Re: Kernel calls - args in registers Re: arpresolve errors Re: Voice Recognition (URGENT) Re: Kernel calls - args in registers Re: arpresolve errors RELENG_2_2 and CVS Recuperating a DOS partition DLT4000 bootup problems gated's weirdness (Was: arpresolve errors) ---------------------------------------------------------------------- From: Joe Greco Date: Tue, 19 Nov 1996 17:00:51 -0600 (CST) Subject: Re: Ipx to ip routing > And we want to eliminate the need for so many ip addresses so that we > can get rid of all the ip address conflicts that we can't seem to trace > down. > > Any one have a good method of finding an ip address conflict? Don't know about the rest, but typically I would suggest that the above suggests a certain lack of networking discipline. :-( Usually IP address conflicts arise when someone has created a network that is too large. I usually become uncomfortable somewhere around 8 or 16 nodes, but then I am a bit paranoid. :-) Ideally, in a school environment, each networked classroom or lab should be on its own subnet, or perhaps several subnets. When the machines are configured, use a labeler to note the machine's IP address on the front of the machine. Preferably devise some logical mechanism for numbering, such as sequential numbering, so that when students pull off the labels, it is still pretty easy to figure it out. If you do that and keep no more than, maybe, 16 machines on a network, then you only have 16 machines to check when a problem arises. If they are all in the same room, this is pretty easy. As far as your address space concerns, in your scenario I would probably consider using 10-net addresses, a proxy Web server, and a NAT device to provide continued access to Internet services. The 10-net thing works really nice even for a large school, because you can use the second octet to designate building, third octet to designate room, and fourth octet to designate machine number. ... JG ------------------------------ From: Adam David Date: Wed, 20 Nov 1996 04:27:04 +0000 (GMT) Subject: Re: split speed sio port? > > This is all very well, but when upstream is not (yet?) willing to implement > > such measures themselves and will not trust software that is located outside > > of their direct control, one has to make do with what is available. > > Huh? How does this affect anything? Or are you saying that "upstream" > insists that you use an asymmetrical link? It is at present the only way we can transmit more than we receive, without paying through the nose for the ability to receive more. This is because we are required to pay per-kb rate for 25% of available incoming bandwidth even if we only actually use 10%. (I don't think anyone else is happy with this billing arrangement either, except for the biller). > > Of course, a proven product might catch their interest in terms of > > suitability. > > Hey, go for it 8) What was the name of that product again, and does it have a URL? :) Adam ------------------------------ From: davidn@sdev.usn.blaze.net.au (David Nugent) Date: Wed, 20 Nov 1996 16:25:50 +1100 Subject: Re: Who needs Perl? We do! Nik Clayton writes: > Terry Lambert writes: > > This is the rub. PERL is not stable over the release cycle period for > > FreeBSD. People are *always* complaining "why don't you upgrade your > > PERL?", even when it it well known that an upgrade frequently requires > > updating all of the PERL-dependent scripts to the new syntax, since > > the syntax is not sufficiently stable. > > As someone who spends a reasonable amount of the working day coding in > Perl, I don't think this is a particularly valid point, particularly in > comparison to the moving target that is Tcl/Tk. In the past four years > Perl 4.036 (/usr/bin/perl on 2.1.5 and below) has been the standard, > rock-solid version on the 4.branch, while 5.0 was the new, OO biased > version. Yes. I have to think carefully when trying to come up with something works under perl4 as well. :) The comment about perl4 being dead *is* very true it is no longer supported. Let's see.. excluding things provided for perl development, in the - -current distribution we have the following scripts: /usr/bin/catman /usr/bin/keyinfo /usr/bin/killall /usr/bin/makewhatis /usr/bin/sgmlfmt /usr/bin/whereis /usr/bin/which /usr/sbin/adduser (and presumably add/rmgroup & removeuser?) /usr/sbin/kbdmap /usr/sbin/spkrtest /usr/sbin/vidfont It is interesting to note that all of these scripts run unchanged under perl5. So the first paragraph quoted above is bogus in any case. > There is an issue moving from 4.036 to 5.x, as the syntax did change > in a few places between the two -- not counting the option of a new > OOish syntax, which wouldn't break older scripts anyway. Most obviously > where '@' in strings suddenly needed to backslash-escaped. This broke > a lot of things that dealt with e-mail addresses. Yes. That is perhaps the most pertinent change, and the one that is most likely to affect anyone who is dependant on perl4. There are others, but most dependancies are fairly obscure. > Not much in the way of hard facts there, but this seems to be an opinion > only thread anyway. I can only confirm the same experience. All I will add is that a decision not to upgrade perl (not necessarily follow the bleeding edge at all!) is just putting off the inevitable with the probability of creating likely dependancies on perl4 that apparently don't currently exist. > Having said that, I don't think Perl should be moved to the base system > anyway (assuming that base system is whatever you get when you install > bin.xx for the first time). But this is for the same reason I don't > particularly want tcl in there either -- they're extensions to the > system -- I have no objections to seeing a new dist category, something > like 'cool-things-we-think-you'll-enjoy', but I tend to prefer to > build these things myself. I could not agree more. Personally, i think perl5 is *too big* to include in the base system anyway, and comes with a large amount of cruft that noone will use unless they develop applications in perl or run a lot of third-party perl scripts (mainly web sites). For the few perl scripts in the system, only the sgml formatter will be the loss (unless something in the install depends upon it? Can't say I've looked). Almost everything else can be easily replaced, either with a shell script or a small C program (which I'll happily volunteer to take care of, if the removal of perl4 from the base dist is the preferred way to go). It appears to me at least that the reluctance to "upgrade" to perl is due to its size. I agree with that. It's just that as a developer who uses perl, having perl4 on the system is a pain in the rear. Yes, sure, I know I won't affect finished scripts that use #!, but (a) it is a waste of space just for a few scripts, (b) for a variety of reasons, I'd prefer to have /usr/bin in my path before /usr/local/bin and while developing scripts, I often need to call perl from the command line (with -d, for example), and (c) nothing perl 4 does can't be done by perl 5. David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn ------------------------------ From: davidn@sdev.usn.blaze.net.au (David Nugent) Date: Wed, 20 Nov 1996 16:28:42 +1100 Subject: Re: Who needs Perl? We do! Terry Lambert writes: > The problem, again, is that the change cycle on PERL has historically > been too short to base a FreeBSD release on a PERL release... PERL > is moving faster than FreeBSD, in other words. Which then begs the question - why use perl at all? Yes, I use it quite a bit, but in a base distribution I don't really see it as an appropriate tool. It is certainly easier that programming in, say, bourne shell, and probably significantly faster too. But I still think it is a mistake it being part of the base system. David Nugent, Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@blaze.net.au http://www.blaze.net.au/~davidn ------------------------------ From: roberto@keltia.freenix.fr (Ollivier Robert) Date: Wed, 20 Nov 1996 00:21:39 +0100 Subject: Re: Who needs Perl? We do! According to Terry Lambert: > I realize this. However, it requires going over your existing PERL > code to make sure it doesn't break from the syntactical changes. 99% of the time, all you need is "perl -cw your.script". > What was the delay between when people started saying we should upgrade > to PERL 5.x and the release of MajorDomo 1.93? I think 1.93 was released before that moment. The first really usable version was 5.001m (5.000 should have never seen the light and 5.001 was still very buggy). > The problem, again, is that the change cycle on PERL has historically > been too short to base a FreeBSD release on a PERL release... PERL > is moving faster than FreeBSD, in other words. Yes, that's why I think it is better to wait for 5.004 and use this one. - -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #28: Sun Nov 10 13:37:41 MET 1996 ------------------------------ From: "John S. Dyson" Date: Wed, 20 Nov 1996 00:32:38 -0500 (EST) Subject: Re: Kernel calls - args in registers > Travis Hassloch x231 stands accused of saying: > > > > One thing I thought might make a worthwhile gain is to make all > > intrakernel calls use registers -- and if possible, all kernel calls. > > I think Bruce will have opinions here, but IMHO using registers for > arg passing isn't much of a win, especially on the x86 where there > are so few of them. > I have an opinion also... I have already recompiled much of the FreeBSD kernel to use the register passing convention. Not really worth it. F.E. our approx 500-530usec fork perf (on a P5-166) doesn't budge almost at all with a change in calling convention... The pgcc compiler or - -fomit-frame-pointer makes much more difference (if it works to compile your kernel :-) -- sometimes "advanced options" don't work to compile ours...) (BTW, even that difference is in the 5% or so range.) I think that algorithmic improvements in the kernel are where "it is." It is likely that if we use the register passing conventions in the kernel -- it'll be because there is a worthwhile improvement. I haven't seen a significant one -- YET. If you see one -- let me know!!! John ------------------------------ From: Gary Clark II Date: Tue, 19 Nov 1996 23:44:45 -0600 (CST) Subject: Re: Who needs Perl? We do! Terry Lambert wrote: > > > FreeBSD. People are *always* complaining "why don't you upgrade your > > > PERL?", even when it it well known that an upgrade frequently requires > > > updating all of the PERL-dependent scripts to the new syntax, since > > > the syntax is not sufficiently stable. > > > > Between Perl4 and Perl5, the changes are documented in perltrap. Between > > 5.x there have been very few syntaxic changes. You won't notice many > > changes between 5.003 and 5.004 in that respect. The only major change that hit people was that the @ was no longer escaped by default. > > I realize this. However, it requires going over your existing PERL > code to make sure it doesn't break from the syntactical changes. Takes very little time. Just like taking a C program to C++. > > The problem is the dependencies for the existing code, and that fact > that if the maintainers of the code haven't "upgraded", then we become > promary support for the "upgraded" scripts. Most programs run fine with NO changes. > > This would have been less of a problem in the 5.x changeover if the > PERL distribution had a tool to upgrade scripts over the syntactic > changes. Why don't C++ compliers supply the same thing? I've seen programmers get bit by the same thing. > > > > > For FreeBSD, the biggest problem is PERL dependent ports and MajorDomo; > > > PERL upgrades have been delayed for MajorDomo more than once in the > > > past. > > > > Majordomo has been Perl5 compatible as of 1.93. 1.94 runs fine under it. > > What was the delay between when people started saying we should upgrade > to PERL 5.x and the release of MajorDomo 1.93? > > The problem, again, is that the change cycle on PERL has historically > been too short to base a FreeBSD release on a PERL release... PERL > is moving faster than FreeBSD, in other words. HuH???!!!??? > Terry Lambert > terry@lambert.org Gary - -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii ------------------------------ From: Gary Clark II Date: Tue, 19 Nov 1996 23:58:44 -0600 (CST) Subject: Re: Who needs Perl? We do! Michael Smith wrote: > Ollivier Robert stands accused of saying: > > > > Perl 5.004 is rounding the corner. 5.003_08 just came out and 5.003_09 will > > be 5.004-candidate. > > > > Many thinks are broken (even if people don't tumble often on them) and > > 5.004 should be stable. > > Ok. I am still waiting for a hand up from someone who has a > contrib-ready perl5. If someone can point me towards the how-to contrib docs I'll do this. Considering I did the perl4 b-make and the commit, I have no problems doing this. > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ Garyy - -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii ------------------------------ From: Bruce Evans Date: Wed, 20 Nov 1996 17:51:32 +1100 Subject: Re: Kernel calls - args in registers >I've been looking at this a bit lately, and noticed that, as you >point out, gcc doesn't use registers on the x86 by default (IMHO it should >have, at least if you can configure that for free Unixes -- it's not like we >had a historical baggage commercial compiler to be call-level compatible >with). Well, gcc didn't officially support passing args in registers until 2.7, and it still doesn't quite work - function calls through a pointer sometimes clobber one of the args. Example: FreeBSD qsort(). My version of FreeBSD works when compiled with -mrtd (callee pops), but I gave up on getting -mregparm=N to work when I hit this problem. - -mrtd doesn't make much difference. It gives slightly smaller code and is a few percent faster on 486's (because `ret N' is just as fast as `ret') and a few percent slower on Pentiums (because `ret N' is one nonpairable cylce slower than `ret'). - -mregparm=2 gives slightly larger code. I think it won't make much difference to the speed when it works. Bruce ------------------------------ From: Bill Fenner Date: Tue, 19 Nov 1996 21:52:13 PST Subject: Re: arpresolve errors In message you wr ite: >Are messages like the one below indicative of mbuf problems, or something >else? Generally they're indicative of routing problems. >"arpresolve: can't allocate llinfo for 203.x.y.49" What's the routing table look like for 203.x.y.49? >A check through the messages file >shows that it only happens to CSLIP links which are gateways to remote >nets/subnets. Are you using gated? gated likes to add bogus host routes which confuse the routing table. There's code in 2.2 that handles this. Bill ------------------------------ From: Amancio Hasty Date: Wed, 20 Nov 1996 00:28:56 -0800 Subject: Re: Voice Recognition (URGENT) Yeap, what about it . I remember about a year ago approaching the project to import technology to FreeBSD and the folks over there where not interested so what is the status nowdays? Amancio >From The Desk Of Andrew Y Ng : > Hmmm.. Chk out the CMU Speech Lab: > http://www.speech.cs.cmu.edu/speech/ > > /ayn > > -- > Andrew Y Ng http://andrew.Ngbert.org > Carnegie Mellon University; ECE major, Music minor > campus ph: 412/862-2836; voice mail: 412/268-6700 x30027 > talk: finger ayn@andrew.Ngbert.org for online status. > finger ayn@CMU.EDU for more info, > such as my public key, geekcode, snail address, etc. > > NGBERT! http://www.Ngbert.org > ------------------------------ From: Jonathan Stone Date: Wed, 20 Nov 1996 00:32:23 -0800 Subject: Re: Kernel calls - args in registers >It is likely that if we use the register passing conventions in the >kernel -- it'll be because there is a worthwhile improvement. I haven't >seen a significant one -- YET. If you see one -- let me know!!! The x86 just doesn't have enough registers for this to be worth much. But for NetBSD, looking in a non-x86-specific direction: I experimented with this on 68030s running More/BSD (Mt.Xinu's version of the Utah port of 4.3bsd-Tahoe, or thereabouts) to hp300s. I measured worthwhile savings from both passing arguments in registers and using callee-pops for non-variadic functions. That was with gcc 1.33; I don't know how much saving to expect from gcc2, if and when the -mregparm works again. I'd definitely encourage the NetBSD people with access to m68k machines to try it, though. Are there better alternatives, these days, than rewriting all the locore routines to use different calling convention? Like maybe adding attributes to a declaration to disable -mrtd? And of course, passing _syscall_ args in registers rather than on the normal stack saves copyin/copyout, and reduces syscall latency, which is a Good Thing for us time vultures. ------------------------------ From: "Daniel O'Callaghan" Date: Wed, 20 Nov 1996 19:40:15 +1100 (EST) Subject: Re: arpresolve errors On Tue, 19 Nov 1996, Bill Fenner wrote: I wrote: > >Are messages like the one below indicative of mbuf problems, or something > >else? > > Generally they're indicative of routing problems. > >"arpresolve: can't allocate llinfo for 203.x.y.49" > > What's the routing table look like for 203.x.y.49? 203.x.y.48/28 203.x.y.49 UGc 203.x.y.49 203.x.y.34 UH 203.s.t 203.x.y.49 UGc > >A check through the messages file > >shows that it only happens to CSLIP links which are gateways to remote > >nets/subnets. > > Are you using gated? gated likes to add bogus host routes which confuse > the routing table. There's code in 2.2 that handles this. Yes, I am using gated. Yes, there are host routes, but they seem to make sense (e.g. the one listed above) for the point to point links. And the PPP-connected networks on this and another 2.1.5R terminal server have *not* exhibited this [arpresolve] behaviour, although the routing entries are equivalent. Thanks, Danny ------------------------------ From: Michael Hancock Date: Wed, 20 Nov 1996 17:40:58 +0900 (JST) Subject: RELENG_2_2 and CVS I discovered that my CVS tree was corrupt after trying the following: cd /jaz cvs co -r RELENG_2_2 src # -r implies -P The checkout failed and later that night my cvsup cron job failed with the error "Possible reference of NIL". So I rm -rf /jaz/cvs; cvsup'ed the tree again; rm -rf /jaz/src; checked out 2.2 release; built a new kernel and things look fine now for testing 2.2. /jaz/src was current. Which brings me to a question, should I have done a cvs release src? The man pages say that doing a checkout-only is ok, but seems to recommend doing a release beforehand. What do most people do in practice, especially with something as large as the entire FreeBSD src tree? Regards, Mike Hancock ------------------------------ From: Jean-Pierre Morant Date: Wed, 20 Nov 1996 13:35:53 +0100 Subject: Recuperating a DOS partition Hello ! being a bit short on swap space I would like to reuse a DOS partition on my wd1 (second ESDI) disk. I've used fdisk to assign that partition to FreeBSD, then edited the fstab so that /dev/wd1s1f (the next available partition name) is seen as a swap partition. Apaprently there is a step inbetween that I'm missing : how to tell FreeBSD that the second (nr 1) partition on disk wd1 should be used as /dev/wd1s1f ? Do anybody know what I'm forgetting ? Thanks ADDITIONNAL INFO ===== Now, if I type swapon -a I get : swapon: /dev/wd1s1f: Device not configured fdisk /dev/wd1 tells me that : ******* Working on device /dev/wd1 ******* parameters extracted from in-core disklabel are: cylinders=244160 heads=1 sectors/track=1 (1 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=244160 heads=1 sectors/track=1 (1 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 244160 (119 Meg), flag 80 beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 1/ head 0 The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 244160 (119 Meg), flag 0 beg: cyl 0/ sector 0/ head 0; end: cyl 447/ sector 1/ head 0 The data for partition 2 is: The data for partition 3 is: where partition 0 is another file system mounted and used as : /dev/wd1s1e on /tmp (local) - -- Jean-Pierre Morant c/o MARBEN S.A./N.V. La vie serait tellement Boulevard du Souverain,400, Vorstlaan plus facile 1160 Bruxelles Si seulement Belgium nous avions les sources.... + 32 2 663 1130 (phone) + 32 2 663 1199 (fax) http://www.marben.be jpm@marben.be ------------------------------ From: mark@plato.salford.ac.uk (Mark Powell) Date: 20 Nov 1996 12:48:22 -0000 Subject: DLT4000 bootup problems I was testing a DLT4000 tape on my system. However, 2.2-960801 hung when the kernel was probing the scsi devices. Any ideas why? Yes, it was properly terminated and I'd slotted it in using the same cable, terminator and scsi ID of the DAT drive that is usually on that machine. - -- Mark Powell - Unix Information Officer - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 745 5936 Fax: +44 161 736 3596 Email: mark@ucsalf.ac.uk finger mark@ucsalf.ac.uk (for PGP key) Home Page ------------------------------ From: J Wunsch Date: Wed, 20 Nov 1996 12:08:00 +0100 (MET) Subject: gated's weirdness (Was: arpresolve errors) As Bill Fenner wrote: > Are you using gated? gated likes to add bogus host routes which confuse > the routing table. There's code in 2.2 that handles this. Btw., people might remember that i've once asked about some complaints GateD spits onto the console of our modem server whenever somebody logs in via PPP. Now that i've finally got 'round yesterday to DTRT and subnet our IP address space, my PPP peers are no longer inside the ether address range, and i could throw the d*mn proxyARP hackery overboards... Needless to say, GateD no longer complains! It works fine as expected, as soon as a PPP interface comes up, GateD notices it and offers routing for this peer. - -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ------------------------------ End of hackers-digest V1 #1659 ******************************