From owner-freebsd-hackers Sat Dec 17 04:01:29 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id EAA13390 for hackers-outgoing; Sat, 17 Dec 1994 04:01:29 -0800
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id EAA13384 for <freebsd-hackers@freebsd.org>; Sat, 17 Dec 1994 04:01:27 -0800
Received: (from rgrimes@localhost) by ref.tfs.com (8.6.8/8.6.6) id EAA12283 for freebsd-hackers@freebsd.org; Sat, 17 Dec 1994 04:01:27 -0800
From: Rodney W Grimes <rgrimes@ref.tfs.com>
Message-Id: <199412171201.EAA12283@ref.tfs.com>
Subject: Who has an EISA config file !HIT0001??
To: freebsd-hackers@freebsd.org
Date: Sat, 17 Dec 1994 04:01:27 -0800 (PST)
Content-Type: text
Content-Length: 297
Sender: hackers-owner@freebsd.org
Precedence: bulk
I am in desperate need of the EISA config file for a HiNT motherboard,
the file is called !HIT0001.CFG, any one out there have a copy of it??
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Custom computers for FreeBSD
From owner-freebsd-hackers Sat Dec 17 05:32:33 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id FAA13997 for hackers-outgoing; Sat, 17 Dec 1994 05:32:33 -0800
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id FAA13991 for <freebsd-hackers@freebsd.org>; Sat, 17 Dec 1994 05:32:31 -0800
Received: (from rgrimes@localhost) by ref.tfs.com (8.6.8/8.6.6) id FAA12429; Sat, 17 Dec 1994 05:32:31 -0800
From: Rodney W Grimes <rgrimes@ref.tfs.com>
Message-Id: <199412171332.FAA12429@ref.tfs.com>
Subject: Re: Who has an EISA config file !HIT0001??
To: rgrimes@ref.tfs.com (Rodney W Grimes)
Date: Sat, 17 Dec 1994 05:32:31 -0800 (PST)
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <199412171201.EAA12283@ref.tfs.com> from "Rodney W Grimes" at Dec 17, 94 04:01:27 am
Content-Type: text
Content-Length: 356
Sender: hackers-owner@freebsd.org
Precedence: bulk
>
> I am in desperate need of the EISA config file for a HiNT motherboard,
> the file is called !HIT0001.CFG, any one out there have a copy of it??
Never mind.. some one has gotten a copy to me..
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Custom computers for FreeBSD
From owner-freebsd-hackers Sat Dec 17 07:07:00 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id HAA15339 for hackers-outgoing; Sat, 17 Dec 1994 07:07:00 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id HAA15333 for <hackers@freebsd.org>; Sat, 17 Dec 1994 07:06:57 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.9/8.6.9) with SMTP id HAA00363; Sat, 17 Dec 1994 07:06:50 GMT
X-Authentication-Warning: time.cdrom.com: Host localhost didn't use HELO protocol
To: Morgan Davis <root@io.cts.com>
cc: hackers@freebsd.org
Subject: Re: Error building libncurses
In-reply-to: Your message of "Sat, 17 Dec 94 01:46:04 PST."
<199412170946.BAA04572@io.cts.com>
Date: Sat, 17 Dec 1994 07:06:49 +0000
Message-ID: <362.787648009@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> I am running 2.0 with the original source distribution (circa
> 11/17/94). Today, I ran sup for the first time and updated the whole
> distribution set. Typing "make" in /usr/src revealed some errors.
I suggest a:
cd /usr/src
make beforeinstall
make all
There is a pre-pass that's done in the beforeinstall that moves the
right include files into place. And no, I can't say I've ever liked it
either, but I have nothing better to suggest for now..
> P.S. While I'm here, is there anything I should know before typing
> "make install" in /usr/src? Will it do stupid things like copy the
> updated files in /usr/src/etc to /etc, thus wiping out my previous
> changes to files like ttys and netstart?
No, it's not quite _that_ pathological.. :-)
I suggest `make world', myself. This will also do all the beforeinstall
stuff.
Jordan
From owner-freebsd-hackers Sat Dec 17 12:33:36 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id MAA17481 for hackers-outgoing; Sat, 17 Dec 1994 12:33:36 -0800
Received: from vmbb.cts.com (vmbb.cts.com [192.188.72.18]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id MAA17475 for <hackers@freebsd.org>; Sat, 17 Dec 1994 12:33:35 -0800
Received: from io.cts.com by vmbb.cts.com with smtp
(Smail3.1.28.1 #9) id m0rJ5op-0000HiC; Sat, 17 Dec 94 12:33 PST
Received: (from root@localhost) by io.cts.com (8.6.9/8.6.9) id MAA28715; Sat, 17 Dec 1994 12:30:21 -0800
From: Morgan Davis <root@io.cts.com>
Message-Id: <199412172030.MAA28715@io.cts.com>
Subject: Re: Error building libncurses
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Sat, 17 Dec 1994 12:30:19 -0800 (PST)
Cc: hackers@freebsd.org
In-Reply-To: <362.787648009@time.cdrom.com> from "Jordan K. Hubbard" at Dec 17, 94 07:06:49 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1191
Sender: hackers-owner@freebsd.org
Precedence: bulk
Jordan K. Hubbard writes:
>
> There is a pre-pass that's done in the beforeinstall that moves the
> right include files into place. And no, I can't say I've ever liked it
> either, but I have nothing better to suggest for now..
Thanks, Jordan. I've discovered "make world" and it's been building
for about 8 hours now. It seems that make world first wants to
remove all the object files to begin a full build.
Is 'make world' something that must be done after every 'sup'? Or, it
is safe to 'sup' then do "make all" skipping the object removal part?
I'm sure it depends on just what 'sup' has updated (e.g. libraries
that should be relinked into all the executables). Is there a roadmap
for updates and rebuilds so I don't have to bother you folks with such
basic things?
> No, it's not quite _that_ pathological.. :-)
I didn't think so, but wanted to make sure.
> I suggest `make world', myself. This will also do all the beforeinstall
> stuff.
Yup -- it's progressing nicely.
BTW, where's the manual for "tar"? The built-in "--help" is okay, but
I'm interested in the details such as which levels of gzip compression
are used when you include the 'z' flag, etc. Thanks.
From owner-freebsd-hackers Sat Dec 17 12:56:17 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id MAA17717 for hackers-outgoing; Sat, 17 Dec 1994 12:56:17 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id MAA17711 for <hackers@freebsd.org>; Sat, 17 Dec 1994 12:56:16 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.9/8.6.9) with SMTP id MAA19873; Sat, 17 Dec 1994 12:56:10 GMT
X-Authentication-Warning: time.cdrom.com: Host localhost didn't use HELO protocol
To: Morgan Davis <root@io.cts.com>
cc: hackers@freebsd.org
Subject: Re: Error building libncurses
In-reply-to: Your message of "Sat, 17 Dec 94 12:30:19 PST."
<199412172030.MAA28715@io.cts.com>
Date: Sat, 17 Dec 1994 12:56:09 +0000
Message-ID: <19866.787668969@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
> Is 'make world' something that must be done after every 'sup'? Or, it
> is safe to 'sup' then do "make all" skipping the object removal part?
Well, it sort of depends on what sup updated, as you already surmised.
I just do a make world when I want to get back in sync, and it works
fine for me. The extra degree of certainly is more than worth the
extra compile time (IMHO).
> BTW, where's the manual for "tar"? The built-in "--help" is okay, but
> I'm interested in the details such as which levels of gzip compression
> are used when you include the 'z' flag, etc. Thanks.
Umm. Embarassing ommission, but we've lived without one for many many
months now.. :-) As soon as someone cares to submit one, I'll stick it
in the tree!
Jordan
From owner-freebsd-hackers Sat Dec 17 13:40:33 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id NAA18328 for hackers-outgoing; Sat, 17 Dec 1994 13:40:33 -0800
Received: from cs.pub.ro ([141.85.37.20]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id NAA18226 for <freebsd-hackers@freefall.cdrom.com>; Sat, 17 Dec 1994 13:28:52 -0800
Received: by apolo.cs.pub.ro
(1.38.193.4/15.6) id AA06396; Sat, 17 Dec 1994 20:22:31 +0200
Date: Sat, 17 Dec 1994 20:22:31 +0200
From: Tudor Hulubei <tudor@cs.pub.ro>
Posted-Date: Sat, 17 Dec 1994 20:22:31 +0200
Received-Date: Sat, 17 Dec 1994 20:22:31 +0200
Message-Id: <9412171822.AA06396@apolo.cs.pub.ro>
To: chet@po.cwru.edu
Cc: arnold@cc.gatech.edu, composer@beyond.dreams.org, friedman@gnu.ai.mit.edu,
joshua5@cs.bu.edu, dob@inel.gov, mjo@msen.com, jason@servio.slc.com,
timbo@ig.co.uk, trost@cse.ogi.edu, zoo@armadillo.com,
lubkin@cs.rochester.edu, james@bigtex.cactus.org,
chip%fin@myrddin.sybus.com, dbrooks@ics.com, Greg.Onufer@Eng.Sun.COM,
kre@munnari.oz.au, tmwalden@saturn.sys.acc.com,
torvalds@cc.helsinki.fi, watson@kodak.com, glenn@mathcs.emory.edu,
penningt@reason.psc.edu, devet@adv.iaehv.nl, khera@cs.duke.edu,
grog@lemis.de, djm@eng.umd.edu, wieting@tweety.llnl.gov,
geoff@well.sf.ca.us, de5@ornl.gov, kayvan@satyr.sylvan.com,
smd@uunet.ca, Andy.Linton@aarnet.edu.au, mark@comp.vuw.ac.nz,
david@cs.dal.ca, jwe@che.utexas.edu,
Karl.Kleinpaste@GODIVA.NECTAR.CS.CMU.EDU, bammi@cadence.com,
sanders@bsdi.com, tramey@boi.hp.com, sandro@elf.com,
drich@lerc.nasa.gov, carson@cs.columbia.edu, dbecker@legato.com,
deven@asylum.sf.ca.us, remy@ccs.neu.edu,
freebsd-hackers@freefall.cdrom.com, dtm@nsd.3com.com,
lim@solomon.technet.sg, kjetilho@ifi.uio.no, mwette@csi.jpl.nasa.gov,
jsh@canary.com, gjb@gba.oz.au, andreas@MPA-Garching.MPG.DE,
pgf@foxharp.boston.ma.us, peterc@suite.sw.oz.au, brown@eff.org,
bothner@cygnus.com, fox@cac.washington.edu, chet@odin.INS.CWRU.Edu
In-Reply-To: <9412112218.AA05529.SM@odin.INS.CWRU.Edu> (message from Chet Ramey on Sun, 11 Dec 1994 17:18:57 -0500)
Subject: Re: Test release of bash-1.14.3 available
Sender: hackers-owner@freebsd.org
Precedence: bulk
Hi,
At the first look, compiling bash-1.14.3 on a HP-UX crashes at the very
beginning like this:
(The uname -a result is:
HP-UX apolo A.09.03 A 9000/715 2014801031 two-user license
and the gcc -v result is:
Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.03/2.6.1/specs
gcc version 2.6.1
)
You are about to make this version of GNU Bash for
this architecture for the first time. If you haven't
yet read the README file, you may want to do so. If
you wish to report a bug in Bash, or in the installation
procedure, please run the bashbug script and include:
* a description of the bug,
* a recipe for recreating the bug reliably,
* a fix for the bug if you have one!
/bin/sh ./support/mksysdefs -s .
cp ./cpp-Makefile tmp-Makefile.c
rm -f ./support/getcppsyms
/bin/sh ./support/mkdirs support
cc -o ./support/getcppsyms ./support/getcppsyms.c
rm -f bash-Makefile
/lib/cpp -Dhp9000s700 -Dhp9000s800 -Dhppa -Dhpux -Dunix -P -I. -I. -DCPP_CC=cc tmp-Makefile.c | awk -f ./support/cat-s > bash-Makefile
rm -f tmp-Makefile.c
make -f bash-Makefile srcdir=.
make[1]: Entering directory `/home/student/tudor/src/bash-1.14.3'
cc -O -g -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H
-DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_SYS_PARAM -DVOID_SIGHANDLER
-DNO_SBRK_DECL -DHAVE_SOCKETS -DHAVE_GETHOSTNAME +O3 -Ae -DHPUX -Dhpux
-DHAVE_GETHOSTNAME -DUSG -DHAVE_WAIT_H -DHAVE_DUP2 -DHAVE_STRERROR
-DHAVE_DIRENT -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -D"hp9000s700" -D"hpux_9" -DSHELL -o newversion.aux ./newversion.c
cc: +O3: No such file or directory
*Initialization*:1: missing token-sequence in `#assert'
make[1]: *** [newversion.aux] Error 1
make[1]: Leaving directory `/home/student/tudor/src/bash-1.14.3'
make: *** [all] Error 2
removing +O3 from bash-Makefile doesn't appear to be good enough because
gcc doesn't recognize the -Ae option. Removing both +O3 and -Ae from the
SYSDEP variable appears to be ok. Let's wait...
The link step failed. This appears to be the problem:
make[2]: Leaving directory `/home/student/tudor/src/bash-1.14.3/lib/tilde'
rm -f bash
cc -O -g -L ./lib/readline/ -L ./lib/tilde/ -L ./lib/glob/ -o bash shell.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hash.o mailcheck.o test.o trap.o alias.o ./lib/malloc/alloca.o braces.o unwind_prot.o input.o bashhist.osiglist.o version.o bashline.o bracecomp.o builtins/libbuiltins.a -lreadline -lcurses -lglob -ltilde
/bin/ld: builtins/libbuiltins.a: Missing library symbol table
collect2: ld returned 1 exit status
make[1]: *** [bash] Error 1
make[1]: Leaving directory `/home/student/tudor/src/bash-1.14.3'
make: *** [all] Error 2
The libbuiltins.a library should be ranlib-ed. After
ranlib libbuiltins.a
the linker failed at the next step, the readline library.
This should be ranlib-ed too. The glob & tilde libraries too.
Ok, I did it.
It WORKS !
make test fails like this:
cc test.o -o test
/bin/ld: Unsatisfied symbols:
interactive_shell (data)
current_user (data)
get_name_for_error (code)
xrealloc (code)
main
collect2: ld returned 1 exit status
make: *** [test] Error 1
I don't know. Should this work ? I am not sure.
Anyway, as far as I saw, ./bash works ok.
Until now I've used gcc 2.6.1. I will try the native, non-ANSI, HP-UX C
compiler (a K&R one). Let's see what happens:
(You should note that the native HP-UX C compiler is a very dumb one. It
doesn't understands optimization and debug info flags, so the following
warnings are normal (in its opinion, of course :-) )
cc: warning 422: Unknown option "O" ignored.
cc: warning 422: Unknown option "g" ignored.
cc: warning 422: Unknown option "A" ignored.
cc: warning 422: Unknown option "e" ignored.
Anyway, these are warnings, not errors like when using gcc.
OOPS, some strange warnings here:
cc -c -O -g -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H -DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_SYS_PARAM -DVOID_SIGHANDLER -DNO_SBRK_DECL -DHAVE_SOCKETS-DHAVE_GETHOSTNAME +O3 -Ae -DHPUX -Dhpux -DHAVE_GETHOSTNAME -DUSG -DHAVE_WAIT_H -DHAVE_DUP2 -DHAVE_STRERROR -DHAVE_DIRENT -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -D"hp9000s700" -D"hpux_9" -DSHELL -I/home/student/tudor/src/bash-1.14.3 -I/home/student/tudor/src/bash-1.14.3/./lib/ -I././lib/ -I. -I/home/student/tudor/src/bash-1.14.3/builtins -I. -I. -I././lib/ ulimit.c
cc: warning 422: Unknown option "O" ignored.
cc: warning 422: Unknown option "g" ignored.
cc: warning 422: Unknown option "A" ignored.
cc: warning 422: Unknown option "e" ignored.
cc: "builtins/ulimit.def", line 354: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 686: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 693: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 699: warning 31: String literal contains undefined escape sequence.
rm -f ulimit.c
Hmmm, the same problem with builtins/libbuiltins.a not beeing ranlib-ed.
The other libraries too... (readline, glob, tilde)
ok, got a binary, it works !
make test fails in the same way. Maybe I should not try this, I don't know.
So, the problem is that make doesn't detect the presence of gcc. In fact
/usr/bin is the native HP-UX compiler, gcc is installed in /usr/local/bin
and I have a link to it in my ~/bin directory. You should check the ranlib
part too... It might be my problem because we have both /bin/ranlib (the
native version) and /usr/local/bin/ranlib (the GNU version). I have
/usr/local/bin in PATH *before* /bin so, this might be the problem. But
when I have ranlibed "by hand" the libraries it worked just fine.
If you want to check where those ulimit.def warnings come from and you
need our headers, just send me an email and I will send them uuencoded
to you.
Best regards,
Tudor
From owner-freebsd-hackers Sat Dec 17 13:53:39 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id NAA18470 for hackers-outgoing; Sat, 17 Dec 1994 13:53:39 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id NAA18464 for <hackers@freebsd.org>; Sat, 17 Dec 1994 13:53:37 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA23962; Sat, 17 Dec 94 14:48:57 MST
Date: Sat, 17 Dec 94 14:48:57 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9412172148.AA23962@cs.weber.edu>
To: kurto@tiny.mcs.usu.edu, sos@kmd-ac.dk
Subject: Re: Using graphics under syscons (src)
Cc: hackers@freebsd.org, mark@grondar.za
Sender: hackers-owner@freebsd.org
Precedence: bulk
Soren writes:
> > Also in a previous message you mentioned that directly going to the hardware
> > required root privs. How about extending syscons to support a more general
> > VGA driver with ioctl's for setting various VGA registers, this would allow
> > for mode-x programming, etc.
>
> Hmm, the problem is one have to decide where to stop this, you VERY
> quickly get into situations where you have to treat diffent VGA chips
> differently, and I have _*NO*_ intention of trying to support all
> possible video hardware (try ask the XFree guys about this :-)
> I do however see that we need a way of allowing writes to the VGA
> registers of "normal" hardware. As I remember the ibcs/sysv ioctl
> set has some functions for this. The problem here is speed, if you
> wan't "live" graphics you want speed over security, and then you
> HAVE to have access directly to the hardware so you will need root
> privs. Another way was to allow access to specific port numbers,
> but I dont think the kernel supports this at this time (or if it
> ever will).
Another way to allow access to the ardware directly is using a mapping
into the applications virtual address space of the device memory or
device memory backing store (depending on if the application on a
particular virtual console owned the real console), with the backing
store being used instead of the device memory if the thing didn't own
the real hardware.
This gets around the mapping aspect of the "root priveledges" problem.
The other component of the "root priveledges" problem is modifications
to hardware state by knowledge of registers/state control through ports,
as wired into particular programs.
This requires a hardware abstraction.
By default, I agree with Soren; the support of special modes for VGA
chips is too complex to use by default.
HOWEVER, the modes are not "too difficult period", just "too difficult for
this to be the default behaviour". This is a subtle distinction. The
suggestion I would make would be to abstract the VGA interface from the
card interface. In its simplest form, this would result in knowing the
contents of typically write-only registers so that mode settings could
always be restored *IF* the mode setting was done through the abstraction.
The second level of support would include emulation of VGA modes and SupreVGA
by way of an INT-10 abstraction interface using a VM86() call of some kind.
Thus it would be possible to select modes from a list of available modes
without wiring explicit knowledge of the hardware into a driver -- the
trade of being the requirement for VM86() support.
A third level of support could be obtained by providing a kernel environment
emulation framework. This sounds more complicated than it is. Basically,
you provide an environment so that NT and Windows 95 (both protected mode
OS's) video drivers *think* they are running in their native environment.
Then you simply use manufacturer supplied drivers.
The upshot is that the actual work done in all these cases does not include
card-specific drivers.
There *ought* to be the possibility of card specific drivers, however --
what I have, in the past, called "moving DDX into the kernel".
The end result of the majority of this work would be the ability to
remove knowledge of specific cards from, among other things, generic X
support, and to abstract it from the console code (there is currently a
limitation on the support of loading ISO8859-1 character sets on console
hardware that I believe should be removed).
As a final incentive for change,DOS emulation and things like "DOOM" require
access to the hardware. But do they really? What they want is something
that looks to the program like it has access to the hardware.
In reality, what it wants is the top level of the hardware abstraction; but
in fact, the underlying driver could be any user supplied driver. Including
a driver that acted as a client to X, or one that mapped a region of a cards
linear frame buffer as a VGA card, and allowed relocation of the origin of
the rectangle within X by virtue of window geometry notification... the
applications for video under X and mpeg/quicktime/CDTV should be obvious.
Finally, a library front end to the abstraction, in the form of a callable
"INT10(3)" interface would make porting from DOS simplistic.
> > ps - as far as a game I would like to see, how about practically any
> > of the older arcade games. especially joust, any pacman, etc.
>
> This tend to be the trend in all answers I've got :-)
Star Castle! 8-).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-hackers Sat Dec 17 14:05:47 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id OAA18589 for hackers-outgoing; Sat, 17 Dec 1994 14:05:47 -0800
Received: from europa.com (root@ratcliff.europa.com [199.2.194.11]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id OAA18579 for <hackers@freebsd.org>; Sat, 17 Dec 1994 14:05:45 -0800
Received: by europa.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0rJ7Ee-000BXXC@europa.com>; Sat, 17 Dec 94 14:04 GMT
Message-Id: <m0rJ7Ee-000BXXC@europa.com>
Date: Sat, 17 Dec 94 14:05 GMT
From: timb@europa.com (Tim Bach)
To: hackers@freebsd.org
Sender: hackers-owner@freebsd.org
Precedence: bulk
Ok i am having trouble getting mshell working.Basicly it works when i telnet in local but when somebody dials in it dies on signal 11's.
That's using mgetty and mshell under 1.1.5 and 2.0..
Any clues?
From owner-freebsd-hackers Sat Dec 17 16:22:23 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA21332 for hackers-outgoing; Sat, 17 Dec 1994 16:22:23 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id QAA21321 for <freebsd-hackers@freebsd.org>; Sat, 17 Dec 1994 16:22:21 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA26610; Sat, 17 Dec 94 17:17:39 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9412180017.AA26610@cs.weber.edu>
Subject: Re: telnet "daemon" for Novell NetWare
To: karant@gallium.csusb.edu (Dr. Yasha Karant)
Date: Sat, 17 Dec 94 17:17:38 MST
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <9412150106.AA12202@gallium.csusb.edu>; from "Dr. Yasha Karant" at Dec 14, 94 5:06 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: hackers-owner@freebsd.org
Precedence: bulk
[ ... per subject ... ]
> Their immediate plan is to put two 802.3 10Base cards in the Novell
> server; one of these cards will run only the present Novell
> IPX/SPX/... proprietary stack, the other is intended to run a TCP/IP/...
> stack so that external machines can initiate telnet sessions into the
> Novell NetWare `server ("fire up a Novell login"). What is the equivalent
> of the daemon in the NetWare world which responds to telnet? Is there
> any source code or free (PD, shareware, GPL, ... ) software to do
> this? Any suggestions on whom to contact?
There is a routing IPX for Linux; it's not very diffivult to make one.
IPX is now documented, and the docs are available from Novell (you
got me on who'd you talk to -- I haven't a clue there).
The "gateway" function could probably be handled by either setting
out a 'pad' as if it were a modem pool (there is an INT14 redirector
for modem sharing) and having the 'pad' pretending it's a modem
server, but when you connect, giving a telnet> style prompt.
The only other alternative is a winsock.dll or other type of "apparent"
TCP/IP interface from the client application perspective that talks
IPX to a gateway program.
AT&T's LANMAN offering has this -- they call it "TAP" or "TCP Access
Program" that talks SMB to a client that talks SMB.
If you take this route, it's probably be quite easy to start with
say the "term" stuff ("Term" the TCP access program for UNIX) and
modify it.
At one time I wrote something similar to the AT&T stuff for NetWare
assuming UnixWare or some other UNIX with a TLI accessable IPX
implementation, but I could neither convinve Novell to sell it nor
convince them to let me give it away. Part of the problem is that
it had to have an assigned number to let it SAP out of, and they
wouldn't assign one to the service type.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-hackers Sat Dec 17 16:28:57 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA21884 for hackers-outgoing; Sat, 17 Dec 1994 16:28:57 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id QAA21878 for <hackers@freebsd.org>; Sat, 17 Dec 1994 16:28:54 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA26627; Sat, 17 Dec 94 17:24:08 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9412180024.AA26627@cs.weber.edu>
Subject: Re: syscons & multiple Xservers?
To: dawes@physics.su.oz.au (David Dawes)
Date: Sat, 17 Dec 94 17:24:07 MST
Cc: kaleb@x.org, hackers@freebsd.org
In-Reply-To: <199412160146.AA10014@physics.su.OZ.AU>; from "David Dawes" at Dec 16, 94 12:46 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: hackers-owner@freebsd.org
Precedence: bulk
[ ... multiple X servers with just one console ... ]
> The race condition is when two servers try to initialise the video
> hardware at the same time. It should be possible to prevent the second
> one from accessing the hardware until the first one has got the point
> where it can allow a VT switch providing that there is at least a little
> delay between when they start. I don't know if this requires changes
> in syscons, XFree86 or both (I suspect both).
This worked fine in 1.1. It's the console interface that changed.
I suspect no X changes are needed. The problem is that locking the
resource is necessary, and you have to lock it over the entire
critical section. Right now the critical sections are allowed to
interleave.
In point of fact, you *can* start up two servers.
You just have to *never* switch directly between the servers without
switching to a vanilla console in between.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-hackers Sat Dec 17 16:48:05 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id QAA22785 for hackers-outgoing; Sat, 17 Dec 1994 16:48:05 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id QAA22778; Sat, 17 Dec 1994 16:48:03 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA26661; Sat, 17 Dec 94 17:43:24 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9412180043.AA26661@cs.weber.edu>
Subject: Re: DataBases
To: gclarkii@freefall.cdrom.com (Gary Clark II)
Date: Sat, 17 Dec 94 17:43:23 MST
Cc: hackers@freefall.cdrom.com
In-Reply-To: <199412170321.TAA07124@freefall.cdrom.com>; from "Gary Clark II" at Dec 16, 94 7:21 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: hackers-owner@freebsd.org
Precedence: bulk
> As a follow up to the announcement of the msql DB stuff, I also have
> Typhoon RDBM ported to FreeBSD-2.0 and it is also bmaked. This a
> RDBM styled after RAIMA(sic) DB_Vista system. There docs are a little sparse
> but it looks like it could be a very good foundation for a system.
> It is copywrited but freeware.
>
> If anyone wants a copy of it, please email me and I will put it up for FTP.
DB Vista is an associative database.
Is this also an associative database?
Specifically, can I give n search keys (where n is some reasonable number
less than 15) and it will produce a hit frequency ordered list of
matches?
I used DB Vista to implement a technical support database for a previous
employer some 7-8 years ago, and after rewriting all the error messages
to provide keywords in the product, it really sped support and reduced
phone time.
One thing that DB Vista also let me do is hit-frequency sort the problem
soloution pairs within each set of equal hitcounts so that the first
thing the technical support operator gave them was the most frequent
soloution to the problem/key set.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-hackers Sat Dec 17 17:24:00 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id RAA24003 for hackers-outgoing; Sat, 17 Dec 1994 17:24:00 -0800
Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id RAA23997 for <hackers@FreeBSD.org>; Sat, 17 Dec 1994 17:23:58 -0800
Received: by cs.weber.edu (4.1/SMI-4.1.1)
id AA26706; Sat, 17 Dec 94 18:13:01 MST
From: terry@cs.weber.edu (Terry Lambert)
Message-Id: <9412180113.AA26706@cs.weber.edu>
Subject: LKMs: limits to utility
To: joerg_wunsch@uriah.sax.de
Date: Sat, 17 Dec 94 18:13:00 MST
Cc: hackers@freebsd.org
In-Reply-To: <199412161744.SAA00693@julia.tcd-dresden.de>; from "J Wunsch" at Dec 16, 94 6:43 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: hackers-owner@freebsd.org
Precedence: bulk
> |
> | Just a thought : would trying to put the sound cards drivers as different
> | lkms a bad idea instead of getting the kernel much bigger ?
>
> Now that everybody's speaking of LKM's, is there any documentation
> available outside?
I want to caution against the "I have a hammer, now everything's a nail"
approach to the use of LKMs. Not that this is what I think you are
suggesting, but that's where the current track seems headed.
Specifically, LKMs as they are currently written are useful for:
1) Loading/Unloading kernel parts during developement to
save reboot time. This assumes the module, when loaded,
does not result in a kernel panic.
2) Boot-time loading of drivers that are never unloaded.
They are *not* useful for general load/probe/fail_probe/unload.
This is because there is no distinction between high, medium, and low
persistance uses of kernel memory.
The probe wants to be low persistance. This implies that the probe
is either a sperate file or a seperate code segment in a single coff or
elf file containing the rest of the module runtime.
The modules themselves want to be either medium (demand loaded and
developer loaded) or high (boot time loaded, device access time
demand loaded).
Current kernel memory management assume high persistance objects are
loaded at boot time (the kernel itself) or closely thereafter.
In a developement environement, you can afford the fragmentation of
kernel memory that loading and unloading without collapsing the
memory pools will cause, but this is not acceptable in a production
system.
I believe that the following *must* be done before everything ends
up being modularized:
1) The linking must be against a kernel symbol list that is
maintained apart from the kernel image itself. Currently
there is a problem with module interdependency based on
the link order and the resulting object file when the
modules are linked against the kernel symbol table. This
can not be resolved such that non-interdependent but time
order previously linked modules can be unloaded without
needing to reverse the load order.
2) As part of this, ideally, symbol resoloution would take place
in the kernel itself (the module being loaded with vn_lookup()
followed by vn_read's of the module data). Currently the
module is pushed from user space into kernel space 512 bytes
at a time after:
i) The module is linked once against the kernel symbol
table with a relocation offset of 0 to get a relocated
object.
ii) The resulting object is checked for size.
iii) Contiguous memory aligned on a page boundry sufficient
to contain the module is allocated and the kernel
allocation address is passed back. This memory need
only be contiguous i the kernel address space and not
physically contiguous.
iv) The module is relinked again against the kernel symbol
table with a relocation offset equal to the start of
the contiguous memory segment.
This is all vastly more time consuming and error-prone than it
needs to be.
Pushing the symbol resoloution into the kernel will also allow
the auto-export of symbols to the kernel symbol list. For
instance, the exporting of symbols by an IP module for use by
both a UDP and a TCP module.
3) At *least* "high/low" persistance pools must be established for
kernel memory objects. I'd suggest halving the kernel virtual
address space and allocating the low persistance stuff following
the boundry and the high persistance stuff prior to the boundry
(or vice versa -- I really don't care about the implementation
details). There needs to be a mapping mechanism that allows
"promotion" of low persistance obcts to be high persistance
objects. This resolves the "probe" problem. If the device probes
as being there, the module containing it is promoted.
It should also be noted that as it stands, the LKM system was never
intended for general use this way. It was an expedient hack by me to
server the dual purpose of allowing me to load execution classes when I
was doing initial work on share libraries in late 92/early 93 and to
support the console working groups ability to load, among other things,
emulation modules.
With that in mind, my feelings would not be hurt by going back and
reconsidering the entire design -- in fact, I'd recommend it.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
From owner-freebsd-hackers Sat Dec 17 18:45:03 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id SAA24932 for hackers-outgoing; Sat, 17 Dec 1994 18:45:03 -0800
Received: from tiny.mcs.usu.edu (tiny.mcs.usu.edu [129.123.15.8]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id SAA24925 for <hackers@freebsd.org>; Sat, 17 Dec 1994 18:45:01 -0800
Received: by tiny.mcs.usu.edu (8.6.8/1.34)
id VAA07410; Sat, 17 Dec 1994 21:12:26 -0700
Date: Sat, 17 Dec 1994 21:12:26 -0700
From: kurto@tiny.mcs.usu.edu (Kurt Olsen)
Message-Id: <199412180412.VAA07410@tiny.mcs.usu.edu>
To: hackers@freebsd.org
Subject: boottime device configuration
Sender: hackers-owner@freebsd.org
Precedence: bulk
I just had an interesting idea and thought I would get other people
's opinions. Now that there is the facility to reconfigure devices at
boottime, why not have a /dev_config or something that would hold a list
of device configurations. This was when a person changes how their hardware
is setup, it won't require a full recompile. Plus for people not interested
in recompiling a kernel, it would allow them to change the setup of the
generic kernels.
I'm not sure how difficult it would be to read a file, but this seems like
it would be quite helpful. I was also thinking of moving many devices out
to LKMs, but from reading Terry's reply, maybe that's not such a good idea.
However if the devices were written correctly (ie. load at boot time and
stay that way,) we could make a kernel that had minimal support and then
provide a bunch of LKMs that could be loaded depending on a person's hardware.
This would look really nice to people who didn't feel quite adept at building
up a kernel. Plus make it really easy to do binary upgrades of different
device drivers.
Kurt Olsen
From owner-freebsd-hackers Sat Dec 17 18:57:43 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id SAA25020 for hackers-outgoing; Sat, 17 Dec 1994 18:57:43 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id SAA25012 for <hackers@freebsd.org>; Sat, 17 Dec 1994 18:57:00 -0800
Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id SAA08795; Sat, 17 Dec 1994 18:55:49 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id SAA01031; Sat, 17 Dec 1994 18:55:48 -0800
Message-Id: <199412180255.SAA01031@corbin.Root.COM>
X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol
To: kurto@tiny.mcs.usu.edu (Kurt Olsen)
cc: hackers@freebsd.org
Subject: Re: boottime device configuration
In-reply-to: Your message of "Sat, 17 Dec 94 21:12:26 MST."
<199412180412.VAA07410@tiny.mcs.usu.edu>
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sat, 17 Dec 1994 18:55:14 -0800
Sender: hackers-owner@freebsd.org
Precedence: bulk
>
>I just had an interesting idea and thought I would get other people
>'s opinions. Now that there is the facility to reconfigure devices at
>boottime, why not have a /dev_config or something that would hold a list
>of device configurations. This was when a person changes how their hardware
>is setup, it won't require a full recompile. Plus for people not interested
>in recompiling a kernel, it would allow them to change the setup of the
>generic kernels.
>
>I'm not sure how difficult it would be to read a file, but this seems like
>it would be quite helpful. I was also thinking of moving many devices out
>to LKMs, but from reading Terry's reply, maybe that's not such a good idea.
>However if the devices were written correctly (ie. load at boot time and
>stay that way,) we could make a kernel that had minimal support and then
>provide a bunch of LKMs that could be loaded depending on a person's hardware.
>This would look really nice to people who didn't feel quite adept at building
>up a kernel. Plus make it really easy to do binary upgrades of different
>device drivers.
All of the above has been heavily discussed over the past 4 months or so,
and the idea is generally the direction that we're headed. It's still unclear
if we will be storing the device configuration information in the kernel
binary somehow or if it will be stored in a seperate file. Do the latter
either complicates the boot code or creates a chicken-and-egg problem for
the configuration of the boot device.
-DG
From owner-freebsd-hackers Sat Dec 17 19:17:51 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id TAA25291 for hackers-outgoing; Sat, 17 Dec 1994 19:17:51 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.223.46]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id TAA25273; Sat, 17 Dec 1994 19:17:34 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.9/8.6.9) with SMTP id TAA08238; Sat, 17 Dec 1994 19:17:57 GMT
X-Authentication-Warning: time.cdrom.com: Host localhost didn't use HELO protocol
To: hackers@freebsd.org
cc: current@freebsd.org
Subject: Don't scream..
Date: Sat, 17 Dec 1994 19:17:56 +0000
Message-ID: <8237.787691876@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk
Let me tell you the story of a little CDROM company who could never
quite manage to do a FreeBSD release without *something* going wrong.
1.0 begat 1.0.2, then 1.1 begat another 1.1 without mastering errors,
and then finally 2.0, out of the woods technically speaking with me at
the helm, fell prey to the art department. All the CDs say "January
1994" on them, which would be a neat trick indeed. Since I wasn't
here when the artwork came back, I only noticed it the day I arrived.
Since the error is only typographic in nature, CDs continue to go out
the door, but it still rankles us here and so we have decided to do
another reprinting of the covers, CDs and other misprinted material
associated with it. While we were reprinting the CDs, I inquired as
to whether or not another _master_ image might be sent for
duplication, and I was informed that yes, this was quite possible.
I therefore put it to you, the members of -hackers and -current,
whether or not you'd care to see (wait for it)..
FreeBSD 2.0.5!
[Aiieee!!]
I've talked to both Poul-Henning Kamp and David Greenman about this,
and we all think that a snap-shot of FreeBSD-current under the
brand-name (and version) of 2.0.5 is quite possible, and perhaps even
eminently desirable. Sure, there will be some bugs in -current.
There were also some pretty _embarassing_ bugs in 2.0R, like the one
that allows you to change anyone else's password, or the install
floppies from hell that only supported the CD installation method.
I'm sure anyone reviewing the commit logs between 2.0R and 2.0C can
find others. What we need to determine is which bugs are _worse_.
Assuming that Poul-Henning and I can pull this off tomorrow, and we're
pretty sure that we can, the question still remains: "Should we?" If
we don't, then the world doesn't end, it just means that we skip
remastering and only change the bogus artwork. If we do, then it has
to be done by Monday morning before the parcel goes off to the
printer/duplication house. If we do change it, then the artwork will
also be changed to read "2.0.5" (January 1995 :-).
Oh yes, all people who got 2.0 CDs (no matter where they purchased
them from) will also get the updated 2.0.5 CDs free of charge, so our
existing customer base will be happy. That's not an issue. The issue
is whether or not people here want to see it.
Please send me your thoughts on this matter. I will react by reading
all of them, thinking for a few minutes, then sticking my finger in
the air to see what final decision I want to make.
Thanks!
Jordan
From owner-freebsd-hackers Sat Dec 17 20:10:25 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id UAA26430 for hackers-outgoing; Sat, 17 Dec 1994 20:10:25 -0800
Received: from kryten.atinc.com (kryten.atinc.com [198.138.38.7]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id UAA26424; Sat, 17 Dec 1994 20:10:22 -0800
Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id XAA15781; Sat, 17 Dec 1994 23:06:55 -0500
Date: Sat, 17 Dec 1994 23:06:54 -0500 (EST)
From: "Jonathan M. Bresler" <jmb@kryten.atinc.com>
Subject: Re: Don't scream..
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
cc: hackers@freebsd.org, current@freebsd.org
In-Reply-To: <8237.787691876@time.cdrom.com>
Message-ID: <Pine.3.89.9412172339.B13156-0100000@kryten.atinc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: hackers-owner@freebsd.org
Precedence: bulk
go for 2.0.5 the floppies from hell are enough to justify
remastering for customers. it just looks bad that the other methods of
install fail, but the cdrom install goes okay. in this cynical day and
age, i dont know what people might think. besides a lot of other things
have been fixed as well.
good to hear that the cdroms are selling well enough that a
remastering is already possible.
Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc.
| 2341 Jeff Davis Hwy
play go. | Arlington, VA 22202
ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346
From owner-freebsd-hackers Sat Dec 17 21:08:22 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id VAA27123 for hackers-outgoing; Sat, 17 Dec 1994 21:08:22 -0800
Received: from cs.pub.ro (apolo.cs.pub.ro [141.85.37.20]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id VAA27061 for <freebsd-hackers@freefall.cdrom.com>; Sat, 17 Dec 1994 21:00:44 -0800
Received: by apolo.cs.pub.ro
(1.38.193.4/15.6) id AA06396; Sat, 17 Dec 1994 20:22:31 +0200
Date: Sat, 17 Dec 1994 20:22:31 +0200
From: Tudor Hulubei <tudor@cs.pub.ro>
Posted-Date: Sat, 17 Dec 1994 20:22:31 +0200
Received-Date: Sat, 17 Dec 1994 20:22:31 +0200
Message-Id: <9412171822.AA06396@apolo.cs.pub.ro>
To: chet@po.cwru.edu
Cc: arnold@cc.gatech.edu, composer@beyond.dreams.org, friedman@gnu.ai.mit.edu,
joshua5@cs.bu.edu, dob@inel.gov, mjo@msen.com, jason@servio.slc.com,
timbo@ig.co.uk, trost@cse.ogi.edu, zoo@armadillo.com,
lubkin@cs.rochester.edu, james@bigtex.cactus.org,
chip%fin@myrddin.sybus.com, dbrooks@ics.com, Greg.Onufer@Eng.Sun.COM,
kre@munnari.oz.au, tmwalden@saturn.sys.acc.com,
torvalds@cc.helsinki.fi, watson@kodak.com, glenn@mathcs.emory.edu,
penningt@reason.psc.edu, devet@adv.iaehv.nl, khera@cs.duke.edu,
grog@lemis.de, djm@eng.umd.edu, wieting@tweety.llnl.gov,
geoff@well.sf.ca.us, de5@ornl.gov, kayvan@satyr.sylvan.com,
smd@uunet.ca, Andy.Linton@aarnet.edu.au, mark@comp.vuw.ac.nz,
david@cs.dal.ca, jwe@che.utexas.edu,
Karl.Kleinpaste@GODIVA.NECTAR.CS.CMU.EDU, bammi@cadence.com,
sanders@bsdi.com, tramey@boi.hp.com, sandro@elf.com,
drich@lerc.nasa.gov, carson@cs.columbia.edu, dbecker@legato.com,
deven@asylum.sf.ca.us, remy@ccs.neu.edu,
freebsd-hackers@freefall.cdrom.com, dtm@nsd.3com.com,
lim@solomon.technet.sg, kjetilho@ifi.uio.no, mwette@csi.jpl.nasa.gov,
jsh@canary.com, gjb@gba.oz.au, andreas@MPA-Garching.MPG.DE,
pgf@foxharp.boston.ma.us, peterc@suite.sw.oz.au, brown@eff.org,
bothner@cygnus.com, fox@cac.washington.edu, chet@odin.INS.CWRU.Edu
In-Reply-To: <9412112218.AA05529.SM@odin.INS.CWRU.Edu> (message from Chet Ramey on Sun, 11 Dec 1994 17:18:57 -0500)
Subject: Re: Test release of bash-1.14.3 available
Sender: hackers-owner@freebsd.org
Precedence: bulk
Hi,
At the first look, compiling bash-1.14.3 on a HP-UX crashes at the very
beginning like this:
(The uname -a result is:
HP-UX apolo A.09.03 A 9000/715 2014801031 two-user license
and the gcc -v result is:
Reading specs from /usr/local/lib/gcc-lib/hppa1.1-hp-hpux9.03/2.6.1/specs
gcc version 2.6.1
)
You are about to make this version of GNU Bash for
this architecture for the first time. If you haven't
yet read the README file, you may want to do so. If
you wish to report a bug in Bash, or in the installation
procedure, please run the bashbug script and include:
* a description of the bug,
* a recipe for recreating the bug reliably,
* a fix for the bug if you have one!
/bin/sh ./support/mksysdefs -s .
cp ./cpp-Makefile tmp-Makefile.c
rm -f ./support/getcppsyms
/bin/sh ./support/mkdirs support
cc -o ./support/getcppsyms ./support/getcppsyms.c
rm -f bash-Makefile
/lib/cpp -Dhp9000s700 -Dhp9000s800 -Dhppa -Dhpux -Dunix -P -I. -I. -DCPP_CC=cc tmp-Makefile.c | awk -f ./support/cat-s > bash-Makefile
rm -f tmp-Makefile.c
make -f bash-Makefile srcdir=.
make[1]: Entering directory `/home/student/tudor/src/bash-1.14.3'
cc -O -g -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H
-DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_SYS_PARAM -DVOID_SIGHANDLER
-DNO_SBRK_DECL -DHAVE_SOCKETS -DHAVE_GETHOSTNAME +O3 -Ae -DHPUX -Dhpux
-DHAVE_GETHOSTNAME -DUSG -DHAVE_WAIT_H -DHAVE_DUP2 -DHAVE_STRERROR
-DHAVE_DIRENT -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -D"hp9000s700" -D"hpux_9" -DSHELL -o newversion.aux ./newversion.c
cc: +O3: No such file or directory
*Initialization*:1: missing token-sequence in `#assert'
make[1]: *** [newversion.aux] Error 1
make[1]: Leaving directory `/home/student/tudor/src/bash-1.14.3'
make: *** [all] Error 2
removing +O3 from bash-Makefile doesn't appear to be good enough because
gcc doesn't recognize the -Ae option. Removing both +O3 and -Ae from the
SYSDEP variable appears to be ok. Let's wait...
The link step failed. This appears to be the problem:
make[2]: Leaving directory `/home/student/tudor/src/bash-1.14.3/lib/tilde'
rm -f bash
cc -O -g -L ./lib/readline/ -L ./lib/tilde/ -L ./lib/glob/ -o bash shell.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hash.o mailcheck.o test.o trap.o alias.o ./lib/malloc/alloca.o braces.o unwind_prot.o input.o bashhist.osiglist.o version.o bashline.o bracecomp.o builtins/libbuiltins.a -lreadline -lcurses -lglob -ltilde
/bin/ld: builtins/libbuiltins.a: Missing library symbol table
collect2: ld returned 1 exit status
make[1]: *** [bash] Error 1
make[1]: Leaving directory `/home/student/tudor/src/bash-1.14.3'
make: *** [all] Error 2
The libbuiltins.a library should be ranlib-ed. After
ranlib libbuiltins.a
the linker failed at the next step, the readline library.
This should be ranlib-ed too. The glob & tilde libraries too.
Ok, I did it.
It WORKS !
make test fails like this:
cc test.o -o test
/bin/ld: Unsatisfied symbols:
interactive_shell (data)
current_user (data)
get_name_for_error (code)
xrealloc (code)
main
collect2: ld returned 1 exit status
make: *** [test] Error 1
I don't know. Should this work ? I am not sure.
Anyway, as far as I saw, ./bash works ok.
Until now I've used gcc 2.6.1. I will try the native, non-ANSI, HP-UX C
compiler (a K&R one). Let's see what happens:
(You should note that the native HP-UX C compiler is a very dumb one. It
doesn't understands optimization and debug info flags, so the following
warnings are normal (in its opinion, of course :-) )
cc: warning 422: Unknown option "O" ignored.
cc: warning 422: Unknown option "g" ignored.
cc: warning 422: Unknown option "A" ignored.
cc: warning 422: Unknown option "e" ignored.
Anyway, these are warnings, not errors like when using gcc.
OOPS, some strange warnings here:
cc -c -O -g -DHAVE_VFPRINTF -DHAVE_UNISTD_H -DHAVE_STDLIB_H -DHAVE_LIMITS_H -DHAVE_GETGROUPS -DHAVE_SYS_PARAM -DVOID_SIGHANDLER -DNO_SBRK_DECL -DHAVE_SOCKETS-DHAVE_GETHOSTNAME +O3 -Ae -DHPUX -Dhpux -DHAVE_GETHOSTNAME -DUSG -DHAVE_WAIT_H -DHAVE_DUP2 -DHAVE_STRERROR -DHAVE_DIRENT -DHAVE_DIRENT_H -DHAVE_STRING_H -DHAVE_VARARGS_H -DHAVE_STRCHR -D"hp9000s700" -D"hpux_9" -DSHELL -I/home/student/tudor/src/bash-1.14.3 -I/home/student/tudor/src/bash-1.14.3/./lib/ -I././lib/ -I. -I/home/student/tudor/src/bash-1.14.3/builtins -I. -I. -I././lib/ ulimit.c
cc: warning 422: Unknown option "O" ignored.
cc: warning 422: Unknown option "g" ignored.
cc: warning 422: Unknown option "A" ignored.
cc: warning 422: Unknown option "e" ignored.
cc: "builtins/ulimit.def", line 354: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 686: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 693: warning 31: String literal contains undefined escape sequence.
cc: "builtins/ulimit.def", line 699: warning 31: String literal contains undefined escape sequence.
rm -f ulimit.c
Hmmm, the same problem with builtins/libbuiltins.a not beeing ranlib-ed.
The other libraries too... (readline, glob, tilde)
ok, got a binary, it works !
make test fails in the same way. Maybe I should not try this, I don't know.
So, the problem is that make doesn't detect the presence of gcc. In fact
/usr/bin is the native HP-UX compiler, gcc is installed in /usr/local/bin
and I have a link to it in my ~/bin directory. You should check the ranlib
part too... It might be my problem because we have both /bin/ranlib (the
native version) and /usr/local/bin/ranlib (the GNU version). I have
/usr/local/bin in PATH *before* /bin so, this might be the problem. But
when I have ranlibed "by hand" the libraries it worked just fine.
If you want to check where those ulimit.def warnings come from and you
need our headers, just send me an email and I will send them uuencoded
to you.
Best regards,
Tudor
From owner-freebsd-hackers Sat Dec 17 22:41:04 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id WAA27784 for hackers-outgoing; Sat, 17 Dec 1994 22:41:04 -0800
Received: from tiny.mcs.usu.edu (tiny.mcs.usu.edu [129.123.15.8]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id WAA27778 for <hackers@freebsd.org>; Sat, 17 Dec 1994 22:41:01 -0800
Received: by tiny.mcs.usu.edu (8.6.8/1.34)
id BAA07709; Sun, 18 Dec 1994 01:08:31 -0700
Date: Sun, 18 Dec 1994 01:08:31 -0700
From: kurto@tiny.mcs.usu.edu (Kurt Olsen)
Message-Id: <199412180808.BAA07709@tiny.mcs.usu.edu>
To: hackers@freebsd.org
Subject: Re: boottimedevice configuration
Sender: hackers-owner@freebsd.org
Precedence: bulk
> All of the above has been heavily discussed over the past 4 months or so,
>and the idea is generally the direction that we're headed. It's still unclear
>if we will be storing the device configuration information in the kernel
>binary somehow or if it will be stored in a seperate file. Do the latter
>either complicates the boot code or creates a chicken-and-egg problem for
>the configuration of the boot device.
>
>-DG
I would go with the current scheme of having some compile time
defaults. Then using the -c option in the kernel a user could change
the settings on a temporary basis to get it booted. Then if they don't
want to recompile they could create a file to setup the changes for the
next boot. As for changing the boot device, why not allow this bit of
information to be written directly to the boot code. I'm not sure
exactly what would required for this, but it seems like a useful
feature.
Kurt Olsen
kurto@cc.usu.edu
ps - I'm still waiting for someone to give an opinion of what to do
about drand48 and friends.
pps - I'm also still wondering if anyone can help me with some code
for identifying a Cyrix 486DX2 (not a DLC.) I've talked with
Cyrix and got a callback so I'm really happy, but their suggestion
was to send them the code and they'll see if they can figure it
out. Needless to say the only reasonably way I can see to get them
the code would be a CD, maybe after the new year.
From owner-freebsd-hackers Sat Dec 17 23:22:36 1994
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id XAA27929 for hackers-outgoing; Sat, 17 Dec 1994 23:22:36 -0800
Received: from physics.su.OZ.AU (dawes@physics.su.OZ.AU [129.78.129.1]) by freefall.cdrom.com (8.6.8/8.6.6) with SMTP id XAA27923 for <hackers@freebsd.org>; Sat, 17 Dec 1994 23:22:33 -0800
Received: by physics.su.OZ.AU id AA25280
(5.67b/IDA-1.4.4 for hackers@freebsd.org); Sun, 18 Dec 1994 18:22:17 +1100
From: David Dawes <dawes@physics.su.oz.au>
Message-Id: <199412180722.AA25280@physics.su.OZ.AU>
Subject: Re: syscons & multiple Xservers?
To: terry@cs.weber.edu (Terry Lambert)
Date: Sun, 18 Dec 1994 18:22:16 +1100 (EST)
Cc: dawes@physics.su.oz.au, kaleb@x.org, hackers@freebsd.org
In-Reply-To: <9412180024.AA26627@cs.weber.edu> from "Terry Lambert" at Dec 17, 94 05:24:07 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1013
Sender: hackers-owner@freebsd.org
Precedence: bulk
>[ ... multiple X servers with just one console ... ]
>
>> The race condition is when two servers try to initialise the video
>> hardware at the same time. It should be possible to prevent the second
>> one from accessing the hardware until the first one has got the point
>> where it can allow a VT switch providing that there is at least a little
>> delay between when they start. I don't know if this requires changes
>> in syscons, XFree86 or both (I suspect both).
>
>This worked fine in 1.1. It's the console interface that changed.
>
>I suspect no X changes are needed. The problem is that locking the
>resource is necessary, and you have to lock it over the entire
>critical section. Right now the critical sections are allowed to
>interleave.
>
>In point of fact, you *can* start up two servers.
Yes.
>You just have to *never* switch directly between the servers without
>switching to a vanilla console in between.
I've never had any problem switching directly from one server to another.
David