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 ; 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 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 ; 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 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 ; 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 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" 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 ; 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 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 ; 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 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" 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 ; 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 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 ; 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 ; Sat, 17 Dec 1994 14:05:45 -0800 Received: by europa.com (/\==/\ Smail3.1.28.1 #28.15) id ; Sat, 17 Dec 94 14:04 GMT Message-Id: 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 ; 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 ; 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 ; 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 ; 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 ; 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 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" 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" Subject: Re: Don't scream.. To: "Jordan K. Hubbard" cc: hackers@freebsd.org, current@freebsd.org In-Reply-To: <8237.787691876@time.cdrom.com> Message-ID: 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 ; 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 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 ; 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 ; 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 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