Date: Mon, 25 Nov 1996 17:32:24 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1660 Message-ID: <199611251738_MC1-C3A-258E@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from ns2.harborcom.net (ns2.harborcom.net [206.158.4.4]) by arl-img-2.compuserve.com (8.6.10/5.950515)
id OAA07889; Wed, 20 Nov 1996 14:38:12 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by ns2.harborcom.net (8.8.3/8.6.12) with ESMTP id OAA08184; Wed, 20 Nov 1996 14:35:47 -0500 (EST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id KAA26240
for freebsd-hackers-digest-outgoing; Wed, 20 Nov 1996 10:40:42 -0800 (PST)
Date: Wed, 20 Nov 1996 10:40:42 -0800 (PST)
Message-Id: <199611201840.KAA26240@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1660
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 1660
In this issue:
Re: Ipx to ip routing
Re: Recuperating a DOS partition
Re: Ipx to ip routing(translation)
640MB MO support source kit
Re: Kernel calls - args in registers
Re: Ipx to ip routing
Re: Ipx to ip routing
Re: Ipx to ip routing
Disk Striping
Re: RELENG_2_2 and CVS
Integrating sendmail 8.8.3 into a 2.1.6 tree
Re: Ipx to ip routing(translation)
Re: Turbo FreeBSD CD
Re: Ipx to ip routing
Re: Ipx to ip routing
Re: Ipx to ip routing(translation)
Re: Disk Striping
Re: Who needs Perl? We do!
----------------------------------------------------------------------
From: exidor@superior.net (Christopher Masto)
Date: Wed, 20 Nov 1996 09:50:47 -0500
Subject: Re: Ipx to ip routing
Joe Greco writes:
> Ideally, in a school environment, each networked classroom or lab should
> be on its own subnet, or perhaps several subnets. When the machines are
[...]
This falls apart when you have to deal with roaming. If your "school
environment" isn't dealing with student laptops now, it will be within
the next few years.
The nicest solution I've seen is a large subnet (~13 bits) with smart
IP switches.
- --
Christopher Masto . . . . Superior Net Support: support@superior.net
chris@masto.com . . . . . Masto Consulting: info@masto.com
On Book Titles, Confidence-Building:
"Correctly English in 100 Days"
- title from an East ASian book for beginning English speakers
------------------------------
From: J Wunsch <j@uriah.heep.sax.de>
Date: Wed, 20 Nov 1996 15:46:54 +0100 (MET)
Subject: Re: Recuperating a DOS partition
As Jean-Pierre Morant wrote:
> 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.
Are you confusing partitions and slices here?
wd1s1f would be partition `f' on slice 1 on wd1.
> 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
This is slice 1.
> 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
This is slice 2, i think that's what you're actually trying to use?
If so, it's /dev/wd1s2 (eventually followed by a partition letter).
I'm not sure whether swapping to partitions != `b' is supported now;
it wasn't supported in historic versions. At least, it's the cleanest
to stick with the traditional names, disklabel wd1s2, and assign the
entire space there to the `b' partition.
See also the (updated) section 2.15 of the FAQ for traditional
partition naming conventions.
- --
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. ;-)
------------------------------
From: dennis@etinc.com (dennis)
Date: Wed, 20 Nov 1996 10:13:44 -0500
Subject: Re: Ipx to ip routing(translation)
>
>
>On Tue, 19 Nov 1996, Hal Snyder wrote:
>
>> > My question is: Does Freebsd support ipx to ip routing. I know that BSDi
>> > does. (And they want $6,000 for their system because of it.)
>
>oops, I really meant ipx to ip TRANSLATION. I want to only have one host
>using a ip address and all the others using ipx (or somthing similar) to
>talk to the internet. Each computer would be mapped to by the MAC address
>on the ethernet card. All communications with the internet would go
>through FBSD host.
www.netcon.com
Dennis
------------------------------
From: "barry (b.a.) scott" <tsbarry@nortel.ca>
Date: 20 Nov 1996 09:57 EST
Subject: 640MB MO support source kit
Introduction
============
This kit contains changes to "FreeBSD 2.2-961006-SNAP"
which implement support for disks with physical sector
size of 512, 1024 and 2048 bytes.
Authors: These changes are the joint effort of
John Gumb (john@talisker.demon.co.uk) and
Barry Scott (barry@scottb.demon.co.uk). Please
contact us about these chanages.
At this point only the od device has been changed.
Changing the sd device would be straight forward;
apply the changes from od.c to sd.c. We will submit
a patch for sd.c later.
This kit contains diffs that can be used with the 'patch'
utility to update a virgin source tree.
Location: via ftp at ftp.freebsd.org:/pub/FreeBSD/incoming/mo-2048kit.tar.gz
1. Source Changes necessary
========================
a) SBIN changes
------------
Patch file: sbin.MO.patch
This file patches fdisk and newfs to support up to
2048 byte sectors.
Files changed on system:
/usr/src/sbin/newfs/newfs.c
/usr/src/sbin/newfs/mkfs.c
/usr/src/sbin/i386/fdisk/fdisk.c
Corresponding files in this kit:
mo-kit/sbin.MO.patch
mo-kit/sbin/newfs/newfs.c
mo-kit/sbin/newfs/mkfs.c
mo-kit/sbin/i386/fdisk.c
b) SYS chages
----------
Patch file sys.MO.patch
This file patches the kernel to support up to 2048
byte sectors on the od device. Both ufs and msdosfs
are supported on the od device.
Files changed on system:
/usr/src/sys/msdosfs/msdosfs_fat.c
/usr/src/sys/msdosfs/msdosfs_vfsops.c
/usr/src/sys/msdosfs/msdosfsmount.h
/usr/src/sys/kern/subr_diskslice.c
/usr/src/sys/ufs/ufs/ufs_disksubr.c
/usr/src/sys/scsi/od.c
Corresponding files in this kit:
mo-kit/sys.MO.patch
mo-kit/sys/msdosfs/msdosfs_fat.c
mo-kit/sys/msdosfs/msdosfs_vfsops.c
mo-kit/sys/msdosfs/msdosfsmount.h
mo-kit/sys/kern/subr_diskslice.c
mo-kit/sys/ufs/ufs/ufs_disksubr.c
mo-kit/sys/scsi/od.c
c) ETC changes
-----------
The file disktab.MO contains the disktab entry for the
Fujitsu M2513A MO drive with 2048 byte media.
Files changed on system:
/etc/disktab
Corresponding file in this kit:
mo-kit/disktab.MO
2. Testing performed
=================
a) MSDOS
-----
For MSDOS FS we created a FAT formated MO disk under Windows NT
and placed files onto the disk from Windows NT.
Under FreeBSD all the directories and files where confirmed
to be readable.
Under FreeBSD we created extra directories and wrote files
on to the MO disk.
FreeBSD could read these additional files.
The disk was moved back to Windows NT and chkdsk was used
to detect any file system corrupt. None found. Window NT
was used to read the directories and files written under
FreeBSB.
b) UFS
---
we use the following script to regression test
disklabel and newfs:
- -------------
#!/bin/bash
set -x
echo Initing disk...
umount /dev/od0a
umount /dev/od0s1
logger -p local1.notice "Initing disk..."
dd bs=2048 count=1 if=od0-mbr.fdisk of=/dev/rod0
dd bs=2048 count=2 seek=1 if=/dev/zero of=/dev/rod0
echo read disklabel...
logger -p local1.notice "read disklabel before write..."
disklabel /dev/rod0c
echo read disklabel...
logger -p local1.notice "read disklabel -r before write..."
disklabel -r /dev/rod0c
echo write disklabel...
logger -p local1.notice "write disklabel..."
disklabel -r -w /dev/rod0c m2513a-640mb testing-mo-code
echo read disklabel after write...
logger -p local1.notice "read disklabel..."
disklabel /dev/rod0c
echo newfs od0a
logger -p local1.notice "newfs..."
newfs /dev/rod0a
echo mount od0a
logger -p local1.notice "mount od0a..."
mount /mo
- -------------
Note the file od0-mbr.fdisk contains a copy of the mbr
written previously under FreeBSD by the new fdisk.
The entire /usr/src/sys tree was written to the MO disk
using cp -r. The disk was dismounted and then remounted.
Then the entire /usr/src/sys tree was diffed against the
MO disk copy. No differences found.
The MO was dismounted and fsck was run. It detected no
problems.
3. Misc. Information
=================
a) FDISK
-----
We have tended to create a single BSD slice using fdisk. Be
aware that the slice should start at offset 1 and the file
system size should be 310351 sectors; the first sector being
reserved for the mbr/partition table information. The geometry
we use is slightly different to the default (see our modified
/etc/disktab) in order to utilise the full capacity of the media.
The bios geometry we use is C/H/S 652/17/28 (652*17*28=310352).
------------------------------
From: "barry (b.a.) scott" <tsbarry@nortel.ca>
Date: 20 Nov 1996 10:04 EST
Subject: Re: Kernel calls - args in registers
This problem was reseached inside DEC by the compiler group.
They found that it was far better to pass parameters on the
stack and thus leave the optimiser a full set of registers
to work with within the body of the routine.
As gcc's optimiser improves it becomes less and less likely
that passing args in registers will give an advantage.
BArry
------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Wed, 20 Nov 1996 10:18:43 -0600 (CST)
Subject: Re: Ipx to ip routing
> Joe Greco writes:
> > Ideally, in a school environment, each networked classroom or lab should
> > be on its own subnet, or perhaps several subnets. When the machines are
> [...]
>
> This falls apart when you have to deal with roaming. If your "school
> environment" isn't dealing with student laptops now, it will be within
> the next few years.
>
> The nicest solution I've seen is a large subnet (~13 bits) with smart
> IP switches.
What do you do about IP address collisions, then??????? Good lord. Hope
you are great with an Ethernet sniffer, and your switches can trace on
your behalf. We had this problem at MEI, trust me, it is virtually
impossible to track down transient collisions on such a large network.
I can just see the fireworks when Suzi Smith, the first year arts major,
plugs in her workstation and mistakenly nails your gateway IP address
in as her PC's IP address. Woo woo! There goes your Internet
connectivity.
I would think that in the sort of environment you are suggesting, one
would think that DHCP is the ideal solution, and would allow for properly
subnetted networks that do not suffer from the general problems of a
network with 13 bits of space.
That way you could even "roam" yourself to your home network, or your
local ISP, or the other school across town where you decided to take one
course for the hell of it.
Incidentally: I am no big supporter of DHCP, I do not even like the
concept, but for this kind of thing, it's really the right tool.
... JG
------------------------------
From: exidor@superior.net (Christopher Masto)
Date: Wed, 20 Nov 1996 12:03:37 -0500
Subject: Re: Ipx to ip routing
Joe Greco writes:
> > Joe Greco writes:
> > > Ideally, in a school environment, each networked classroom or lab should
> > > be on its own subnet, or perhaps several subnets. When the machines are
> > [...]
> >
> > This falls apart when you have to deal with roaming. If your "school
> > environment" isn't dealing with student laptops now, it will be within
> > the next few years.
> >
> > The nicest solution I've seen is a large subnet (~13 bits) with smart
> > IP switches.
>
> What do you do about IP address collisions, then??????? Good lord. Hope
> you are great with an Ethernet sniffer, and your switches can trace on
> your behalf. We had this problem at MEI, trust me, it is virtually
> impossible to track down transient collisions on such a large network.
The switches don't allow IP address collisions. They associate a
hardware address with an IP address and talk to each other to keep
things in sync. This is what they did where I went to school (RPI).
When you're in your room with a laptop, packets for your IP get
forwarded to that physical wire.. if you unplug the laptop and
reconnect it in a classroom, the switch sees your first packet and
updates its knowledge of where you are, physically. If you try to use
the wrong IP, you are only affecting the physical segment that you are
on, because the switch knows it's not correct and probably even sends
an SNMP trap to let the administrators know.
- --
Christopher Masto . . . . Superior Net Support: support@superior.net
chris@masto.com . . . . . Masto Consulting: info@masto.com
On Machismo and Pestilence:
In the early sixties, we were strong, we were virulent...
- John Connally, Secretary of Treasury under Richard Nixon.
------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Wed, 20 Nov 1996 11:16:31 -0600 (CST)
Subject: Re: Ipx to ip routing
> The switches don't allow IP address collisions. They associate a
> hardware address with an IP address and talk to each other to keep
> things in sync. This is what they did where I went to school (RPI).
> When you're in your room with a laptop, packets for your IP get
> forwarded to that physical wire.. if you unplug the laptop and
> reconnect it in a classroom, the switch sees your first packet and
> updates its knowledge of where you are, physically. If you try to use
> the wrong IP, you are only affecting the physical segment that you are
> on, because the switch knows it's not correct and probably even sends
> an SNMP trap to let the administrators know.
Ethernet switches are not supposed to do anything other than MAC level
address routing.
Switches by definition will certainly allow IP address collisions because
they do not have a clue what the hell an IP address is.
The other disadvantage of switches is the potentially large amount of
ARP'ing that can go on to locate hosts in such a network.
... JG
------------------------------
From: "Darrin R. Woods" <dwoods@netgazer.com>
Date: Wed, 20 Nov 1996 11:14:31 -0600
Subject: Disk Striping
I just got my news server up and running INN (thanks to everyone that
helped), but now I'm looking for a better way of dealing with it. I've got
3 Fast/Wide 4gb disks to hold news. It would be a lot easier (and better
performance) if I could stripe (or span) the /var partition accross the 3
disks instead of having to guess as to how to partition each drive and into
what sizes.
The question: Is there a way to stripe a partition across multiple drives
in FreeBSD? If not, does anyone know of a FreeBSD like OS that will do it?
Preferably NOT Linux.
Thanks,
Darrin R. Woods | dwoods@netgazer.com
Director |
Netgazer Solutions, Inc. | http://www.netgazer.net
Dallas, Texas |
My employer most whole-heartedly denies everything I say
------------------------------
From: John Polstra <jdp@polstra.com>
Date: Wed, 20 Nov 1996 09:19:44 -0800
Subject: Re: RELENG_2_2 and CVS
In article <Pine.SV4.3.95.961120171708.9101A-100000@parkplace.cet.co.jp> Mike
Hancock writes:
> 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".
*Blush*, how embarrassing. There are still a couple of cases
involving badly spammed CVS repositories that can cause this sort
of thing to happen. If you still have a backup of the bad repository,
I'd greatly appreciate getting a copy of the offending subtree.
My current unreleased working version of CVSup has fixes for the
two problems I was aware of. But neither of them involved null
pointer dereferences, so this one could be new to me.
>
> 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?
No, "cvs release" doesn't affect the repository at all. It might affect
your logfiles, but that's all. There's nothing wrong with doing a
simple "rm -rf" of your working directory when you're done with it.
- --
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
------------------------------
From: Tom Samplonius <tom@sdf.com>
Date: Wed, 20 Nov 1996 09:54:48 -0800 (PST)
Subject: Integrating sendmail 8.8.3 into a 2.1.6 tree
I've been trying to integrate sendmail 8.8.3 (taken from current) into a
2.1.6 tree. This looked very straightforward because the Makefiles and
directory structure was nearly identical. However, when trying a "make
all", make stops with a "don't know how to make
/usr/src/usr.sbin/sendmail/src/sysexits.h". I find this strange.
sysexits.h isn't included with sendmail, and isn't mentioned in the
Makefile, so why does make think it needs to be built?
Tom
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Wed, 20 Nov 1996 10:37:51 -0700 (MST)
Subject: Re: Ipx to ip routing(translation)
> > You up for writing a winsock? If you were to write a winsock, and
> > you made it use SOCKS to connect to a SOCKS IP Proxy Gateway, your
> > name would be heralded from the tops of towers, in many circles,
> > since it would mean the death of the hated "aliasing".
>
> Trumpet Winsock does this, last time I looked, or am I misunderstanding
> what you are suggesting?
I'll have to look; I wasn't aware of this... Thanks!
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: "Maestros Asociados" <maestro@vianet.com.mx>
Date: Wed, 20 Nov 1996 11:58:48 -0600
Subject: Re: Turbo FreeBSD CD
- ----------
: From: Chris Timmons <skynyrd@tahoma.cwu.edu>
: To: Wilko Bulte <wilko@yedi.iaf.nl>
: Cc: FreeBSD hackers list <FreeBSD-hackers@FreeBSD.org>
: Subject: Re: Turbo FreeBSD CD
: Date: martes 19 de noviembre de 1996 13:28
:
:
: Well the great thing about FreeBSD is that it's FREE... so anybody can
put
: it on a CD and sell it.
:
: My preference has always been to buy from Walnut Creek CDROM because they
: support the project. I personally subscribe to both the -RELEASE and
: -SNAP cd distributions and have had excellent experience dealing with the
: Walnut Creek people on the phone. Since we rely heavily on FreeBSD at
: work, I spec Walnut Creek as the CD-ROM of choice there as well. Thanks
: WC!!!
:
: -Chris
:
: On Tue, 19 Nov 1996, Wilko Bulte wrote:
:
: > Hi there,
: >
: > I just today got a catalog in my PObox of Pacific HighTech CDROM.
: > A bit to my surprise it has a 'Turbo FreeBSD' CDROM listed on it's
: > cover. I contains 2.1.5R and a 2.2 SNAP (960801? it's very
: > fine print).
: >
: > Comments?
: >
: > Wilko
: > _
____________________________________________________________________
: > | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The
Netherlands
: > |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda
: >
- --------------------------------------------------------------------------
: >
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Wed, 20 Nov 1996 10:53:00 -0700 (MST)
Subject: Re: Ipx to ip routing
> > My question is: Does Freebsd support ipx to ip routing. I know that BSDi
> > does. (And they want $6,000 for their system because of it.)
> >
> > Do we have any plans for implementing it?
>
> You can't route between IP and IPX. They are incompatible. You can
> can however tunnel IPX across an IP network.
Sidebar: NetWare/IP uses encapsulated IPX on a native IP transport;
it is impossible to get away from IPX if you are using NetWare.
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Wed, 20 Nov 1996 11:02:02 -0700 (MST)
Subject: Re: Ipx to ip routing
> I would think that in the sort of environment you are suggesting, one
> would think that DHCP is the ideal solution, and would allow for properly
> subnetted networks that do not suffer from the general problems of a
> network with 13 bits of space.
I agree. And I'm not a big fan of DHCP, either.
Are people actually implementing PAP yet?
One big problem is that most RAS clients on MS boxes (Windows 95
without the "Plus! Pack" and Windows NT prior to 4.x) do not do auto
connection on the basis of routing information... ie: demand dial
PPP. An application has to be RAS aware, or a human has to establish
the connection. Bleah.
But they are much better at being DHCP clients than a BSD box can
generally stumble through. 8-(.
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Doug Ambrisko <ambrisko@whistle.com>
Date: Wed, 20 Nov 1996 10:16:47 -0800 (PST)
Subject: Re: Ipx to ip routing(translation)
Terry Lambert writes:
| > > You up for writing a winsock? If you were to write a winsock, and
| > > you made it use SOCKS to connect to a SOCKS IP Proxy Gateway, your
| > > name would be heralded from the tops of towers, in many circles,
| > > since it would mean the death of the hated "aliasing".
| >
| > Trumpet Winsock does this, last time I looked, or am I misunderstanding
| > what you are suggesting?
|
| I'll have to look; I wasn't aware of this... Thanks!
Not to mention Hummingbird has a Win95/NT wedge for free and I've used at home,
as well as, the 16 bit & 32 bit shims for Windows avaliable from NEC also for
the download.
Doug A.
------------------------------
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Date: Wed, 20 Nov 1996 12:22:05 -0600 (CST)
Subject: Re: Disk Striping
> I just got my news server up and running INN (thanks to everyone that
> helped), but now I'm looking for a better way of dealing with it. I've got
> 3 Fast/Wide 4gb disks to hold news. It would be a lot easier (and better
> performance) if I could stripe (or span) the /var partition accross the 3
> disks instead of having to guess as to how to partition each drive and into
> what sizes.
(I am not convinced that that statement is true...)
> The question: Is there a way to stripe a partition across multiple drives
> in FreeBSD? If not, does anyone know of a FreeBSD like OS that will do it?
> Preferably NOT Linux.
I recommend you go search the mailing list archives for almost anything
I have ever written on the subject of Usenet news and FreeBSD.
... JG
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Wed, 20 Nov 1996 11:26:32 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> > 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.
As we gain more dependencies on PERL in the main line source tree,
we will become more sensitive to PERL changes.
Has PERL syntax reached the top end of the inverse expotential curve
yet? If the last major rev is any indicator, the answer is "no". 8-(.
When it starts to stagnate, then it will be safe. 8-).
> > 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.
Frank answer: because compiler writers are lazy.
IMO, it is work 100 hours of compiler write time to save 1 hour of
compiler user time is compiler users outnumber compiler writers 100
to 1.
Since there are now in excess of 1.1 million professional programmers
in the US alone, I kind of think the number is closer to 1000 to 1.
One hour of compiler writer time for each 6 minutes of compiler user time.
The whole MS "near/far" debacle could have been avoided if the compiler
emitted pseduo-ops, which the linker resolved to near/far calls as
necessary -- and as a result, totally hidden segments from the compiler
user. Prototypes were the MS and Borland answer to the ANSI committee;
they are useful in that they allow a migration path from C to C++, but
the type-checking benefits result from not properly attributing object
module contents in the first place... otherwise, the linker could
catch the call return/argument mismatch by comparing attributes.
Similarly, the "extern C" constructs are bogus name space selector
mechanisms, only necessary because the object modules are once
again, not attributed, and the linker is, once again, stupid. A
lot of extra work for the compiler user because the compiler writer
didn't want to have to spend the time.
You can make similar arguments about applying "volatile" to variables
instead of functions and memory ranges to make it innocuous (and in
many cases, hide it with encapsulation -- ie: in __sighandler_t). A
"volatile" function, by definition, is a crossing of a thread of
control boundry. Stack scoping attribution could eliminate the need
for volatile for everything by physical device memory references...
any function crossing a thread of control (like a signal handler)
would implicitly have non-local scope references treated as volatile.
Etc., etc.
Failure to provide "syntax upgrade" tools to post-process existing
source code into the new syntax is just another instance of the same
general problem. 8-(.
And even if "syntax upgrade" tools were available, most of the PERL
code in FreeBSD is "vendor branched"... which means convincing all
the "vendors" to run the tools and rerelease their sources. There
*will* be a latency in that process.
> > 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???!!!???
Include the latency in getting all vendors to the same revision level
of the interpreter so that the new revision and all the dependent tools
can be committed simultaneously.
If FreeBSD has to run the conversion, then FreeBSD becomes the maintainer
for each tool until the vendor himself runs the conversion.
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
End of hackers-digest V1 #1660
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611251738_MC1-C3A-258E>