From owner-freebsd-hackers Sun Jul 20 08:28:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA20335 for hackers-outgoing; Sun, 20 Jul 1997 08:28:35 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA20330 for ; Sun, 20 Jul 1997 08:28:31 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA00517 (5.67b/IDA-1.5 for FreeBSD-hackers@freebsd.org); Sun, 20 Jul 1997 17:28:47 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id RAA02191 for FreeBSD-hackers@freebsd.org; Sun, 20 Jul 1997 17:26:06 +0200 (MET DST) From: Wilko Bulte Message-Id: <199707201526.RAA02191@yedi.iaf.nl> Subject: ipfw and secure http To: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Date: Sun, 20 Jul 1997 17:26:06 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quick question: I just had a little collision with ipfw (due to me..). I tried to access a server that uses secure http (is that the right name for it anyway?). In any case it wanted to access the port# corresponding to https (instead of http). Am I correct in assuming the packetfiltering characteristics are identical to http save for the https port# ? Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-hackers Sun Jul 20 10:06:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24533 for hackers-outgoing; Sun, 20 Jul 1997 10:06:30 -0700 (PDT) Received: from csd.cs.technion.ac.il (csd.cs.technion.ac.il [132.68.32.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24501 for ; Sun, 20 Jul 1997 10:06:18 -0700 (PDT) Received: from localhost (nadav@localhost) by csd.cs.technion.ac.il (8.6.11/8.6.10) with SMTP id UAA06014; Sun, 20 Jul 1997 20:06:00 +0300 X-Authentication-Warning: csd.cs.technion.ac.il: nadav owned process doing -bs Date: Sun, 20 Jul 1997 20:06:00 +0300 (IDT) From: Nadav Eiron X-Sender: nadav@csd To: Wilko Bulte cc: FreeBSD hackers list Subject: Re: ipfw and secure http In-Reply-To: <199707201526.RAA02191@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Jul 1997, Wilko Bulte wrote: > Quick question: I just had a little collision with ipfw (due to me..). > I tried to access a server that uses secure http (is that the right > name for it anyway?). In any case it wanted to access the port# > corresponding to https (instead of http). > > Am Icorrect in assuming the packetfiltering characteristics are identical > to http save for the https port# ? Yes, and both can easily be served by a proxy too, which is generally considered safer than letting the packets through. Anyhow, you should be fine just letting them through with ipfw. The port number is 443, BTW. > > Wilko > _ ____________________________________________________________________ > | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, TheNetherlands > |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda > -------------------------------------------------------------------------- > Nadav From owner-freebsd-hackers Sun Jul 20 10:46:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26135 for hackers-outgoing; Sun, 20 Jul 1997 10:46:57 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26130 for ; Sun, 20 Jul 1997 10:46:54 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id KAA21145 for ; Sun, 20 Jul 1997 10:46:54 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.6/8.8.5) with SMTP id KAA26362 for ; Sun, 20 Jul 1997 10:46:37 -0700 (PDT) Date: Sun, 20 Jul 1997 10:46:36 -0700 (PDT) From: Chris Timmons To: freebsd-hackers@freebsd.org Subject: suggested enhancement: linux_ioctl.c diagnostic output Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I tried to get some comments about this from -emulation but perhaps the subject line wasn't to the point enough. If you read down to the end I've sketched out a proposed change to linux_ioctl.c. I'd like to know: 1. Overall is this a worthwile change? 2. Is the long comment which documents linux ioctl encoding inappropriate for this source file? 3. I see from style(9) that I should have spaces between the operands to the bitwise and operator. What about the style of the nested conditional? I guess there might also be some unnecessary parens in the printf argument list. -Chris ---------- Forwarded message ---------- Date: Fri, 11 Jul 1997 16:44:56 -0700 (PDT) From: Chris Timmons To: freebsd-emulation@freebsd.org Subject: Linux StreamWorks player; diagnostic output suggestion While running down an emulation problem with the Linux/Elf StreamWorks Audio player, I've done some thinking about the way in which our diagnostic output for unimplemented ioctls is formatted by linux_ioctl.c in the linux emulator source. Please comment on what I've got below; if no-one strenuously objects I will send-pr it as a patch. The problem with StreamWorks Audio Player is that it wants to use ioctl commands not present in our VoxWare 3.0 sound driver system. The calls in question are available in the VoxWare v3.5-alpha5 driver which I am running on my 2.2-STABLE system courtesy work done by Amancio Hasty and Brian Litzinger (and probably others whom I am unaware of but thank nonetheless.) I am going to ask around on the -multimedia list if I can be of help integrating VoxWare v3.5-alpha5 into -current so that I can then prepare and submit the appropriate emulation mappings in linux_ioctl.c. linux_ioctl.c DIAGNOSTIC OUTPUT ------------------------------- I think the goal of the diagnostic output should be to give the end user something meaningful to put into a send-pr. Here is what I was seeing from the StreamWorks player.: LINUX: 'ioctl' fd=8, typ=0xc50(P), num=0x12 not implemented This contains good information, but to run this down you really have to use ktrace and have an understanding of linux ioctl encoding to get enough information to be able to start digging in the linux sources. You can't tell the mode of the request, only get a nibble of the parameter size, and aren't left with something that resembles an ioctl definition. I've modified the uprintf call to do a little bit more formatting, so that the output is now formatted like this: LINUX: unimplemented ioctl: fd=8, cmd=0x800c5012 (IOR, 'P', 18, 12) We now see the full command word, the mode and also the size parameter presented in more or less the way it would appear in the source which defines the ioctl itself. See the comment in my code about non-printing characters. In evaluating this change I would say that a drawback is more execution time if you're caught in a tight loop featuring an unimplemented ioctl, and also a more complex printf featuring the cryptic conditional operator. In the case of the former, probably the extra overhead is negligible, particularly because if you're executing it at all you have bigger problems :) I respect the fact that comments in the code are sparse because the code is self documenting. Would this comment be inappropriate? Presumably someone like I will have another emulation problem someday and come looking for clues - this will save time downloading the linux kernel sources, at least :) Proposed code snippet for the 'unimplemented ioctl' section of linux_ioctl.c: /* * Linux i386 IOCTL commands are 32 bits total, and at the source * level are encoded with the familiar _IO, _IOR, _IOW, and _IOWR * macros. The Linux binary encoding of the upper 16 bits differs * from that used by FreeBSD as follows: Like FreeBSD the lower 16 * bits contain the command while the higher 16 bits store the mode * and size of any parameter structures. FreeBSD's encoding scheme * is found in . * * In Linux binary encoding, the highest two bits of the most * significant 16 correspond to mode: * * 00 _IO (no parameters) * 01 _IOW (copy in parameters) * 10 _IOR (copy out parameters) * 11 _IOWR (copy in/copy out parameters) * * The remaining 14 bits of this word store the size of any * parameter structures. * * Many of the IOCTL codes found in the upper 8 bits of the lower 16 * conveniently correspond to ascii characters and are actually * represented that way by convention in source code. We print them * that way below, but there are codes that map to non-printing * characters. * Printing undefined characters in diagnostic output isn't a very nice * thing to do, but the alternative is either to omit entirely or be * much more complex than is appropriate. The non-printing codes can * still be seen in the cmd= output that shows all 32 bits. * */ uprintf("LINUX: unimplemented ioctl: fd=%d, cmd=0x%lx (%s, '%c', %lu, %lu)\n", args->fd, args->cmd, (args->cmd&0xc0000000) ? (args->cmd&0xc0000000) == 0x80000000 ? "IOR" : (args->cmd&0xc0000000) == 0x40000000 ? "IOW" : "IOWR" : "IO", /* ick - risk printing the unprintable */ (char)((args->cmd&0x0000ff00)>>8), args->cmd&0xff, (args->cmd&0x3fff0000) >> 16); return EINVAL; } From owner-freebsd-hackers Sun Jul 20 16:17:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA07231 for hackers-outgoing; Sun, 20 Jul 1997 16:17:49 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07223 for ; Sun, 20 Jul 1997 16:17:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09972; Sun, 20 Jul 1997 16:13:59 -0700 From: Terry Lambert Message-Id: <199707202313.QAA09972@phaeton.artisoft.com> Subject: Re: sendmail complains about being unable to write his pid file To: sthaug@nethelp.no Date: Sun, 20 Jul 1997 16:13:59 -0700 (MST) Cc: andreas@klemm.gtn.com, hackers@FreeBSD.ORG In-Reply-To: <15406.869308066@verdi.nethelp.no> from "sthaug@nethelp.no" at Jul 19, 97 12:27:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I think it's a BSDism. bin is the UID and GID for Binaries, Commands > > and source as shown by the entry in /etc/passwd ... > > Yes, but the question stands - why is it setup this way? What is gained > by having binaries (and important directories) owned by bin instead of > root? The ability to update machines remotely via NFS, which proxies root as "nobody" in most sane configurations. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jul 20 16:23:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA07477 for hackers-outgoing; Sun, 20 Jul 1997 16:23:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07472; Sun, 20 Jul 1997 16:22:50 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09987; Sun, 20 Jul 1997 16:20:36 -0700 From: Terry Lambert Message-Id: <199707202320.QAA09987@phaeton.artisoft.com> Subject: Re: pcireg.h lost children... ? To: se@FreeBSD.ORG (Stefan Esser) Date: Sun, 20 Jul 1997 16:20:36 -0700 (MST) Cc: Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG, se@FreeBSD.ORG In-Reply-To: <19970718202558.63332@mi.uni-koeln.de> from "Stefan Esser" at Jul 18, 97 08:25:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > One of the changes to the PCI code, that might follow (I have > not completely made up my mind) is, that the probe will just > associate a driver with a list of vendor/device IDs, and there > will no longer be a xxx_probe() function in the drivers. How does a PCI driver for, for instance, a DEC chip based ethernet board find boards for which a vendor/driver assignment has not yet been made? Currently, the probe code will find the board, and it will just work. One big problem I can see this causing (though I admit it cures one of my loudest complaints: destructive probing) is that the vendor/device/driver association list could quicly get too large to fit on the same floppy as the BSD kernel. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jul 20 16:33:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA07854 for hackers-outgoing; Sun, 20 Jul 1997 16:33:45 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA07849 for ; Sun, 20 Jul 1997 16:33:42 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA10047; Sun, 20 Jul 1997 16:31:26 -0700 From: Terry Lambert Message-Id: <199707202331.QAA10047@phaeton.artisoft.com> Subject: Re: sys/vfs.h To: frankd@yoda.fdt.net (Frank Seltzer) Date: Sun, 20 Jul 1997 16:31:26 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Frank Seltzer" at Jul 18, 97 07:14:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Do we have an equivalent file to this Linux file? I am trying to build > XVFilemanager and mount.c has > > #include > > which causes the build to fall over. It depends on what it wants out of it. Possibilities are: mount.h Contains mount related structures and manifest constants; this is your most likely candidate. Note: I am not happy with manifest definitions of file system types here; you will probably have to add "yet-another-one". This is because the BSD mount(2) system call needs a facelift. vnode_if.h The vnode interface; this file is generated as part of the build process by kern/vnode_if.sh. vnode.h Probably not what you want; details the in-core vnode structures. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Jul 20 17:08:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09304 for hackers-outgoing; Sun, 20 Jul 1997 17:08:13 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA09299 for ; Sun, 20 Jul 1997 17:08:09 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 24272 invoked by uid 1001); 21 Jul 1997 00:08:03 +0000 (GMT) To: terry@lambert.org Cc: andreas@klemm.gtn.com, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: Your message of "Sun, 20 Jul 1997 16:13:59 -0700 (MST)" References: <199707202313.QAA09972@phaeton.artisoft.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 21 Jul 1997 02:08:03 +0200 Message-ID: <24270.869443683@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Yes, but the question stands - why is it setup this way? What is gained > > by having binaries (and important directories) owned by bin instead of > > root? > > The ability to update machines remotely via NFS, which proxies root > as "nobody" in most sane configurations. Certainly - for a corresponding decrease in security. I'd like to have the tighter security be the default. Or at least have it as an option when installing. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Sun Jul 20 17:28:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA10285 for hackers-outgoing; Sun, 20 Jul 1997 17:28:10 -0700 (PDT) Received: from smtp.interlog.com (root@smtp.interlog.com [198.53.145.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA10280 for ; Sun, 20 Jul 1997 17:28:08 -0700 (PDT) Received: from ip226-167.cc.interlog.com (ip226-167.cc.interlog.com [207.34.226.167]) by smtp.interlog.com (8.8.3/8.7.6) with SMTP id UAA19571; Sun, 20 Jul 1997 20:27:51 -0400 (EDT) Message-Id: <199707210027.UAA19571@smtp.interlog.com> Comments: Authenticated sender is From: "Harold Smorodin" To: Al Johnson Date: Sun, 20 Jul 1997 20:26:47 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: HP LaserJet 6L Reply-to: shws@pobox.com CC: freebsd-hackers@FreeBSD.ORG Priority: normal In-reply-to: <01BC939C.46CF4020.Al.Johnson@AJC.State.Net> X-mailer: Pegasus Mail for Windows (v2.54) Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hey folks, > > I'm trying to migrate all my ciritical functions from Win95 to > FreeBSD. Ya, I hear you all groaning now :) Since I'm no expert at > this, been a long time since I was a unix sysadmin, I need > assistance with the filters needed for this printer. I have > successfully printed plain text on the HP from the directly > connected system sort of. An lptest > /dev/lpt0 gets me a sheet of > paper with a single line printed on it. Obvisouly not what it's > supposed to generate. Anyone with a filter or an adequate printcap > definition for this (or just about any PCL) printer I would really > appreciate an email copy. > > In addition, is there any special setup required to get the > appropriate conversion from a Win95 print job to the printer via > Samba? > > -- Al > The following HP filter is what I use: ================== Begin Script ================================ #!/bin/sh # The above assumes that the Bourne Shell is available # # Filter for HP printers # # This file MUST be created using command: cat > hpcrlf # # When finished entering, use Ctrl-d to return to system prompt # (Press/hold the Ctrl key and strike the d key) # # The character (Hex 1B) is entered as Alt-027: # (Press/hold the Alt key and enter: 027 on the NUMERIC key pad) # # Create this script signed on as: root # Script name: hpcrlf # Script location: /usr/spool # Script permissions: chmod 775 hpcrlf # Script ownership: chown root:wheel hpcrlf # After installation, execute command: rehash # # Once created, this script may be edited using the vi editor, # PROVIDED you don't delete, alter, or overwrite the # character which displays as a ^ [ character pair in the vi # editor. # # In the lines that follow, enter as Alt-027 # # Treat LF as CRLF echo -n \&k2G # Symbol Set: (8U = HP Roman-8 echo -n \(8U # Font: 12cpi 10pt Upright Medium Courier echo -n \(s0p12.00h10.0v0s0b3T # End-of-Line Wrap echo -n \&s0C # Printer data stream cat # Printer Reset (CRLF Treatment) echo -n \&k0G =========================== End Script ========================= The following is my printcap script: ================== Begin Script ================================ # # Reference: printcap(5) # Script name: printcap # Script location: /etc # Set ownership & permissions as required # lp|HP LaserJet:\ :sh:\ :mx#0:\ :lp=/dev/lpt0:\ :sd=/var/spool/lpd:\ :lf=/var/log/lpd-errs:\ :of=/usr/spool/hpcrlf: =========================== End Script ========================= I use the following script to print configuration files: ================== Begin Script ================================ #!/bin/sh # Shell script for printing text files # # Script name: prfile # Script location: /usr/local/bin # Script permissions: chmod 775 prfile # Script ownership: chown root:wheel prfile # After installation, execute command: rehash # case $# in 1) [ -r $PWD'/'$1 ] if [ "$?" = 0 ] then if [ $PWD = '/' ] then cat $1 | pr -h $1 -o 9 | lpr else cat $1 | pr -h $PWD'/'$1 -o 9 | lpr fi else cat $1 | pr -h $1 -o 9 | lpr fi ;; *) echo "$0: Invalid argument count: $#" >&2 echo " " >&2 echo "Usage: $0 filename" >&2 echo " " >&2 ;; esac =========================== End Script ========================= I use the following script to print man pages: ================== Begin Script ================================ #!/bin/sh # Shell script for printing MAN pages # # Script name: prman # Script location: /usr/local/bin # Script permissions: chmod 775 prman # Script ownership: chown root:wheel prman # After installation, execute command: rehash # case $# in 1) man $1 | pr -h $1 -o 9 | lpr ;; 2) man $1 $2 | pr -h $2 -o 9 | lpr ;; *) echo "$0: Invalid argument count: $#" >&2 echo " " >&2 echo "Usage: $0 [section] name" >&2 echo " " >&2 ;; esac =========================== End Script ========================= DISCLAIMER I am not responsible in any manner for direct, indirect, special or consequential damages, howsoever caused, arising from the use of these scripts. USE AT YOUR OWN RISK By using these scripts, you agree to assume all risks and liabilities arising from such use. Harold From owner-freebsd-hackers Sun Jul 20 17:51:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11497 for hackers-outgoing; Sun, 20 Jul 1997 17:51:52 -0700 (PDT) Received: from Kryten.nina.org (port-55.ts1.gnv.fdt.net [205.229.51.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA11492 for ; Sun, 20 Jul 1997 17:51:48 -0700 (PDT) Received: from localhost (frankd@localhost) by Kryten.nina.org (8.8.5/8.8.5) with SMTP id UAA00713; Sun, 20 Jul 1997 20:50:17 -0400 (EDT) X-Authentication-Warning: Kryten.nina.org: frankd owned process doing -bs Date: Sun, 20 Jul 1997 20:50:17 -0400 (EDT) From: Frank Seltzer X-Sender: frankd@Kryten.nina.org To: Terry Lambert cc: hackers@FreeBSD.ORG Subject: Re: sys/vfs.h In-Reply-To: <199707202331.QAA10047@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Jul 1997, Terry Lambert wrote: > > Do we have an equivalent file to this Linux file? I am trying to build > > XVFilemanager and mount.c has > > > > #include > > > > which causes the build to fall over. > > It depends on what it wants out of it. > > Possibilities are: > > mount.h Contains mount related structures and manifest > constants; this is your most likely candidate. > Note: I am not happy with manifest definitions > of file system types here; you will probably > have to add "yet-another-one". This is because > the BSD mount(2) system call needs a facelift. > > vnode_if.h The vnode interface; this file is generated as > part of the build process by kern/vnode_if.sh. > > vnode.h Probably not what you want; details the in-core > vnode structures. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > I will give it a try with these files substituted and see what happens. On closer inspection, it seems that this app was not written with portability beyond Linux in mind so I may not have much luck. Thanks, Frank -- Only in America can a homeless veteran sleep in a cardboard box while a draft dodger sleeps in the White House - anonymous From owner-freebsd-hackers Sun Jul 20 17:58:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11836 for hackers-outgoing; Sun, 20 Jul 1997 17:58:09 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA11831 for ; Sun, 20 Jul 1997 17:58:06 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA19603; Mon, 21 Jul 1997 10:27:53 +0930 (CST) From: Michael Smith Message-Id: <199707210057.KAA19603@genesis.atrad.adelaide.edu.au> Subject: Re: APA358 In-Reply-To: from Bob Bishop at "Jul 20, 97 02:54:14 pm" To: rb@gid.co.uk (Bob Bishop) Date: Mon, 21 Jul 1997 10:27:53 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bob Bishop stands accused of saying: > Hi, another dumb question... > > Has anyone looked at a driver for the Adaptec/Trantor APA358 parallel port > SCSI adaptor? TIA Do you have one? If you do, is it totally sealed, or can it be opened up? If it can be opened, can you send me a list of the part numbers off the chips inside? It's possible that it could be supported by the same code that handles the parallel port Zip drives. Alternatively, if you can get documentation from Adaptec for it, and arrange a sample unit, we could probably manage something for you. > Bob Bishop (0118) 977 4017 international code +44 118 -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 18:01:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA12014 for hackers-outgoing; Sun, 20 Jul 1997 18:01:54 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12008 for ; Sun, 20 Jul 1997 18:01:49 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA19628; Mon, 21 Jul 1997 10:31:37 +0930 (CST) From: Michael Smith Message-Id: <199707210101.KAA19628@genesis.atrad.adelaide.edu.au> Subject: Re: QSeeMe/Linux emul. Problems In-Reply-To: <19970720101041.40890@scsn.net> from "Donald J. Maddox" at "Jul 20, 97 10:10:41 am" To: dmaddox@scsn.net Date: Mon, 21 Jul 1997 10:31:37 +0930 (CST) Cc: hackers@FreeBSD.ORG, mavilar@aleph.pangea.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Donald J. Maddox stands accused of saying: > When I try to run QSeeMe 0.80a for Linux, this is what I see: > > >QSeeMe-0.80a> ./qseeme > LINUX: 'ioctl' fd=7, typ=0x450(P), num=0xf not implemented > LINUX: 'ioctl' fd=7, typ=0x50(P), num=0x16 not implemented #define SNDCTL_DSP_GETTRIGGER _IOR ('P',16, int) #define SNDCTL_DSP_SETTRIGGER _IOW ('P',16, int) # define PCM_ENABLE_INPUT 0x00000001 # define PCM_ENABLE_OUTPUT 0x00000002 #define SNDCTL_DSP_SETDUPLEX _IO ('P', 22) These are sound driver ioctls. > It then proceeds to fail to connect to any reflector. Tcpdump > shows that it is trying to make udp connections rather than tcp... > Could this be related to the above failed ioctls? No. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 18:15:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA12857 for hackers-outgoing; Sun, 20 Jul 1997 18:15:06 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12845; Sun, 20 Jul 1997 18:14:57 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA19725; Mon, 21 Jul 1997 10:43:58 +0930 (CST) From: Michael Smith Message-Id: <199707210113.KAA19725@genesis.atrad.adelaide.edu.au> Subject: Re: pcireg.h lost children... ? In-Reply-To: <199707202320.QAA09987@phaeton.artisoft.com> from Terry Lambert at "Jul 20, 97 04:20:36 pm" To: terry@lambert.org (Terry Lambert) Date: Mon, 21 Jul 1997 10:43:58 +0930 (CST) Cc: se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > One of the changes to the PCI code, that might follow (I have > > not completely made up my mind) is, that the probe will just > > associate a driver with a list of vendor/device IDs, and there > > will no longer be a xxx_probe() function in the drivers. > > How does a PCI driver for, for instance, a DEC chip based ethernet > board find boards for which a vendor/driver assignment has not yet > been made? The same way it does now. > Currently, the probe code will find the board, and it will just work. You should read the probe code I think. To save your fingers the effort, here it is : static char* tulip_pci_probe( pcici_t config_id, pcidi_t device_id) { if (PCI_VENDORID(device_id) != DEC_VENDORID) return NULL; if (PCI_CHIPID(device_id) == CHIPID_21040) return "Digital 21040 Ethernet"; if (PCI_CHIPID(device_id) == CHIPID_21041) return "Digital 21041 Ethernet"; if (PCI_CHIPID(device_id) == CHIPID_21140) { u_int32_t revinfo = pci_conf_read(config_id, PCI_CFRV) & 0xFF; if (revinfo >= 0x20) return "Digital 21140A Fast Ethernet"; else return "Digital 21140 Fast Ethernet"; } return NULL; } Now, if we remove this information from the driver and put it somewhere in a Big Central Localtion, like, oh say W95 does (seeing as you respect their design decisions), the central localtion can be updated rapidly without having to rebuild and reinstall the driver. Nifty, eh? > One big problem I can see this causing (though I admit it cures > one of my loudest complaints: destructive probing) is that the > vendor/device/driver association list could quicly get too large > to fit on the same floppy as the BSD kernel. 8-(. You split it into two parts; the ones needed to boot with, and a second set for "frivolous" devices. 8) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 18:25:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA13386 for hackers-outgoing; Sun, 20 Jul 1997 18:25:31 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA13353; Sun, 20 Jul 1997 18:25:10 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA19849; Mon, 21 Jul 1997 10:54:59 +0930 (CST) From: Michael Smith Message-Id: <199707210124.KAA19849@genesis.atrad.adelaide.edu.au> Subject: Re: Is support of Adaptec 152x truely flakey? In-Reply-To: <19970717081631.61271@astro.psu.edu> from Matthew Hunt at "Jul 17, 97 08:16:31 am" To: mph@pobox.com Date: Mon, 21 Jul 1997 10:54:58 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Matthew Hunt stands accused of saying: > On Thu, Jul 17, 1997 at 12:23:08PM +0930, Michael Smith wrote: > > > Are you _sure_ what you have is a U34F? It should be a full-length > > VLB card with a Honda ("scsi-2") connector on it. > > Yep, the manual says it's an UltraStor 34FB, the card matches the > manual (and your description) and if I recall correctly the card's ROM > says it's a U34FB. > > I guess my main puzzle is how the "B" version differs from the > no-letter and "A" versions, which I hear about much more frequently. > Maybe something changed in the "B" that the uha driver doesn't like? Bizarre. I really don't know; the U34F driver has some seriously worn corners; I don't know anyone that actually has documentation on the old card, let alone the newer ones. You could try putting a printf in uha_init in i386/isa/ultra14f.c in the function uha_init() thus : model = inb(ur->id); submodel = inb(ur->id + 1); printf("uha%d: model %d submodel %d\n", uha->unit, model, submodel); I suspect that the 34FB has a different set of identifiers... -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 18:59:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14789 for hackers-outgoing; Sun, 20 Jul 1997 18:59:03 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14767; Sun, 20 Jul 1997 18:58:58 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA20128; Mon, 21 Jul 1997 11:28:44 +0930 (CST) From: Michael Smith Message-Id: <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> Subject: Re: dma handling in the sound driver In-Reply-To: <199707191437.QAA01053@prova.iet.unipi.it> from Luigi Rizzo at "Jul 19, 97 04:37:50 pm" To: luigi@iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 11:28:44 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > - with two DMA buffers, we can refill one buffer while the other one > is in use by the DMA engine. We can still have troubles if we start > a long refill near the end of operation of DMA on the other buffer, > but this problem can be minimized (but not avoided; if we are late, > we are late, no matter how many buffers we have!) This is the traditional double-buffered approach. You go on to describe a triple-buffered approach which is more suited to the high latency that is often encountered in multiprocessing situations. > In our implementation, we use a single memory block structured as > three logical, variable-size, buffers: one in use by the dma engine, > the next one ready for use by the dma (already filled up), the last > one free for refills. > > dp,dl rp,rl fp,fl > +-------+-------------+---------------+------+ > | free | used by dma | ready for use | free | > +-------+-------------+---------------+------+ > > Both the "ready" and "free" areas can wrap around the end of the > buffer. I presume that the plan here is that the host DMA controller loops endlessly over this buffer in autoinit mode? If not, there's no apparent need for such a complex approach; you can just use three separate buffers each sized suitably to cover the latency involved in filling the next. Another alternative would be to simply use an endlessly-recirculating DMA buffer of appropriate size thus : DMA V XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO Some data has been written to the sound device. Regardless of how much data you have, you start the DMA going. DMA V OOOOOOOOOOOOOOOXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO Here the DMA is in progress, consuming data. A selecting writer would be able to write here. DMA V YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY ... and more data has arrived. The key to keeping more data in the buffer than is consumed by the looping DMA is to make sure that any selecting writer is woken up often enough to keep you busy. In order to do this, you need something that interrupts you more than once per DMA loop. At 44kHz, 16-bit stereo you are looking at 160kB/sec throughput, which equates to 1.6kB per possible wakeup(). This isn't too hard to manage really; a 64kB recirculating buffer will give you 400ms of audio, or a 200ms mean wakeup time. You can play some more neat games. In the original first case : DMA V XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO ^ TC you set the terminal count short of the end of the buffer. This avoids your having to worry about the DMA running into unfilled buffer space. In the later case, where the buffer contents have wrapped : DMA V YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY ^ TC TC is set to the end of the buffer, and the autoinit bit is set, so that it will loop back to the start. When it does loop, you'll get an interrupt, and you can reprogram TC again : DMA V YYYYOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ^ TC If an application is too slow to respond to your waking it up, then there's really nothing more you can do. As Amancio has observed, many applications will want to write small amounts of data on a regular basis. A timer event run once every 1/hz seconds can easily monitor the progress of the DMA and update the buffer tail pointer & wake up any writers. In this model, the overhead of uiomove is effectively irrelevant; data is solicited from the application as early as is possible. I'm not sure if this actually helps you... > Luigi Rizzo Dip. di Ingegneria dell'Informazione -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 19:05:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA15130 for hackers-outgoing; Sun, 20 Jul 1997 19:05:56 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15096 for ; Sun, 20 Jul 1997 19:05:43 -0700 (PDT) Received: from awfulhak.org (dev.lan.awfulhak.org [10.0.1.5]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA20285; Mon, 21 Jul 1997 02:23:02 +0100 (BST) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.6/8.8.6) with ESMTP id CAA26149; Mon, 21 Jul 1997 02:23:01 +0100 (BST) Message-Id: <199707210123.CAA26149@awfulhak.org> X-Mailer: exmh version 2.0delta 6/3/97 To: Chuck Robey cc: FreeBSD-Hackers Subject: Re: ppp default routes In-reply-to: Your message of "Thu, 17 Jul 1997 23:37:39 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 02:23:01 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm experimenting with ppp again. I can get it going, and all is > perfectly correct, except I can't get a default route to my isp going. > My machine, journey2.mat.net. is 205.252.122.116, static. The isp isd > mat.net, and the machine I ppp to is earth.mat.net, at 205.252.122.1. > > The end of my ppp.conf entry is: > > set ifaddr 205.252.122.116 205.252.122.1 255.255.255.0 > > the ppp.linkup entry is: > > matppp: > delete ALL > add 0 0 205.252.122.1 > > How come I always have to add the default routing entry via a > route command? It's never done for me, but I duplicate the entry in the > man page just exactly. This is _not_ auto, btw. Does "set log +command +debug" shed any light ? > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@eng.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD > (301) 220-2114 | version 3.0 current -- and great FUN! > ----------------------------+----------------------------------------------- > > -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sun Jul 20 19:29:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA16095 for hackers-outgoing; Sun, 20 Jul 1997 19:29:41 -0700 (PDT) Received: from po1.glue.umd.edu (root@po1.glue.umd.edu [128.8.10.97]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16089 for ; Sun, 20 Jul 1997 19:29:39 -0700 (PDT) Received: from professor.eng.umd.edu (chuckr@professor.eng.umd.edu [129.2.103.23]) by po1.glue.umd.edu (8.8.6/8.8.5) with ESMTP id WAA08014; Sun, 20 Jul 1997 22:29:25 -0400 (EDT) Received: from localhost (chuckr@localhost) by professor.eng.umd.edu (8.8.5/8.8.5) with SMTP id WAA04244; Sun, 20 Jul 1997 22:29:24 -0400 (EDT) X-Authentication-Warning: professor.eng.umd.edu: chuckr owned process doing -bs Date: Sun, 20 Jul 1997 22:29:23 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@professor.eng.umd.edu To: Brian Somers cc: FreeBSD-Hackers Subject: Re: ppp default routes In-Reply-To: <199707210123.CAA26149@awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 21 Jul 1997, Brian Somers wrote: > > I'm experimenting with ppp again. I can get it going, and all is > > perfectly correct, except I can't get a default route to my isp going. > > My machine, journey2.mat.net. is 205.252.122.116, static. The isp isd > > mat.net, and the machine I ppp to is earth.mat.net, at 205.252.122.1. > > > > The end of my ppp.conf entry is: > > > > set ifaddr 205.252.122.116 205.252.122.1 255.255.255.0 > > > > the ppp.linkup entry is: > > > > matppp: > > delete ALL > > add 0 0 205.252.122.1 > > > > How come I always have to add the default routing entry via a > > route command? It's never done for me, but I duplicate the entry in the > > man page just exactly. This is _not_ auto, btw. > > Does "set log +command +debug" shed any light ? I'll experiment some more... it's works exactly perfectly on -auto, but when I invoke it directly, nuts. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt. T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sun Jul 20 19:45:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA16893 for hackers-outgoing; Sun, 20 Jul 1997 19:45:57 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16884; Sun, 20 Jul 1997 19:45:50 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA20440; Mon, 21 Jul 1997 12:15:30 +0930 (CST) From: Michael Smith Message-Id: <199707210245.MAA20440@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707170553.HAA15160@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 17, 97 07:53:40 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 12:15:29 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > controller sndX > > > brings in all the files related to generic sound support for all > > > subsystem. This includes, in particular, the mixer, dma code, > > > timers, and some support routines. > > > > > > device pcmX at isa ? port? tty irq N drq D flags F vector pcmintr > > > device midiX at isa ? port? tty flags F > > > device synthX at isa ? port? tty flags F > > > > Thes should ideally be "at snd?", eg. like the 'disk' stuff, or just > > 'device xxx' like the SCSI devices. They're _not_ "at isa?" in the > > true sense of the word. > > right. But what are the implications of using "at xyz?" ? How do I test > for a specific bus, etc. ? I've just been working through this with the parallel-port stuff, as the ultimate goal there is to produce drivers that will work on any parallel port. The way to go for that (at the moment) is like the PCI code; you use a linker set to create an aggregated list of drivers, which you then scan with your bus code. This isn't really ideal for your case though, as whilst there's some common sound code, there's little or no correlation between the various component drivers, other than (perhaps) that they are aggregated together on a single card. > The identification info should suffice to determine exactly which > board you have (down to the revision level of the chip) so I think > there is really little need to "probe" the device; rather, one > should just run the appropriate configuration commands and deal > with exceptions the standard way. ISA device probing should essentially provide additional information supplementary to that divined by PnP. Once you have all the "what is where" information, you can start working out what to do with it. If using the PnP stuff is of interest to you, you could help me out with some suggestions for calling 16-bit protected-mode BIOS interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of documentation on various bits and pieces (including the ECSD interface) which would be _very_ helpful in this endeavour. 8) > Luigi Rizzo | Dip. di Ingegneria dell'Informazione -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 20:08:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA17794 for hackers-outgoing; Sun, 20 Jul 1997 20:08:04 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17740 for ; Sun, 20 Jul 1997 20:07:59 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA20639; Mon, 21 Jul 1997 12:37:43 +0930 (CST) From: Michael Smith Message-Id: <199707210307.MAA20639@genesis.atrad.adelaide.edu.au> Subject: Re: utmp/wtmp interface In-Reply-To: <199707170828.SAA04602@labs.usn.blaze.net.au> from David Nugent at "Jul 17, 97 06:28:00 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Mon, 21 Jul 1997 12:37:42 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Nugent stands accused of saying: > For anyone who may be interested, my interim work on a lastlog/utmp/wtmp > api has been posted on freefall and is available via the web. It is not > as thoroughly tested as I would like, and the proposed 'new' wtmp format > has not been tested at all (it isn't the default, and won't be initially > activated anyway, when committed, for backwards compatibility with ports). > > Comments, patches, flames and insults - any feedback welcome. :-) Hmm. "More documentation" 8) Seriously; I think that perhaps going in a similar direction to the /etc/passwd approach might be good; write the 'old-format' files when generating the records, but use an improved binary format under a new (but related) filename when accessing it from the library. In particular, a self-describing format for something like utmp/wtmp would be very sexy. I think your changed interface for lastlog is better, although there are a few problems in lastlog.c : modes = xl->ll_time ? (O_RDWR|O_CREAT) : O_RDONLY; if (xl == NULL) errno = EINVAL; This fragment is pretty bad. static char sbuf[sizeof(pl) * 2]; /* time */ xl->ll_time = pl.ll_time; /* line */ xl->ll_line = strncpy(sbuf + l, pl.ll_line, sizeof(pl.ll_line)); sbuf[l + sizeof(pl.ll_line)] = '\0'; if (!*xl->ll_line) xl->ll_line = NULL; else l += strlen(xl->ll_line) + 1; /* host */ xl->ll_host = strncpy(sbuf + l, pl.ll_host, sizeof(pl.ll_host)); sbuf[l + sizeof(pl.ll_host)] = '\0'; if (!*xl->ll_host) xl->ll_host = NULL; Using a static buffer here isn't so great either. It's going to give the threaded version cooties by default. 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 20:09:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA17856 for hackers-outgoing; Sun, 20 Jul 1997 20:09:48 -0700 (PDT) Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17847 for ; Sun, 20 Jul 1997 20:09:45 -0700 (PDT) Received: from onion.ish.org (localhost [127.0.0.1]) by onion.ish.org (8.8.6/3.5Wpl7-06/16/97) with ESMTP id MAA04688 for ; Mon, 21 Jul 1997 12:09:32 +0900 (JST) Message-Id: <199707210309.MAA04688@onion.ish.org> To: freebsd-hackers@FreeBSD.ORG Subject: Re: QSeeMe/Linux emul. Problems In-Reply-To: Your message of "Mon, 21 Jul 1997 10:31:37 +0930 (CST)" References: <199707210101.KAA19628@genesis.atrad.adelaide.edu.au> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 Jul 1997 12:09:31 +0900 From: Masachika ISHIZUKA Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > When I try to run QSeeMe 0.80a for Linux, this is what I see: > > > > >QSeeMe-0.80a> ./qseeme > > LINUX: 'ioctl' fd=7, typ=0x450(P), num=0xf not implemented > > LINUX: 'ioctl' fd=7, typ=0x50(P), num=0x16 not implemented Hi. I'm using FreeBSD 3.0-970618-SNAP and QSeeMe 0.80a for Linux. When qseeme starts, the same error messages appear, but I can connect reflectors and play video. (I can't play audio.) You must give proper interface at startup. Please check as follows. % ifconfig -a | grep UP|grep -v lo0 ed0: flags=8843 mtu 1500 % qseeme -l ed0 ~~~ It seems bad to specify any IP address instead of interface name. From owner-freebsd-hackers Sun Jul 20 20:29:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA18988 for hackers-outgoing; Sun, 20 Jul 1997 20:29:30 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA18971; Sun, 20 Jul 1997 20:29:22 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id UAA00494; Sun, 20 Jul 1997 20:28:52 -0700 (PDT) Message-Id: <199707210328.UAA00494@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: luigi@iet.unipi.it (Luigi Rizzo), hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-reply-to: Your message of "Mon, 21 Jul 1997 11:28:44 +0930." <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 1997 20:28:52 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Guys, All I am trying to do is to explain the existing dma algorithm so that the new re-design does not break the sound apps. Michael's explication is very close to the current dma algorithm. SNDCTL_DSP_SETFRAGMENT sets the block of io which the sub modules use to send or receive data. SNDCTL_DSP_SETBLKSIZE for all practical purposes is the same as the above. If the user does not set the block size then the dma routines choses a size equal to about 1/2 second worth of data. For typical sun style au files this is 4096 bytes . A quick walk thru of the existing dma routines cat TSTSND-elvis-has-left-bldg.au >/dev/audio Jul 20 19:15:29 cioloco /kernel: audio cnt 18364 audio_write initiates request for dma Jul 20 19:15:29 cioloco /kernel: dmabuf start count 65536 Set up an auto dma buffer of size 65536 The current block size which we use for io is 4096. qlen is the number of buffer's queued up . The dma routines loop on the auto dma buffer modulus 4096. Jul 20 19:15:29 cioloco /kernel: intrflag 0 cnt 4095 dsp_count 4095 This is the first time thru in sb16_dsp.c so we kick off the dma process. Jul 20 19:15:29 cioloco /kernel: what qlen 4 qhead 1 We got an interrupt and we have 4 queued up buffers Jul 20 19:15:29 cioloco /kernel: return cnt 4095 Jul 20 19:15:30 cioloco /kernel: what qlen 3 qhead 2 Jul 20 19:15:30 cioloco /kernel: return cnt 4095 Jul 20 19:15:30 cioloco /kernel: what qlen 2 qhead 3 Jul 20 19:15:30 cioloco /kernel: return cnt 4095 Jul 20 19:15:31 cioloco /kernel: what qlen 1 qhead 4 Jul 20 19:15:31 cioloco /kernel: what qlen 0 qhead 5 No more buffers to process we are done. I don't think latency is a problem with the current dma routines given that we can always set the block of io . However the dma routines are very complex and simplification is needed. >From The Desk Of Michael Smith : > Luigi Rizzo stands accused of saying: > > > > - with two DMA buffers, we can refill one buffer while the other one > > is in use by the DMA engine. We can still have troubles if we start > > a long refill near the end of operation of DMA on the other buffer, > > but this problem can be minimized (but not avoided; if we are late, > > we are late, no matter how many buffers we have!) > > This is the traditional double-buffered approach. You go on to > describe a triple-buffered approach which is more suited to the high > latency that is often encountered in multiprocessing situations. > > > In our implementation, we use a single memory block structured as > > three logical, variable-size, buffers: one in use by the dma engine, > > the next one ready for use by the dma (already filled up), the last > > one free for refills. > > > > dp,dl rp,rl fp,fl > > +-------+-------------+---------------+------+ > > | free | used by dma | ready for use | free | > > +-------+-------------+---------------+------+ > > > > Both the "ready" and "free" areas can wrap around the end of the > > buffer. > > I presume that the plan here is that the host DMA controller loops > endlessly over this buffer in autoinit mode? > > If not, there's no apparent need for such a complex approach; you can > just use three separate buffers each sized suitably to cover the > latency involved in filling the next. > > Another alternative would be to simply use an endlessly-recirculating > DMA buffer of appropriate size thus : > > DMA > V > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > > Some data has been written to the sound device. Regardless of how > much data you have, you start the DMA going. > > DMA > V > OOOOOOOOOOOOOOOXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > > Here the DMA is in progress, consuming data. A selecting writer would be > able to write here. > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY > > ... and more data has arrived. The key to keeping more data in the buffer > than is consumed by the looping DMA is to make sure that any selecting > writer is woken up often enough to keep you busy. In order to do this, > you need something that interrupts you more than once per DMA loop. > > At 44kHz, 16-bit stereo you are looking at 160kB/sec throughput, which > equates to 1.6kB per possible wakeup(). This isn't too hard to manage > really; a 64kB recirculating buffer will give you 400ms of audio, or > a 200ms mean wakeup time. > > You can play some more neat games. In the original first case : > > DMA > V > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > ^ > TC > > you set the terminal count short of the end of the buffer. This avoids > your having to worry about the DMA running into unfilled buffer space. > > In the later case, where the buffer contents have wrapped : > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY > ^ > TC > > TC is set to the end of the buffer, and the autoinit bit is set, so > that it will loop back to the start. When it does loop, you'll get an > interrupt, and you can reprogram TC again : > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO > ^ > TC > > If an application is too slow to respond to your waking it up, then > there's really nothing more you can do. As Amancio has observed, many > applications will want to write small amounts of data on a regular > basis. A timer event run once every 1/hz seconds can easily monitor > the progress of the DMA and update the buffer tail pointer & wake up > any writers. > > In this model, the overhead of uiomove is effectively irrelevant; data > is solicited from the application as early as is possible. > > I'm not sure if this actually helps you... > > > Luigi Rizzo Dip. di Ingegneria dell'Informazione > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 20:49:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19633 for hackers-outgoing; Sun, 20 Jul 1997 20:49:32 -0700 (PDT) Received: from lab321.ru (root@[194.226.32.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19626 for ; Sun, 20 Jul 1997 20:49:27 -0700 (PDT) Received: from localhost (kev@localhost.l321.omsk.net.ru [127.0.0.1]) by lab321.ru SLmail95 v1.0.32 with SMTP id KAA21377; Mon, 21 Jul 1997 10:51:53 +0700 (OSD) Date: Mon, 21 Jul 1997 10:51:53 +0700 (OSD) From: Eugeny Kuzakov To: Bob Bishop cc: hackers@FreeBSD.ORG Subject: Re: Iomega Zip In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 18 Jul 1997, Bob Bishop wrote: > Hi, > > Anyone using Iomega Zip drives with FBSD? Any hints/comments? TIA One copmment: no problem. Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Sun Jul 20 21:46:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22103 for hackers-outgoing; Sun, 20 Jul 1997 21:46:20 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA22098 for ; Sun, 20 Jul 1997 21:46:00 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id OAA21177; Mon, 21 Jul 1997 14:14:40 +0930 (CST) From: Michael Smith Message-Id: <199707210444.OAA21177@genesis.atrad.adelaide.edu.au> Subject: Re: suggested enhancement: linux_ioctl.c diagnostic output In-Reply-To: from Chris Timmons at "Jul 20, 97 10:46:36 am" To: skynyrd@opus.cts.cwu.edu (Chris Timmons) Date: Mon, 21 Jul 1997 14:14:39 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Timmons stands accused of saying: > > I tried to get some comments about this from -emulation but perhaps the > subject line wasn't to the point enough. It was; you're just buried in my to-do list 8( > If you read down to the end I've sketched out a proposed change to > linux_ioctl.c. I'd like to know: > > 1. Overall is this a worthwile change? Yes. > 2. Is the long comment which documents linux ioctl encoding > inappropriate for this source file? No. > 3. I see from style(9) that I should have spaces between the > operands to the bitwise and operator. What about the > style of the nested conditional? I guess there might also be > some unnecessary parens in the printf argument list. Bruce will have his own interpretation; I would be inclined to say : uprintf("LINUX: unimplemented ioctl: fd=%d, cmd=0x%lx (IO%s%s, '%c', %lu, %lu)\n", args->fd, args->cmd, (args->cmd & 0x400000000) ? "W" : "", (args->cmd & 0x800000000) ? "R" : "", ((args->cmd & 0x0000ff00) >> 8) >= 0x20) ? (char)((args->cmd & 0x0000ff00)>>8) : '?', args->cmd & 0xff, (args->cmd & 0x3fff0000) >> 16); return EINVAL; } The other implementation of the IO[WR] decoding I would consider would use a small lookup table and a large shift to generate an index. The massively nested ? set you used makes for very difficult reading. I don't think that the performance of the printf() should be a consideration in contrast to the usefulness of verbose output. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sun Jul 20 21:54:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22557 for hackers-outgoing; Sun, 20 Jul 1997 21:54:42 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA22543; Sun, 20 Jul 1997 21:54:34 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA20510; Mon, 21 Jul 1997 05:52:10 +0200 From: Luigi Rizzo Message-Id: <199707210352.FAA20510@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 05:52:10 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210245.MAA20440@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 12:15:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > > > > > > device pcmX at isa ? port? tty irq N drq D flags F vector pcmintr ... > > > Thes should ideally be "at snd?", eg. like the 'disk' stuff, or just > > > 'device xxx' like the SCSI devices. They're _not_ "at isa?" in the > > > true sense of the word. > > > > right. But what are the implications of using "at xyz?" ? How do I test > > for a specific bus, etc. ? > > The way to go for that (at the moment) is like the PCI code; you use a > linker set to create an aggregated list of drivers, which you then > scan with your bus code. more or less this is what I do now. Except that I do not leave the user a choice of which modules to include and which not, and the actual selection of the driver to use (if necessary at all) is done through some bits of the 'flags' field. I have done this because in in the sound driver there are probably a couple of main operating modes (i.e. soundblaster and MSS) for the codec, and all the card-specific code is for initialization or handling special features of the board. And it is too complex to ask the user (possibly an inexperienced one) to produce a correct configuration file otherwise, with all the required options for his board. > If using the PnP stuff is of interest to you, you could help me out > with some suggestions for calling 16-bit protected-mode BIOS > interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of unfortunately i am not enough familiar with the architecture of the system to help out on this... Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Jul 20 22:25:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA23690 for hackers-outgoing; Sun, 20 Jul 1997 22:25:21 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA23670; Sun, 20 Jul 1997 22:25:13 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA20549; Mon, 21 Jul 1997 06:22:55 +0200 From: Luigi Rizzo Message-Id: <199707210422.GAA20549@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 06:22:54 +0200 (MET DST) Cc: luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 11:28:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > > - with two DMA buffers, we can refill one buffer while the other one ... > This is the traditional double-buffered approach. You go on to certainly I am not inventing anything :) the problem is that, while writing, one never knows if sufficient info are given to let everybody understand all the details, so better give more than be too criptic. > describe a triple-buffered approach which is more suited to the high > latency that is often encountered in multiprocessing situations. in fact I don't agree that multiprocessors should necessarily have high latency, and if a critical interrupt (e.g. the one restarting a DMA transfer) is delayed too much, we are in trouble and get holes in the i/o no matter what we do... > > one free for refills. > > > > dp,dl rp,rl fp,fl > > +-------+-------------+---------------+------+ > > | free | used by dma | ready for use | free | > > +-------+-------------+---------------+------+ > > > > Both the "ready" and "free" areas can wrap around the end of the > > buffer. > > I presume that the plan here is that the host DMA controller loops > endlessly over this buffer in autoinit mode? whoops... I did not think explicitly to autoinit mode, actually I suspect that some changes are necessary to my scheme to support automode. I'll look into them, thanks for the suggestion. > If not, there's no apparent need for such a complex approach; you can > just use three separate buffers each sized suitably to cover the > latency involved in filling the next. not sure. the problem which worries me more is the latency from the time the write routine is invoked with a large block, and the time the next buffer is completely filled up by the uiomove. Now you are right that one could play games such as first mark the buffer as full, with the appropriate length, and then start the uiomove, in the assumption that uiomove will finish first anyways (if not interrupted...) > Another alternative would be to simply use an endlessly-recirculating > DMA buffer of appropriate size thus : ... > I'm not sure if this actually helps you... yes a lot. An interesting alternative, I just have to see how complex (and reliable) is to read from the DMA registers on the fly, and how to do this with the MSS which has some kind of dma support on board. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sun Jul 20 22:53:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA24569 for hackers-outgoing; Sun, 20 Jul 1997 22:53:00 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24562; Sun, 20 Jul 1997 22:52:48 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA21772; Mon, 21 Jul 1997 15:21:49 +0930 (CST) From: Michael Smith Message-Id: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707210352.FAA20510@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 05:52:10 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 15:21:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > > The way to go for that (at the moment) is like the PCI code; you use a > > linker set to create an aggregated list of drivers, which you then > > scan with your bus code. > > more or less this is what I do now. Except that I do not leave the user > a choice of which modules to include and which not, and the actual > selection of the driver to use (if necessary at all) is done through > some bits of the 'flags' field. Ok. > I have done this because in in the sound driver there are probably a > couple of main operating modes (i.e. soundblaster and MSS) for the > codec, and all the card-specific code is for initialization or handling > special features of the board. And it is too complex to ask the user > (possibly an inexperienced one) to produce a correct configuration file > otherwise, with all the required options for his board. Aha. May I offer a suggestion? Have the 'snd' controller pull in all the modules for the various on-card subsystems. Have each of these subsystems register themselves in a linker set using a 'name' field to identify themselves. Then have 'device at ...?' statements which pull in probe code for each of the basic supported board types; eg. mss, sb16, etc. Each of these sets of probe code know how to find the board type they support, whether via PnP or direct probing, and then they use the linker set from the snd controller to locate the subsystem modules and feed them the information required to initialise the subsystems on the card. This lets you have board-specific probe and setup code, while keeping the driver components separate and board-independant. > > If using the PnP stuff is of interest to you, you could help me out > > with some suggestions for calling 16-bit protected-mode BIOS > > interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of > > unfortunately i am not enough familiar with the architecture of the > system to help out on this... Drat. 8) > Luigi -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 00:08:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA26831 for hackers-outgoing; Mon, 21 Jul 1997 00:08:58 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26824 for ; Mon, 21 Jul 1997 00:08:54 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id AAA23335; Mon, 21 Jul 1997 00:08:53 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.6/8.8.5) with SMTP id AAA28929; Mon, 21 Jul 1997 00:08:52 -0700 (PDT) Date: Mon, 21 Jul 1997 00:08:52 -0700 (PDT) From: Chris Timmons Reply-To: Chris Timmons To: Michael Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: suggested enhancement: linux_ioctl.c diagnostic output In-Reply-To: <199707210444.OAA21177@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike, Thanks for the response. > Bruce will have his own interpretation; I would be inclined to say : > > uprintf("LINUX: unimplemented ioctl: fd=%d, cmd=0x%lx (IO%s%s, '%c', %lu, %lu)\n", > args->fd, args->cmd, > (args->cmd & 0x400000000) ? "W" : "", > (args->cmd & 0x800000000) ? "R" : "", > ((args->cmd & 0x0000ff00) >> 8) >= 0x20) > ? (char)((args->cmd & 0x0000ff00)>>8) > : '?', > args->cmd & 0xff, > (args->cmd & 0x3fff0000) >> 16); > > return EINVAL; > } Much easier to understand. I wish I'd thought of your simplification :) As for the is_printable test, would it be also prudent to make sure that the value is < 0x7f as well? I'm pretty naive about character set issues and don't know what some of the values with the 8th bit set might produce. Some of the newer ioctl number assignments start in a range beginning at 0x89 (and beyond.) > The other implementation of the IO[WR] decoding I would consider would > use a small lookup table and a large shift to generate an index. The > massively nested ? set you used makes for very difficult reading. Maybe a lookup table would be the best way to do this neatly in terms of the printf statement. I'll think about that for a while. > I don't think that the performance of the printf() should be a > consideration in contrast to the usefulness of verbose output. Agreed. -Chris > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > From owner-freebsd-hackers Mon Jul 21 00:15:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA27126 for hackers-outgoing; Mon, 21 Jul 1997 00:15:40 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27118 for ; Mon, 21 Jul 1997 00:15:35 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.6/8.8.5) with SMTP id JAA07235; Mon, 21 Jul 1997 09:14:55 +0200 (CEST) Date: Mon, 21 Jul 1997 09:14:54 +0200 (CEST) From: Andrzej Bialecki To: Frank Seltzer cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: sys/vfs.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 20 Jul 1997, Frank Seltzer wrote: > On Sun, 20 Jul 1997, Terry Lambert wrote: > > > > Do we have an equivalent file to this Linux file? I am trying to build > > > XVFilemanager and mount.c has > > > > > > #include > > > > > > which causes the build to fall over. > > > > It depends on what it wants out of it. > > > > Possibilities are: > > > > mount.h Contains mount related structures and manifest > > constants; this is your most likely candidate. > > Note: I am not happy with manifest definitions > > of file system types here; you will probably > > have to add "yet-another-one". This is because > > the BSD mount(2) system call needs a facelift. > > > > vnode_if.h The vnode interface; this file is generated as > > part of the build process by kern/vnode_if.sh. > > > > vnode.h Probably not what you want; details the in-core > > vnode structures. > > > > > > Terry Lambert > > terry@lambert.org > > --- > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > > > > > I will give it a try with these files substituted and see what happens. On > closer inspection, it seems that this app was not written with portability > beyond Linux in mind so I may not have much luck. You may try first to remove this include at all, and see what it complains about (most notably "incomplete type" warnings), and then grep our source tree for these definitions. Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-hackers Mon Jul 21 00:19:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA27275 for hackers-outgoing; Mon, 21 Jul 1997 00:19:11 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA27267 for ; Mon, 21 Jul 1997 00:19:07 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA22125; Mon, 21 Jul 1997 16:48:12 +0930 (CST) From: Michael Smith Message-Id: <199707210718.QAA22125@genesis.atrad.adelaide.edu.au> Subject: Re: suggested enhancement: linux_ioctl.c diagnostic output In-Reply-To: from Chris Timmons at "Jul 21, 97 00:08:52 am" To: skynyrd@opus.cts.cwu.edu Date: Mon, 21 Jul 1997 16:48:11 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Timmons stands accused of saying: > > Thanks for the response. No sweat; like I (should have) said, sorry I was so slow with it. > Much easier to understand. I wish I'd thought of your simplification :) > As for the is_printable test, would it be also prudent to make sure that > the value is < 0x7f as well? I'm pretty naive about character set issues > and don't know what some of the values with the 8th bit set might produce. > Some of the newer ioctl number assignments start in a range beginning at > 0x89 (and beyond.) I think its reasonable to assume that any value >= 0x20 is printable. The only exception I can think of is 0x7f, which may result in only one ' being visible on a serial console. > > The other implementation of the IO[WR] decoding I would consider would > > use a small lookup table and a large shift to generate an index. The > > massively nested ? set you used makes for very difficult reading. > > Maybe a lookup table would be the best way to do this neatly in terms of > the printf statement. I'll think about that for a while. Not using a lookup makes the printf self-contained. I can't think of any other advantages. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 00:42:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28074 for hackers-outgoing; Mon, 21 Jul 1997 00:42:51 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA28066; Mon, 21 Jul 1997 00:42:44 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA20692; Mon, 21 Jul 1997 08:37:06 +0200 From: Luigi Rizzo Message-Id: <199707210637.IAA20692@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 08:37:06 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 03:21:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Aha. May I offer a suggestion? > > Have the 'snd' controller pull in all the modules for the various > on-card subsystems. Have each of these subsystems register themselves > in a linker set using a 'name' field to identify themselves. > > Then have 'device at ...?' statements which pull in probe code for right, but this brings me back to the initial question. What does the config progrm do when it finds a "device at foo?" statement ? I have tried running config with different config files where foo is replaced by bar o rother strings and see no difference in the output . I guess the "isa" keyword is somehow magic (or it becomes specially treated because of something in the "files.i386" file ? Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Jul 21 00:45:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28225 for hackers-outgoing; Mon, 21 Jul 1997 00:45:27 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28207; Mon, 21 Jul 1997 00:45:21 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA22211; Mon, 21 Jul 1997 17:12:58 +0930 (CST) From: Michael Smith Message-Id: <199707210742.RAA22211@genesis.atrad.adelaide.edu.au> Subject: Re: dma handling in the sound driver In-Reply-To: <199707210422.GAA20549@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 06:22:54 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 17:12:58 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > certainly I am not inventing anything :) the problem is that, while > writing, one never knows if sufficient info are given to let > everybody understand all the details, so better give more than be too > criptic. Oh, understood entirely. Likewise my reply 8) > > describe a triple-buffered approach which is more suited to the high > > latency that is often encountered in multiprocessing situations. > > in fact I don't agree that multiprocessors should necessarily have high > latency, and if a critical interrupt (e.g. the one restarting a DMA > transfer) is delayed too much, we are in trouble and get holes in the > i/o no matter what we do... Oops, I meant "multiprogramming", sorry. The big issue with something like this is the possibility that the task responsible for writing audio data may be a long way down the list of runnables. > whoops... I did not think explicitly to autoinit mode, actually I > suspect that some changes are necessary to my scheme to support > automode. I'll look into them, thanks for the suggestion. Sure. Note that autoinit is only suitable for circular buffers. > > If not, there's no apparent need for such a complex approach; you can > > just use three separate buffers each sized suitably to cover the > > latency involved in filling the next. > > not sure. the problem which worries me more is the latency from the > time the write routine is invoked with a large block, and the time the > next buffer is completely filled up by the uiomove. Now you are right > that one could play games such as first mark the buffer as full, with > the appropriate length, and then start the uiomove, in the assumption > that uiomove will finish first anyways (if not interrupted...) ... or you can chunk any copy in in reasonable slabs, and update the DMA controller TC after each slab. ie. for any given write, divide the region being written into page-sized slabs so that you have at most one VM hit per uiomove and then update the DMA after each one. Note that the endleess buffer approach I described specifically tries to avoid the delay problem by trying to keep the buffer as full as possible at all times. It is only in the case where the buffer is almost empty because the writer has lagged that you have to worry about how long a copyin takes. You might also want to check and see if the copyin used by uiomove actually faults the pages first and then copies, or whether it only faults on demand. In this case, doing a full-sized move would actually be faster. Also, consider that the move overhead is really nothing more than another latency item; ie. it's quantitive not qualatative. > yes a lot. An interesting alternative, I just have to see how complex > (and reliable) is to read from the DMA registers on the fly, and how to > do this with the MSS which has some kind of dma support on board. Indeedy. As Amancio said, my suggestion's nothing new either; streaming DMA is probably about as old as double-buffered DMA 8) The former is good for DMA controllers that loop, the latter for those that support buffer chaining. The 8357 doesn't do buffer chaining, so streaming is the way to go. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 00:51:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28484 for hackers-outgoing; Mon, 21 Jul 1997 00:51:58 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28479; Mon, 21 Jul 1997 00:51:55 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA22242; Mon, 21 Jul 1997 17:21:31 +0930 (CST) From: Michael Smith Message-Id: <199707210751.RAA22242@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707210637.IAA20692@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 08:37:06 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 17:21:30 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > Aha. May I offer a suggestion? > > > > Have the 'snd' controller pull in all the modules for the various > > on-card subsystems. Have each of these subsystems register themselves > > in a linker set using a 'name' field to identify themselves. > > > > Then have 'device at ...?' statements which pull in probe code for > > right, but this brings me back to the initial question. What does the > config progrm do when it finds a "device at foo?" statement ? I have > tried running config with different config files where foo is replaced > by bar o rother strings and see no difference in the output . I guess > the "isa" keyword is somehow magic (or it becomes specially treated > because of something in the "files.i386" file ? Oops, my previous wasn't good enough, sorry. The 'device at foo?' doesn't appear to do anything special, and my suggesting it was really wrong. Here, in full glory : controller snd? # sound support, also all chipset modules device zw0 at isa? port... # ZongleWonker ISA board probe ... device bf0 # Bafwangg PCI soundcard probe Then a chipset module might say : struct snddriver_module foo_codec = { foocodec_attach, SNDD_TYPE_CODEC, (void *)foocodec_function_switch, "foo_codec" } DATA_SET(snddriver, foo_codec); Then the 'zw' driver, knowing that the board it had found had a 'foo' codec, would look it up by name in the 'snddriver' linker set, and call its attach function to attach it, passing in the parameters required. Likewise the Bafwang card code would just detect the card and pull up the desired chip driver(s). Does that make more sense? 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 02:04:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA01968 for hackers-outgoing; Mon, 21 Jul 1997 02:04:01 -0700 (PDT) Received: from lab321.ru (root@anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01942 for ; Mon, 21 Jul 1997 02:03:49 -0700 (PDT) Received: from kev.l321.omsk.net.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru SLmail95 v1.0.32 with SMTP id QAA11499; Mon, 21 Jul 1997 16:05:13 +0700 (OSD) Message-ID: <33D3258F.2F1CF0FB@lab321.ru> Date: Mon, 21 Jul 1997 16:02:07 +0700 From: Eugeny Kuzakov Organization: Internet - POINT OF NO RETURN ! X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: erb@inss1.etec.uni-karlsruhe.de CC: hackers@FreeBSD.ORG Subject: Re: integrating ppp-2.3.0, predictor compression References: <199707181914.VAA12362@insl2.etec.uni-karlsruhe.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Olaf Erb wrote: > > Hi, > > are there plans to integrate ppp-2.3.0 w/deflate? I've seen some files were > updated in -current, but still no deflate. I hacked ppp-2.3.0 myself into > a 2.2.2 kernel, but sometimes panics occured I weren't able to track down. > Well, I didn't tried that hard though and gave up quick, it was just > a test to see how good deflate is (it's a lot better than BSD comp). > > Btw, is anyone doing predictor compression for kernel-ppp? I using pppd-2.3.0b3 on 2.1.7.1. Some little patches to compile and no problems in work. But I have problems to compile 2.3.0b3 under 2.2.2. 2.3.0 under 2.1.7.1&2.2.2 too. I have analog dedicated line ( Courier 33600 ) to my ISP. Modem compression enabled. With turned on deflate link speed lower than w/o deflate. MTU 1500. What deflate block size should I use ? Imho, good reason usage of deflate on sync lines. -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Mon Jul 21 02:49:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA03522 for hackers-outgoing; Mon, 21 Jul 1997 02:49:22 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA03516 for ; Mon, 21 Jul 1997 02:49:20 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.65]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-32322U5000L100S10000) with ESMTP id AAA154; Mon, 21 Jul 1997 05:40:52 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.6/8.8.5) id FAA00523; Mon, 21 Jul 1997 05:49:13 -0400 (EDT) Message-ID: <19970721054912.04083@scsn.net> Date: Mon, 21 Jul 1997 05:49:12 -0400 From: "Donald J. Maddox" To: Masachika ISHIZUKA Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: QSeeMe/Linux emul. Problems Reply-To: dmaddox@scsn.net References: <199707210101.KAA19628@genesis.atrad.adelaide.edu.au> <199707210309.MAA04688@onion.ish.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199707210309.MAA04688@onion.ish.org>; from Masachika ISHIZUKA on Mon, Jul 21, 1997 at 12:09:31PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Jul 21, 1997 at 12:09:31PM +0900, Masachika ISHIZUKA wrote: > > > When I try to run QSeeMe 0.80a for Linux, this is what I see: > > > > > > >QSeeMe-0.80a> ./qseeme > > > LINUX: 'ioctl' fd=7, typ=0x450(P), num=0xf not implemented > > > LINUX: 'ioctl' fd=7, typ=0x50(P), num=0x16 not implemented > > Hi. > I'm using FreeBSD 3.0-970618-SNAP and QSeeMe 0.80a for Linux. > When qseeme starts, the same error messages appear, but I can > connect reflectors and play video. (I can't play audio.) > > You must give proper interface at startup. Please check as > follows. > > % ifconfig -a | grep UP|grep -v lo0 > ed0: flags=8843 mtu 1500 > % qseeme -l ed0 > ~~~ > It seems bad to specify any IP address instead of interface > name. Thank you for the information! Apparently, the '-l' flag is the trick I was looking for :-) From owner-freebsd-hackers Mon Jul 21 02:51:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA03599 for hackers-outgoing; Mon, 21 Jul 1997 02:51:16 -0700 (PDT) Received: from insl1.etec.uni-karlsruhe.de (uucp@insl1.etec.uni-karlsruhe.de [129.13.109.178]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA03593 for ; Mon, 21 Jul 1997 02:51:12 -0700 (PDT) Received: (from uucp@localhost) by insl1.etec.uni-karlsruhe.de (8.8.6/8.8.2) with UUCP id LAA10106; Mon, 21 Jul 1997 11:43:08 +0200 (CEST) Received: (from erb@localhost) by insl2.etec.uni-karlsruhe.de (8.8.5/8.8.2) id LAA12218; Mon, 21 Jul 1997 11:42:26 +0200 (CEST) Message-Id: <199707210942.LAA12218@insl2.etec.uni-karlsruhe.de> Subject: Re: integrating ppp-2.3.0, predictor compression In-Reply-To: <33D3258F.2F1CF0FB@lab321.ru> from Eugeny Kuzakov at "Jul 21, 97 04:02:07 pm" To: Eugeny.Kuzakov@lab321.ru (Eugeny Kuzakov) Date: Mon, 21 Jul 1997 11:42:26 +0200 (CEST) Cc: hackers@FreeBSD.ORG Reply-To: erb@inss1.etec.uni-karlsruhe.de From: erb@inss1.etec.uni-karlsruhe.de (Olaf Erb) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eugeny Kuzakov writes: > I have analog dedicated line ( Courier 33600 ) to my ISP. > Modem compression enabled. With turned on deflate link speed lower than > w/o deflate. MTU 1500. What deflate block size should I use ? Try disabing modem compression and enabling deflate, then compare thoughput. With modem compression enabled the modem tries to compress already compressed data. Olaf -- Argue your limitations, and sure enough, they're yours. -- Richard Bach, Illusions From owner-freebsd-hackers Mon Jul 21 03:05:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA04226 for hackers-outgoing; Mon, 21 Jul 1997 03:05:39 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04221 for ; Mon, 21 Jul 1997 03:05:33 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.6/8.8.5) with ESMTP id MAA07593 for ; Mon, 21 Jul 1997 12:07:23 +0200 (CEST) Date: Mon, 21 Jul 1997 12:07:23 +0200 (CEST) From: Andrzej Bialecki To: freebsd-hackers@FreeBSD.ORG Subject: Compressed FS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello! I'm reading the Heidemann's thesis right now (on stackable FS design). He mentions that among others they implemented a compression layer. Did anyone do something similar under FreeBSD? It would be cool to have it, IMHO. Ÿ Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-hackers Mon Jul 21 03:12:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA04453 for hackers-outgoing; Mon, 21 Jul 1997 03:12:06 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA04418 for ; Mon, 21 Jul 1997 03:11:54 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id UAA00760; Mon, 21 Jul 1997 20:11:02 +1000 (EST) Message-Id: <199707211011.UAA00760@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface In-reply-to: Your message of "Mon, 21 Jul 1997 12:37:42 +0930." <199707210307.MAA20639@genesis.atrad.adelaide.edu.au> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 20:10:59 +1000 From: David Nugent Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks for the feedback. > Hmm. "More documentation" 8) It's all there. What's missing? > Seriously; I think that perhaps going in a similar direction to the > /etc/passwd approach might be good; write the 'old-format' files > when generating the records, but use an improved binary format under a > new (but related) filename when accessing it from the library. IMHO, this idea sucks. wtmp files on real systems get large enough already without doing it twice. :-( It isn't too hard to modify legacy code here, and if you looked at the proposed new wtmp.h, you'll find it'll spit out compile warnings (maybe should be error?) for any file that includes it unless it defines a macro first. I'm not certain that this is *the* way to go, though, but I can't think of anything better. > In particular, a self-describing format for something like utmp/wtmp > would be very sexy. Could you explain that further? What is a "self-describing format"? > modes = xl->ll_time ? (O_RDWR|O_CREAT) : O_RDONLY; > if (xl == NULL) > errno = EINVAL; Ouch. I must have been half asleep when I inserted the first line. Fixed, thanks. > This fragment is pretty bad. > > static char sbuf[sizeof(pl) * 2]; > > /* time */ > xl->ll_time = pl.ll_time; > /* line */ > xl->ll_line = strncpy(sbuf + l, pl.ll_line, > sizeof(pl.ll_line)); > sbuf[l + sizeof(pl.ll_line)] = '\0'; > if (!*xl->ll_line) > xl->ll_line = NULL; > else > l += strlen(xl->ll_line) + 1; > /* host */ > xl->ll_host = strncpy(sbuf + l, pl.ll_host, > sizeof(pl.ll_host)); > sbuf[l + sizeof(pl.ll_host)] = '\0'; > if (!*xl->ll_host) > xl->ll_host = NULL; Could you be a little more specific than "pretty bad"? > Using a static buffer here isn't so great either. It's going to give > the threaded version cooties by default. 8) These calls are not intended to be reentrant. There are similar 'problems' with all of the get{pw,gr}*() routines, for example. Calling any of these functions from separate threads is something you just don't do, and for the life of me I can't think of a single reason why you'd ever need to in lastlog's case. :) The alternative is to get into memory allocation, along with all the penalties in runtime and resource use, not to mention bloat. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Mon Jul 21 03:57:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA06578 for hackers-outgoing; Mon, 21 Jul 1997 03:57:19 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA06573 for ; Mon, 21 Jul 1997 03:57:15 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id UAA22881; Mon, 21 Jul 1997 20:26:42 +0930 (CST) From: Michael Smith Message-Id: <199707211056.UAA22881@genesis.atrad.adelaide.edu.au> Subject: Re: utmp/wtmp interface In-Reply-To: <199707211011.UAA00760@labs.usn.blaze.net.au> from David Nugent at "Jul 21, 97 08:10:59 pm" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Mon, 21 Jul 1997 20:26:41 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Nugent stands accused of saying: > Thanks for the feedback. > > > Hmm. "More documentation" 8) > > It's all there. What's missing? Uhm, some idea of what you're heading towards. I misread the lastlog.3 manpage and misunderstood how much of it had been updated too. > > Seriously; I think that perhaps going in a similar direction to the > > /etc/passwd approach might be good; write the 'old-format' files > > when generating the records, but use an improved binary format under a > > new (but related) filename when accessing it from the library. > > IMHO, this idea sucks. wtmp files on real systems get large enough > already without doing it twice. :-( ... so rotate and compress them. This is a management issue; if you care about the information, keep it. If not, discard it. > It isn't too hard to modify > legacy code here, and if you looked at the proposed new wtmp.h, > you'll find it'll spit out compile warnings (maybe should be error?) > for any file that includes it unless it defines a macro first. I'm > not certain that this is *the* way to go, though, but I can't think > of anything better. Fair enough. The point I was making was that the legacy format, or anything vaguely resembing it, is no longer really adequate. If you're not afraid of completely abandoning backwards binary compatability, then sure, just go the whole hog with a new format. > > In particular, a self-describing format for something like utmp/wtmp > > would be very sexy. > > Could you explain that further? What is a "self-describing format"? A file format which contains meta-data describing the layout of the file. Eg. at the head of the file, start with a record containing the length of records in the file, followed by field, length tuples describing the type and length of each of the fields in a record. For utmp, you might do : 0x0000 0x00000100 # 256-byte records 0x0004 0x00000001 # username 0x0008 0x00000020 # 32 bytes 0x000c 0x00000002 # login time 0x0010 0x00000004 # 4 bytes 0x0014 0x00000003 # source host IP 0x0018 0x00000004 # 4 bytes 0x001c 0x00000004 # source hostname 0x0020 0x00000080 # 128 bytes Parsing this is very straightforward, as is using it to obtain the fields you want. You can add new fields to the file, change the size of fields, etc. without ever breaking binary compatability again. Because records in the file are fixed in size, you can treat it as a random-access file too. > > This fragment is pretty bad. > > > > static char sbuf[sizeof(pl) * 2]; > > Could you be a little more specific than "pretty bad"? I was repeating myself; sorry, ref. the static buffer. > > Using a static buffer here isn't so great either. It's going to give > > the threaded version cooties by default. 8) > > These calls are not intended to be reentrant. There are similar 'problems' > with all of the get{pw,gr}*() routines, for example. Calling any of these > functions from separate threads is something you just don't do, and for > the life of me I can't think of a single reason why you'd ever need to > in lastlog's case. :) Call it a matter of principle. 8) I realise that the alternative is a little more work. > The alternative is to get into memory allocation, along with all the > penalties in runtime and resource use, not to mention bloat. *shrug* I don't think the penalties are really that bad, but it's not something I'd fight over. > David -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 04:07:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA06933 for hackers-outgoing; Mon, 21 Jul 1997 04:07:08 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA06924; Mon, 21 Jul 1997 04:06:36 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA20937; Mon, 21 Jul 1997 12:04:22 +0200 From: Luigi Rizzo Message-Id: <199707211004.MAA20937@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 12:04:22 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210751.RAA22242@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 05:21:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > Aha. May I offer a suggestion? > > > > > > Have the 'snd' controller pull in all the modules for the various > > > on-card subsystems. Have each of these subsystems register themselves > > > in a linker set using a 'name' field to identify themselves. > > > > > > Then have 'device at ...?' statements which pull in probe code for > > > > right, but this brings me back to the initial question. What does the > > config progrm do when it finds a "device at foo?" statement ? I have > > tried running config with different config files where foo is replaced > > by bar o rother strings and see no difference in the output . I guess > > the "isa" keyword is somehow magic (or it becomes specially treated > > because of something in the "files.i386" file ? > > Oops, my previous wasn't good enough, sorry. > > The 'device at foo?' doesn't appear to do anything special, and my > suggesting it was really wrong. > > Here, in full glory : > > controller snd? # sound support, also all chipset modules > > device zw0 at isa? port... # ZongleWonker ISA board probe > ... > device bf0 # Bafwangg PCI soundcard probe > > > Then a chipset module might say : > > struct snddriver_module foo_codec = { > foocodec_attach, > SNDD_TYPE_CODEC, > (void *)foocodec_function_switch, > "foo_codec" > } > DATA_SET(snddriver, foo_codec); ... > Does that make more sense? 8) well, this is exactly what I have done! One minor difference, I have used a "struct pnp_device" as follows: static struct pnp_device cs4236 = { "cs4236", cs4236_probe, cs4236_attach, &cs4236_count, NULL, /* shutdown */ &tty_imask /* imask */ }; so that I can easily use a different imask when needed. Maybe I will need more fields in the struct pnp_device to make the mechanism more flexible for other device types. In fact the structure should be the same for ISA/PnP and PCI device, but I understand that support for autoconfiguring devices has been added according to the needs of specific buses and the mechanism is not as clean as it might be. When I am done with the PnP stuff I will talk back to those who implemented the pci things to discuss this item. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Jul 21 04:21:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA07689 for hackers-outgoing; Mon, 21 Jul 1997 04:21:47 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA07672; Mon, 21 Jul 1997 04:21:30 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id UAA22939; Mon, 21 Jul 1997 20:41:25 +0930 (CST) From: Michael Smith Message-Id: <199707211111.UAA22939@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707211004.MAA20937@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 12:04:22 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 20:41:25 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > > Then a chipset module might say : > > > > struct snddriver_module foo_codec = { > > foocodec_attach, > > SNDD_TYPE_CODEC, > > (void *)foocodec_function_switch, > > "foo_codec" > > } > > DATA_SET(snddriver, foo_codec); > ... > > Does that make more sense? 8) > > well, this is exactly what I have done! One minor difference, I have > used a "struct pnp_device" as follows: Hmm, you are going out further. I think it is not good at all to call this a "PnP" device; I think that the generic PnP support linker set needs more flexibility than this. (But you're on the right track.) > static struct pnp_device cs4236 = { > "cs4236", > cs4236_probe, > cs4236_attach, > &cs4236_count, > NULL, /* shutdown */ > &tty_imask /* imask */ > }; > > so that I can easily use a different imask when needed. > Maybe I will need more fields in the struct pnp_device to make the > mechanism more flexible for other device types. Oops, reading my thoughts. Do you have copies of Doug Rabson's work on cleaning up the ISA autoconfig process? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 04:47:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA08930 for hackers-outgoing; Mon, 21 Jul 1997 04:47:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08902; Mon, 21 Jul 1997 04:46:44 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA10007; Mon, 21 Jul 1997 21:33:47 +1000 Date: Mon, 21 Jul 1997 21:33:47 +1000 From: Bruce Evans Message-Id: <199707211133.VAA10007@godzilla.zeta.org.au> To: bde@zeta.org.au, se@FreeBSD.ORG Subject: Re: snd driver attach routine Cc: hackers@FreeBSD.ORG, hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it, multimedia@FreeBSD.ORG, rhh@ct.picker.com Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >Problem: what should be the return type of *attach() routines ? >> >> Perhaps it should be void to match reality, but it currently must be >> int for isa drivers to match the prototype in `struct isa_driver'. >> >> >The drivers in /sys/pci all return void for the attach routine. >> >> They have to, to match the prototype in `strcuct pci_driver'. > >I could easily change the return type of >the PCI attach function. Should I ??? If anything is attached above the driver level, then you need a status from the driver attach to decide whether to clean up or attach more. For ISA, only interrupts are attached at a high level, but they shouldn't be, so ISA attach function shouldn't need to return status (but they should clean up if they fail). I'm not sure about PCI. Bruce From owner-freebsd-hackers Mon Jul 21 04:52:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA09161 for hackers-outgoing; Mon, 21 Jul 1997 04:52:52 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA09074; Mon, 21 Jul 1997 04:51:47 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA21030; Mon, 21 Jul 1997 12:48:38 +0200 From: Luigi Rizzo Message-Id: <199707211048.MAA21030@labinfo.iet.unipi.it> Subject: Re: snd driver attach routine To: bde@zeta.org.au (Bruce Evans) Date: Mon, 21 Jul 1997 12:48:38 +0200 (MET DST) Cc: bde@zeta.org.au, se@FreeBSD.ORG, hackers@FreeBSD.ORG, hasty@rah.star-gate.com, multimedia@FreeBSD.ORG, rhh@ct.picker.com In-Reply-To: <199707211133.VAA10007@godzilla.zeta.org.au> from "Bruce Evans" at Jul 21, 97 09:33:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > >> >Problem: what should be the return type of *attach() routines ? > >> > >> Perhaps it should be void to match reality, but it currently must be > >> int for isa drivers to match the prototype in `struct isa_driver'. > >> > >> >The drivers in /sys/pci all return void for the attach routine. > >> > >> They have to, to match the prototype in `strcuct pci_driver'. > > > >I could easily change the return type of > >the PCI attach function. Should I ??? > > If anything is attached above the driver level, then you need a status > from the driver attach to decide whether to clean up or attach more. > For ISA, only interrupts are attached at a high level, but they shouldn't > be, so ISA attach function shouldn't need to return status (but they > should clean up if they fail). I'm not sure about PCI. I think this should be done in a bus-independent way, and surely the safest way is to always return an error code. Then you have the freedom or ignoring it or not. Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Jul 21 05:24:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA10633 for hackers-outgoing; Mon, 21 Jul 1997 05:24:30 -0700 (PDT) Received: from watson.grauel.com (watson.grauel.com [199.233.104.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10627 for ; Mon, 21 Jul 1997 05:24:28 -0700 (PDT) Received: from sparcmill.grauel.com (sparcmill.grauel.com [199.233.104.34]) by watson.grauel.com (8.8.5/8.7.3) with SMTP id HAA13834; Mon, 21 Jul 1997 07:24:19 -0500 (EST) Received: by sparcmill.grauel.com (SMI-8.6/SMI-SVR4) id HAA17629; Mon, 21 Jul 1997 07:21:57 -0500 Date: Mon, 21 Jul 1997 07:21:57 -0500 Message-Id: <199707211221.HAA17629@sparcmill.grauel.com> From: Richard J Kuhns MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: Richard J Kuhns , Michael Smith , hackers@FreeBSD.ORG Subject: Re: Supermicro P6SNE manuals? In-Reply-To: References: <199707171424.JAA00989@sparcmill.grauel.com> <199707170932.TAA28622@genesis.atrad.adelaide.edu.au> X-Mailer: VM 6.30 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh writes: > > However, are the pins on the motherboard numbered: > 1 2 3 4 5 > 6 7 8 9 10 > or > 1 3 5 7 9 > 2 4 6 8 10 > > I'd really like to know. I suspect that the company that sole me my > PPro back in march shipped the wrong kind of cable because swapping in > a different cable fixed the problem (and I know have both 1-2 and 1-6 > cables laying around). > > Warner > Sorry, I'm not sure. Can you suggest an easy/safe way to find out? I really don't want to take my machine apart again, but it would be worth it to find out. Pin 1 was labelled and pin 10 was missing, but that doesn't really help anything :( -- Richard Kuhns rjk@grauel.com PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 / From owner-freebsd-hackers Mon Jul 21 06:50:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA14091 for hackers-outgoing; Mon, 21 Jul 1997 06:50:27 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA14082 for ; Mon, 21 Jul 1997 06:50:24 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id PAA09544; Mon, 21 Jul 1997 15:52:29 +0200 (CEST) From: Mikael Karpberg Message-Id: <199707211352.PAA09544@ocean.campus.luth.se> Subject: Re: utmp/wtmp interface In-Reply-To: <199707211056.UAA22881@genesis.atrad.adelaide.edu.au> from Michael Smith at "Jul 21, 97 08:26:41 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 15:52:29 +0200 (CEST) Cc: davidn@labs.usn.blaze.net.au, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok... I just have to comment on this... According to Michael Smith: [... snip ...] > > Could you explain that further? What is a "self-describing format"? > > A file format which contains meta-data describing the layout of the > file. Eg. at the head of the file, start with a record containing > the length of records in the file, followed by field, length tuples > describing the type and length of each of the fields in a record. > > For utmp, you might do : > > 0x0000 0x00000100 # 256-byte records > 0x0004 0x00000001 # username > 0x0008 0x00000020 # 32 bytes > 0x000c 0x00000002 # login time > 0x0010 0x00000004 # 4 bytes > 0x0014 0x00000003 # source host IP > 0x0018 0x00000004 # 4 bytes > 0x001c 0x00000004 # source hostname > 0x0020 0x00000080 # 128 bytes > > Parsing this is very straightforward, as is using it to obtain the > fields you want. You can add new fields to the file, change the size > of fields, etc. without ever breaking binary compatability again. > Because records in the file are fixed in size, you can treat it as a > random-access file too. This sounds like an excellent idea to me. The library code for this would always be 100% backwards compatible if written correctly with the correct API towards the library user. One thing though: If you're going to label the fields (1, 2, 3, etc) then why not do it in a logical fashoin instead of some annoying enumeration? You have four bytes, so use them! :-) 0x0000 0x00000100 # 256-byte records 0x0004 'U', 'S', 'E', R' # USERname 0x0008 0x00000020 # 32 bytes 0x000c 'I', 'T', 'I', 'M' # logIn TIMe 0x0010 0x00000004 # 4 bytes 0x0014 'H', '_', 'I', 'P' # source Host IP 0x0018 0x00000004 # 4 bytes 0x001c 'H', 'N', 'A', 'M' # source HostNAMe 0x0020 0x00000080 # 128 bytes Then the function can take a string argument from which the four first characters are used, which makes code more readable. ptr = get_an_entry("USER"); ptr = get_an_entry("H_IP"); Now... this all sounds great to me, but I might have missed something. Any reactions? [... snip ...] > > These calls are not intended to be reentrant. There are similar 'problems' > > with all of the get{pw,gr}*() routines, for example. Calling any of these > > functions from separate threads is something you just don't do, and for > > the life of me I can't think of a single reason why you'd ever need to > > in lastlog's case. :) > > Call it a matter of principle. 8) I realise that the alternative is a > little more work. Actually, libc should NOT be reentrant, should it? Only libc_r should be, and will be linked at giving -thread to the compiler/linker. Or is this not in libc? :-) If you want the functions reentrant, just do it like this? ptr = internal_thread_specific_data[my_thread_id][this_function_id]; if (ptr == NULL) { internal_thread_specific_data[my_thread_id][this_function_id] = malloc(BUFFERSIZE_FOR_THIS_FUNCTION); } ... go ahead and use the buffer ... That way you can return a static buffer per thread, so it's threadsafe. The buffer returned will be overwritten by each call and so only allocated once. Therefor it's no big speed loss. If it's just run once, you really don't need it to be any quicker then that, and if it's run a lot, you just pay the penalty for a malloc once. /Mikael From owner-freebsd-hackers Mon Jul 21 07:43:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA16376 for hackers-outgoing; Mon, 21 Jul 1997 07:43:28 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA16368 for ; Mon, 21 Jul 1997 07:43:21 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id AAA00370; Tue, 22 Jul 1997 00:42:38 +1000 (EST) Message-Id: <199707211442.AAA00370@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface In-reply-to: Your message of "Mon, 21 Jul 1997 20:26:41 +0930." <199707211056.UAA22881@genesis.atrad.adelaide.edu.au> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jul 1997 00:42:38 +1000 From: David Nugent Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's all there. What's missing? > > Uhm, some idea of what you're heading towards. I misread the lastlog.3 > manpage and misunderstood how much of it had been updated too. All that's different is a standardised API. In fact, this goes for all of the modules. Nothing has (yet) changed about any of the file formats - which a "suggested" alternate implementation for wtmp is there (#defined out), and utmp has become a runtime re-sizeable fixed record file, by default, these files use precisely the same format that they currently use. What I am attempting to do is to define an API to access these files, not radically change the format of the files overnight. That can come later, AFTER things use the API rather than use the files directly. There *is* provision for "additional" information to be added, and for utmp this is fairly easy using a slight variation of the current format (by enlarging each record, and the record size is determined at runtime rather than being a sizeof anything), and for wtmp would definitely require a change in format. Personally, I prever a text-based format with extensions in keyword=data style or something similar. You can deal with that in any language - even /bin/sh - with very little loss in performance. The idea is not to change the format of the files immediately, but to first define an API to access them so that it allows the format to be changed at whim later, without breaking compatibility with code that uses the API, both source AND binary compatibility, and old data retained and usable ad infinitum. We can at last kiss goodbye to the problems with XFree and other things that access utmp/wtmp directly. > Fair enough. The point I was making was that the legacy format Actually, it isn't really "legacy" - IIRC wtmp/utmp are fairly recent additions to BSD and utmp/wtmp implementations vary widely between systems already, so one more variation is no big deal. :-) I'm hoping that other OS's may adopt the same approach and hide their implementation somewhere in some system library, but I'm not about to hold my breath. :-) Still, it is the idea that counts. > > Could you explain that further? What is a "self-describing format"? > > A file format which contains meta-data describing the layout of the > file. Eg. at the head of the file, start with a record containing > the length of records in the file, followed by field, length tuples > describing the type and length of each of the fields in a record. Yuck. This is overkill. The idea behind the API is to have a library to access and update the database - noone should care beyond that what format the files actually use. This approach would seem to make a simple thing complex, and even encourage other software to bypass the API, which is not the idea at all. > Parsing this is very straightforward, as is using it to obtain the > fields you want. You can add new fields to the file, change the size > of fields, etc. without ever breaking binary compatability again. But you have broken compatibility. You've just thrown out all of your existing data. It also assumes fixed length fields which, in a logfile that is assumed to grow forever, is inappropriate. > Because records in the file are fixed in size, you can treat it as a > random-access file too. This is fine for utmp, but not wtmp. wtmp *needs* to be in variable length format. > > > static char sbuf[sizeof(pl) * 2]; > > > > Could you be a little more specific than "pretty bad"? > > I was repeating myself; sorry, ref. the static buffer. Ok. The "either" threw me, thinking you were discussing two different things: > > > Using a static buffer here isn't so great either. It's going to give > > > the threaded version cooties by default. 8) ~ > > These calls are not intended to be reentrant. > > Call it a matter of principle. 8) I realise that the alternative is a > little more work. Absolutely it is, and the penalty is paid by the non-threaded version, and it makes the code more complex then it need be in any case. The point is whether there is any benefit in making it thread-safe. :-) Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Mon Jul 21 07:46:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA16501 for hackers-outgoing; Mon, 21 Jul 1997 07:46:29 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA16493 for ; Mon, 21 Jul 1997 07:46:26 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wqJiz-0001N8-00; Mon, 21 Jul 1997 08:46:09 -0600 To: Richard J Kuhns Subject: Re: Supermicro P6SNE manuals? Cc: Michael Smith , hackers@freebsd.org In-reply-to: Your message of "Mon, 21 Jul 1997 07:21:57 CDT." <199707211221.HAA17629@sparcmill.grauel.com> References: <199707211221.HAA17629@sparcmill.grauel.com> <199707171424.JAA00989@sparcmill.grauel.com> <199707170932.TAA28622@genesis.atrad.adelaide.edu.au> Date: Mon, 21 Jul 1997 08:46:09 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707211221.HAA17629@sparcmill.grauel.com> Richard J Kuhns writes: : Sorry, I'm not sure. Can you suggest an easy/safe way to find out? I : really don't want to take my machine apart again, but it would be worth it : to find out. Pin 1 was labelled and pin 10 was missing, but that doesn't : really help anything :( The safest way is to get a manual for the board :-(... Warner From owner-freebsd-hackers Mon Jul 21 07:50:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA16847 for hackers-outgoing; Mon, 21 Jul 1997 07:50:55 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA16833 for ; Mon, 21 Jul 1997 07:50:51 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id AAA23903; Tue, 22 Jul 1997 00:20:35 +0930 (CST) From: Michael Smith Message-Id: <199707211450.AAA23903@genesis.atrad.adelaide.edu.au> Subject: Re: Supermicro P6SNE manuals? In-Reply-To: from Warner Losh at "Jul 21, 97 08:46:09 am" To: imp@rover.village.org (Warner Losh) Date: Tue, 22 Jul 1997 00:20:34 +0930 (CST) Cc: rjk@sparcmill.grauel.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > In message <199707211221.HAA17629@sparcmill.grauel.com> Richard J Kuhns writes: > : Sorry, I'm not sure. Can you suggest an easy/safe way to find out? I > : really don't want to take my machine apart again, but it would be worth it > : to find out. Pin 1 was labelled and pin 10 was missing, but that doesn't > : really help anything :( > > The safest way is to get a manual for the board :-(... Is this still on the SuperMicro board? I discovered that they do it the "right" way, ie. a crimp D9 on one end of a ribbon cable and a crimp IDC10 on the other "just works". The other pinout is an abomination, and as someone who spends my fair share of time pushing polygons laying out PCBs, I swear whoever came up with it SHOULD BE SHOT! > Warner -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 08:27:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA18560 for hackers-outgoing; Mon, 21 Jul 1997 08:27:27 -0700 (PDT) Received: from trem.cnt.org.br (trem.cnt.org.br [200.19.123.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA18537 for ; Mon, 21 Jul 1997 08:27:17 -0700 (PDT) Received: by trem.cnt.org.br (AIX 3.2/UCB 5.64/4.03) id AA31840; Mon, 21 Jul 1997 12:18:35 -0200 From: ormonde@trem.cnt.org.br (Rodrigo Ormonde) Message-Id: <9707211418.AA31840@trem.cnt.org.br> Subject: keepalive time interval To: hackers@freebsd.org Date: Mon, 21 Jul 1997 12:18:34 -0200 (GRNLNDDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello. I'm writing a daemon process that listens to connections on a socket. I don't want to have my daemon waiting forever to receive data from a dead client, so I'm using the SO_KEEPALIVE option on the socket. The problem is that the default time that the system waits until it discover that the client no longer exists is too long for my needs. Is there a way to change this default time by a system call ? If it's not possible, could someone point me what I have to change in the kernel source code to reduce this value ? Thanks in advance. P.S. Please send a copy of the answers to me, I'm not on the list. -- Rodrigo de La Rocque Ormonde e-mail: ormonde@cnt.org.br PGP Public key: finger ormonde@cnt.org.br -> Turn your PC into a workstation - Use FreeBSD ! <- From owner-freebsd-hackers Mon Jul 21 09:46:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23225 for hackers-outgoing; Mon, 21 Jul 1997 09:46:23 -0700 (PDT) Received: from schubert.promo.de (schubert.Promo.DE [194.45.188.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23212 for ; Mon, 21 Jul 1997 09:46:18 -0700 (PDT) Received: from [194.45.188.81] (stefan.Promo.DE [194.45.188.81]) by schubert.promo.de (8.8.5/8.8.5) with ESMTP id SAA26161; Mon, 21 Jul 1997 18:31:18 +0200 (MET DST) X-Sender: stefan@mail.promo.de Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jul 1997 18:35:42 +0200 To: netatalk-admins@umich.edu, freebsd-hackers@freebsd.org From: Stefan Bethke Subject: [ANNOUNCE] MacIP Gateway for FreeBSD - 1st beta release Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is the first beta release of macipgw, a MacIP gateway for FreeBSD, available for downlooad from http://www.promo.de/pub/people/stefan/netatalk/macipgw-1.0b1.tar.gz or ftp://ftp.promo.de/pub/people/stefan/netatalk/macipgw-1.0b1.tar.gz MacIP is a protocol that allows the encapsulation of IP packets in AppleTalk packets, thus allowing Macs connected through an AppleTalk-only network (such as LocalTalk or Apple Remote Access) to use TCP/IP-based services. To use macipgw, you need FreeBSD 2.1.5 or newer with AppleTalk kernel patches (see ftp://ftp.promo.de/pub/people/stefan/netatalk/) or FreeBSD 2.2.1 or newer. Also, you'll need one tunnel device for macipgw, see tun(4) for details. Please direct questions, comments, diffs to . -- Stefan Bethke Promo Datentechnik | Tel. +49-40-851744-0 + Systemberatung GmbH | Fax. +49-40-851744-44 Eduardstrasse 46-48 | e-mail: stefan@Promo.DE D-20257 Hamburg | http://www.Promo.DE/ From owner-freebsd-hackers Mon Jul 21 09:49:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23452 for hackers-outgoing; Mon, 21 Jul 1997 09:49:08 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23447 for ; Mon, 21 Jul 1997 09:49:05 -0700 (PDT) Received: from localhost (brightmn@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id MAA09936 for ; Thu, 3 Jul 1997 12:51:45 GMT Date: Thu, 3 Jul 1997 12:51:45 +0000 (GMT) From: Alfred Perlstein To: hackers@FreeBSD.ORG Subject: File systems slowness? In-Reply-To: <199707210637.IAA20692@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I really like freebsd, however when i did a "rm -rf *" in the /usr/ports directory it took over 5 minutes to clear the directory. My system is a 586/133 with 64megs of ram, the motherboard supports mode 4 PIO and mode 2 DMA, i know there are a lot of files in that directory, but isn't that a little excessive? I assume the disk was going crazy going back and forth from inode space to data space on the disk... but with 64 megs of ram i thought it would try some caching perhaps? doesn't freebsd have write-behind caching? or does it need to be enabled seperately? Alfred Perlstein perlsta@sunyit.edu From owner-freebsd-hackers Mon Jul 21 09:58:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24194 for hackers-outgoing; Mon, 21 Jul 1997 09:58:02 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24173; Mon, 21 Jul 1997 09:57:55 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id JAA05307; Mon, 21 Jul 1997 09:57:51 -0700 (PDT) Message-Id: <199707211657.JAA05307@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org cc: multimedia@freebsd.org, Luigi Rizzo Subject: auto dma? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 09:57:51 -0700 From: Amancio Hasty Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk luigi@labinfo.iet.unipi.it said: > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > buffer, but unfortunately there are no support routines to read the > current transfer status from the dma registers and I have to write > them myself. This also means that the old sound driver probably did > not really work very reliably, and explains why someone was reporting > that pieces of sound were repeating multiple times. Does anyone know how to read the current number of bytes transferred in in a dma transfer? It will be kind of nice to know as a safe guard for cards which occasionlly fail to generate an interrupt and yes I do have such a card is the SB16... Tnks, Amancio From owner-freebsd-hackers Mon Jul 21 10:25:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26297 for hackers-outgoing; Mon, 21 Jul 1997 10:25:41 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26291 for ; Mon, 21 Jul 1997 10:25:38 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA12093; Mon, 21 Jul 1997 11:23:36 -0600 (MDT) Message-Id: <199707211723.LAA12093@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Michael Smith cc: hlew@www2.shoppersnet.com (Howard Lew), rb@gid.co.uk, hackers@FreeBSD.ORG Subject: Re: Iomega Zip In-reply-to: Your message of "Sat, 19 Jul 1997 14:11:36 +0930." <199707190441.OAA12625@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 11:23:35 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Howard Lew stands accused of saying: >> >> The probe doesn't look right, but it works: > >The probe is _exactly_ right. > >> sd0 at scbus0 target 5 lun 0 >> sd0: Direct-Access >> sd0: ILLEGAL REQUEST asc:24,0 Invalid field in CDB >> sd0 could not mode sense (4). Using ficticious geometry > >The drive has refused a MODE SENSE command, so it's not possible to >establish its geometry. Geometry is only (really) relevant for >processing the MBR. Instead, the driver will fake some sensible >falues. Actually, the probe is what you should expect from the current SCSI code, but the current SCSI code isn't really right. It should be using the READ CAPACITY command in order to determine the size of the disk and not even bothering to attempt to get the geometry from the mode pages. In the case of a PC, you want the controller to tell you the geometry to use, based on the size of the device, since the one the drive will give you (assuming it supports that mode page) is quite useless. On other architectures, you may not need a specific geometry as specified by the controller (in PC land, this is only required in order to setup the partition table so you can find the boot block), but it would be trivial to have a generic and efficient geometry placed in the disklabel. In general, it would be nice if no layer above the device driver cared about the geometry of the device and that all BSD partitioning could be performed on arbitrary sector boundaries. >-- >]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ >]] Genesis Software genesis@gsoft.com.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control. (ph) +61-8-8267-3493 [[ >]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Mon Jul 21 10:41:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27615 for hackers-outgoing; Mon, 21 Jul 1997 10:41:52 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27607 for ; Mon, 21 Jul 1997 10:41:49 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id DAA24563; Tue, 22 Jul 1997 03:11:38 +0930 (CST) From: Michael Smith Message-Id: <199707211741.DAA24563@genesis.atrad.adelaide.edu.au> Subject: Re: File systems slowness? In-Reply-To: from Alfred Perlstein at "Jul 3, 97 12:51:45 pm" To: brightmn@a-v25.rh.sunyit.edu (Alfred Perlstein) Date: Tue, 22 Jul 1997 03:11:38 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alfred Perlstein stands accused of saying: > > My system is a 586/133 with 64megs of ram, the motherboard supports mode 4 > PIO and mode 2 DMA, i know there are a lot of files in that directory, but > isn't that a little excessive? I assume the disk was going crazy going > back and forth from inode space to data space on the disk... but with 64 > megs of ram i thought it would try some caching perhaps? It does. What you are seeing are synchronous metadata updates. > doesn't freebsd have write-behind caching? or does it need to be enabled > seperately? Mount the filesystem with the 'async' option. This is less conservative than the default, which seeks to maximise reliabilty by trading off speed. > Alfred Perlstein -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 10:45:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27930 for hackers-outgoing; Mon, 21 Jul 1997 10:45:12 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27882; Mon, 21 Jul 1997 10:44:59 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id DAA24577; Tue, 22 Jul 1997 03:14:44 +0930 (CST) From: Michael Smith Message-Id: <199707211744.DAA24577@genesis.atrad.adelaide.edu.au> Subject: Re: auto dma? In-Reply-To: <199707211657.JAA05307@rah.star-gate.com> from Amancio Hasty at "Jul 21, 97 09:57:51 am" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 22 Jul 1997 03:14:44 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, luigi@labinfo.iet.unipi.it X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty stands accused of saying: > > luigi@labinfo.iet.unipi.it said: > > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > > buffer, but unfortunately there are no support routines to read the > > current transfer status from the dma registers and I have to write > > them myself. This also means that the old sound driver probably did > > not really work very reliably, and explains why someone was reporting > > that pieces of sound were repeating multiple times. > > Does anyone know how to read the current number of bytes transferred in > in a dma transfer? > It will be kind of nice to know as a safe guard for cards which > occasionlly fail to generate an interrupt and yes I do have such a card > is the SB16... This was one of the reasons behind my suggesting that a 1/hz timeout should be running whenever the sound output is running. 1/128th of a second is a fairly short glitch for end-of-sample overrun. If you haven't got an answer by tomorrow (my time; mid-afternoon today your time) I will rummage my Intel databook and get back to you on that one. > Amancio -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 10:46:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28065 for hackers-outgoing; Mon, 21 Jul 1997 10:46:26 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA28056 for ; Mon, 21 Jul 1997 10:46:23 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wqMQY-0001OB-00; Mon, 21 Jul 1997 10:39:18 -0700 Date: Mon, 21 Jul 1997 10:39:17 -0700 (PDT) From: Tom Samplonius To: Alfred Perlstein cc: hackers@freebsd.org Subject: Re: File systems slowness? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Jul 1997, Alfred Perlstein wrote: ... > doesn't freebsd have write-behind caching? or does it need to be enabled > seperately? Directory meta information is written immediately to disk. If it wasn't, you risk severe file system damage during a power failure. See the man page for mount on how to mount stuff async, and for more warnings on the risks. > Alfred Perlstein > perlsta@sunyit.edu > > > Tom From owner-freebsd-hackers Mon Jul 21 11:05:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29652 for hackers-outgoing; Mon, 21 Jul 1997 11:05:00 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA29624; Mon, 21 Jul 1997 11:04:40 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA21422; Mon, 21 Jul 1997 19:01:59 +0200 From: Luigi Rizzo Message-Id: <199707211701.TAA21422@labinfo.iet.unipi.it> Subject: Re: auto dma? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 19:01:59 +0200 (MET DST) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: <199707211744.DAA24577@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 22, 97 03:14:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Amancio Hasty stands accused of saying: > > > > luigi@labinfo.iet.unipi.it said: > > > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > > > buffer, but unfortunately there are no support routines to read the ... > > Does anyone know how to read the current number of bytes transferred in > > in a dma transfer? the intel data sheet for the i82371 (also known as PIIX), a PCI chipset which implements a number of standard isa devices including timer and dma controller, is available at the intel site (www.intel.com). Although it probably is not exactly the same as the original 8237, it myght still give some ideas on what to do. The main problem with old peripherals is that they often did not allow a safe reading of 16-bit registers such as counters, which can be incremented while you read the two pieces. I don't know if this affected the original 8237, but sure was a problem with some old PC timer. Apart from this, I'd look in the PIIX data sheet. Finally, if someone is familiar with Linux or NetBSD kernel (specifically for the isa routines) let me know. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Mon Jul 21 11:11:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29944 for hackers-outgoing; Mon, 21 Jul 1997 11:11:15 -0700 (PDT) Received: from agni.nuko.com ([206.79.130.80]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA29939 for ; Mon, 21 Jul 1997 11:11:09 -0700 (PDT) Received: (from vinay@localhost) by agni.nuko.com (8.8.5/8.7.3) id LAA02995; Mon, 21 Jul 1997 11:07:21 -0700 (PDT) From: Vinay Bannai Message-Id: <199707211807.LAA02995@agni.nuko.com> Subject: Re: keepalive time interval To: ormonde@trem.cnt.org.br (Rodrigo Ormonde) Date: Mon, 21 Jul 1997 11:07:20 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <9707211418.AA31840@trem.cnt.org.br> from "Rodrigo Ormonde" at "Jul 21, 97 12:18:34 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Rodrigo Ormonde: > Hello. > > I'm writing a daemon process that listens to connections on a socket. I > don't want to have my daemon waiting forever to receive data from a dead > client, so I'm using the SO_KEEPALIVE option on the socket. The problem is > that the default time that the system waits until it discover that the > client no longer exists is too long for my needs. > > Is there a way to change this default time by a system call ? If it's not > possible, could someone point me what I have to change in the kernel source > code to reduce this value ? > > Thanks in advance. > > P.S. Please send a copy of the answers to me, I'm not on the list. > > -- > Rodrigo de La Rocque Ormonde > e-mail: ormonde@cnt.org.br > PGP Public key: finger ormonde@cnt.org.br > > -> Turn your PC into a workstation - Use FreeBSD ! <- Well, keeptime timer is reset to 2 hours every time a segment is received for the connection. If the keepalive option is set for the socket then this timer is enforced by dropping the connection after a set number of no responses to the probes (this comes to 9 probes set at 75 seconds apart). The first probe is sent after 2 hours of idle time. Now to change these default values, you have to edit the tcp timers file /usr/src/sys/netinet/tcp_timers.h The variables that you would be interested in messing around would be TCPTV_KEEP_INIT TCPTV_KEEP_IDLE TCPTV_KEEPINTVL TCPTV_KEEPCNT But, remember change at your own peril. If you make the keep alive timers smaller than the RTT (which itself varies based on the congestion on the network) then you have to deal with connections getting dropped for problems other than network connectivity. A more elegant solution would be to use the application level probes and not depend on the TCP keep alives, which are not a requirement for the TCP implementation as per the RFC's. Vinay -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From owner-freebsd-hackers Mon Jul 21 11:22:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00827 for hackers-outgoing; Mon, 21 Jul 1997 11:22:49 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00807; Mon, 21 Jul 1997 11:22:42 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id DAA24761; Tue, 22 Jul 1997 03:51:39 +0930 (CST) From: Michael Smith Message-Id: <199707211821.DAA24761@genesis.atrad.adelaide.edu.au> Subject: Re: auto dma? In-Reply-To: <199707211701.TAA21422@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 07:01:59 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 22 Jul 1997 03:51:38 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > the intel data sheet for the i82371 (also known as PIIX), a PCI chipset > which implements a number of standard isa devices including timer and > dma controller, is available at the intel site (www.intel.com). > > Although it probably is not exactly the same as the original 8237, it > myght still give some ideas on what to do. It almost certainly uses a "real" 8237 macrocell, so it's likely to behave as near to identically as can be expected. > The main problem with old > peripherals is that they often did not allow a safe reading of 16-bit > registers such as counters, which can be incremented while you read the > two pieces. I don't know if this affected the original 8237, but sure > was a problem with some old PC timer. It was? Unless I'm muchly mistaken, even the 8253 supports the counter latch command. Our gear is full of 8254's; I have bad nightmares every time I have to work on the code that manages them, but for all that they're not _that_ bad. > Finally, if someone is familiar with Linux or NetBSD kernel > (specifically for the isa routines) let me know. Uh, "sorta" (NetBSD). Probably not to the level that you are after though. > Luigi -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 11:35:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA01655 for hackers-outgoing; Mon, 21 Jul 1997 11:35:14 -0700 (PDT) Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01649; Mon, 21 Jul 1997 11:35:10 -0700 (PDT) Received: (from mdtancsa@localhost) by granite.sentex.net (8.8.5/8.6.9) id OAA29815; Mon, 21 Jul 1997 14:43:48 -0400 (EDT) From: Mike D Tancsa Message-Id: <199707211843.OAA29815@granite.sentex.net> Subject: preventing ICMP echo requests to the broadcast address To: questions@freebsd.org, hackers@freebsd.org Date: Mon, 21 Jul 1997 14:43:45 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any easy way to always prevent someone from pinging the broadcast addresses on my networks other than explicitly filtering them using ipfw ? Also, while on the topic of ipfw, does anyone know how much processor overhead ipfw adds to the system ? I suppose the more rules one adds the worse it gets. But does anyone have a reasonable guestimate ? Thanks, ---Mike From owner-freebsd-hackers Mon Jul 21 11:59:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03270 for hackers-outgoing; Mon, 21 Jul 1997 11:59:10 -0700 (PDT) Received: from tangelo.lal.ufl.edu (tangelo.lal.ufl.edu [204.199.163.200]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA03228; Mon, 21 Jul 1997 11:59:00 -0700 (PDT) Received: from Loche.lal.ufl.edu (204.199.163.38) by tangelo.lal.ufl.edu (EMWAC SMTPRS 0.81) with SMTP id ; Mon, 21 Jul 1997 14:58:52 -0400 Received: by localhost with Microsoft MAPI; Mon, 21 Jul 1997 15:07:31 -0400 Message-ID: <01BC95E7.CFDECB40.cll@icon.lal.ufl.edu> From: Christina Loche To: "'freebsd-bugs@freebsd.org'" , "'freebsd-chat@freebsd.org'" , "'freebsd-current@freebsd.org'" , "'hackers@freebsd.org'" Subject: unsubscribe Date: Mon, 21 Jul 1997 15:07:27 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk unsubscribe Christina Loche Cll@icon.lal.ufl.edu Ext. 220 From owner-freebsd-hackers Mon Jul 21 12:00:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA03511 for hackers-outgoing; Mon, 21 Jul 1997 12:00:48 -0700 (PDT) Received: from agni.nuko.com ([206.79.130.80]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA03494 for ; Mon, 21 Jul 1997 12:00:36 -0700 (PDT) Received: (from vinay@localhost) by agni.nuko.com (8.8.5/8.7.3) id LAA03148 for freebsd-hackers@freebsd.org; Mon, 21 Jul 1997 11:58:10 -0700 (PDT) From: Vinay Bannai Message-Id: <199707211858.LAA03148@agni.nuko.com> Subject: Kernel panic in driver probe() routine To: freebsd-hackers@freebsd.org Date: Mon, 21 Jul 1997 11:58:10 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey folks, Is it a bad thing to free up memory in the probe() routine for a pci driver in the event of something going wrong? It appears that whenever I do that the kernel panics saying page fault in kernel mode I have seen other probe() routines for other drivers do that. Thanks Vinay -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From owner-freebsd-hackers Mon Jul 21 12:30:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05314 for hackers-outgoing; Mon, 21 Jul 1997 12:30:09 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA05308 for ; Mon, 21 Jul 1997 12:30:06 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wqO9X-00023a-00; Mon, 21 Jul 1997 13:29:51 -0600 To: Michael Smith Subject: Re: Supermicro P6SNE manuals? Cc: rjk@sparcmill.grauel.com, hackers@freebsd.org In-reply-to: Your message of "Tue, 22 Jul 1997 00:20:34 +0930." <199707211450.AAA23903@genesis.atrad.adelaide.edu.au> References: <199707211450.AAA23903@genesis.atrad.adelaide.edu.au> Date: Mon, 21 Jul 1997 13:29:51 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707211450.AAA23903@genesis.atrad.adelaide.edu.au> Michael Smith writes: : Is this still on the SuperMicro board? I discovered that they do it : the "right" way, ie. a crimp D9 on one end of a ribbon cable and a : crimp IDC10 on the other "just works". The other pinout is an : abomination, and as someone who spends my fair share of time pushing : polygons laying out PCBs, I swear whoever came up with it SHOULD BE : SHOT! Yes. It is on the super micro board. That would indicate the pins are numbered 1-2-3-4-5 on the top row and 6-7-8-9-x on the bottom row. The signals on the ribbon cable would then be numbered 1-6-2-7-3-8-4-9-5-x. I'll pick up parts on the way home and try to make this cable... Warner From owner-freebsd-hackers Mon Jul 21 12:36:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05704 for hackers-outgoing; Mon, 21 Jul 1997 12:36:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA05699 for ; Mon, 21 Jul 1997 12:36:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA11689; Mon, 21 Jul 1997 12:29:08 -0700 From: Terry Lambert Message-Id: <199707211929.MAA11689@phaeton.artisoft.com> Subject: Re: sys/vfs.h To: abial@korin.warman.org.pl (Andrzej Bialecki) Date: Mon, 21 Jul 1997 12:29:08 -0700 (MST) Cc: frankd@yoda.fdt.net, terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Jul 21, 97 09:14:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > Do we have an equivalent file to this Linux file? I am trying to build > > > > XVFilemanager and mount.c has > > > > > > > > #include > > > > > > > > which causes the build to fall over. > > > > > > It depends on what it wants out of it. > > > > I will give it a try with these files substituted and see what happens. On > > closer inspection, it seems that this app was not written with portability > > beyond Linux in mind so I may not have much luck. > > You may try first to remove this include at all, and see what it complains > about (most notably "incomplete type" warnings), and then grep our source > tree for these definitions. Most likely, he will need to replace the mount command entirely; I assume that "mount.c" is the mount command. Look at the mount code under /usr/src/sbin for sample code showing how to push data across the mount system call. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 12:51:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07034 for hackers-outgoing; Mon, 21 Jul 1997 12:51:34 -0700 (PDT) Received: from tangelo.lal.ufl.edu (tangelo.lal.ufl.edu [204.199.163.200]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA06973; Mon, 21 Jul 1997 12:50:54 -0700 (PDT) Received: from Loche.lal.ufl.edu (204.199.163.38) by tangelo.lal.ufl.edu (EMWAC SMTPRS 0.81) with SMTP id ; Mon, 21 Jul 1997 15:50:52 -0400 Received: by localhost with Microsoft MAPI; Mon, 21 Jul 1997 15:59:33 -0400 Message-ID: <01BC95EF.147A1A00.cll@icon.lal.ufl.edu> From: Christina Loche To: "'Christina Loche'" , "'freebsd-bugs@freebsd.org'" , "'freebsd-chat@freebsd.org'" , "'freebsd-current@freebsd.org'" , "'hackers@freebsd.org'" Subject: RE: unsubscribe Date: Mon, 21 Jul 1997 15:59:28 -0400 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry all...I pushed the wrong address. Please disregard. Christina Loche Cll@icon.lal.ufl.edu Ext. 220 -----Original Message----- From: Christina Loche [SMTP:cll@ICON.LAL.UFL.EDU] Sent: Monday, July 21, 1997 3:07 PM To: 'freebsd-bugs@freebsd.org'; 'freebsd-chat@freebsd.org'; 'freebsd-current@freebsd.org'; 'hackers@freebsd.org' Subject: unsubscribe unsubscribe Christina Loche Cll@icon.lal.ufl.edu Ext. 220 From owner-freebsd-hackers Mon Jul 21 13:57:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11004 for hackers-outgoing; Mon, 21 Jul 1997 13:57:04 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10999 for ; Mon, 21 Jul 1997 13:57:00 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA01845 (5.67b/IDA-1.5 for ); Mon, 21 Jul 1997 22:56:49 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id WAA10859; Mon, 21 Jul 1997 22:56:33 +0200 (CEST) X-Face: " Date: Mon, 21 Jul 1997 22:56:33 +0200 From: Stefan Esser To: Terry Lambert Cc: Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? References: <19970718202558.63332@mi.uni-koeln.de> <199707202320.QAA09987@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707202320.QAA09987@phaeton.artisoft.com>; from Terry Lambert on Sun, Jul 20, 1997 at 04:20:36PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 20, Terry Lambert wrote: > > One of the changes to the PCI code, that might follow (I have > > not completely made up my mind) is, that the probe will just > > associate a driver with a list of vendor/device IDs, and there > > will no longer be a xxx_probe() function in the drivers. > > How does a PCI driver for, for instance, a DEC chip based ethernet > board find boards for which a vendor/driver assignment has not yet > been made? Well, if the device ID has not been assigned, then the chip most probably does not exist :) If you mean that the list of IDs available to the driver is incomplete: well how is that different from the current behaviour, where a list of device IDs is just compiled into the driver ? > Currently, the probe code will find the board, and it will just work. Hmmm ? I'm not sure I understand what you mean. I surely won't try to attach a board that does only match the vendor ID and the class code. This has been done by NCR in their early SDMS code, and they noticed it was wrong, when it caused boot failures on systems with new chips, that could not be driven by that version of the SCSI BIOS. > One big problem I can see this causing (though I admit it cures > one of my loudest complaints: destructive probing) is that the > vendor/device/driver association list could quicly get too large > to fit on the same floppy as the BSD kernel. 8-(. Hmmm ? The list could for example contain one vendor ID and possibly multiple device IDs on a line starting with the driver name. This is some 10 bytes per unique ID, and well, if you want to support some 100 PCI IDs, may add up to 1KB of highly compressible data :) Regards, STefan From owner-freebsd-hackers Mon Jul 21 14:03:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11342 for hackers-outgoing; Mon, 21 Jul 1997 14:03:20 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11336 for ; Mon, 21 Jul 1997 14:03:15 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA02394 (5.67b/IDA-1.5 for ); Mon, 21 Jul 1997 23:03:13 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id XAA10899; Mon, 21 Jul 1997 23:03:08 +0200 (CEST) X-Face: " Date: Mon, 21 Jul 1997 23:03:08 +0200 From: Stefan Esser To: Vinay Bannai Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel panic in driver probe() routine References: <199707211858.LAA03148@agni.nuko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707211858.LAA03148@agni.nuko.com>; from Vinay Bannai on Mon, Jul 21, 1997 at 11:58:10AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 21, Vinay Bannai wrote: > Hey folks, > > Is it a bad thing to free up memory in the probe() routine for a pci > driver in the event of something going wrong? > > It appears that whenever I do that the kernel panics saying > page fault in kernel mode Could you send me your probe code ? Most probably, there is something else going wrong ... > I have seen other probe() routines for other drivers do that. Yes, it should not cause any problems. Regards, STefan From owner-freebsd-hackers Mon Jul 21 14:04:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11435 for hackers-outgoing; Mon, 21 Jul 1997 14:04:52 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11429 for ; Mon, 21 Jul 1997 14:04:47 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA02227 (5.67b/IDA-1.5 for ); Mon, 21 Jul 1997 23:01:19 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id XAA10884; Mon, 21 Jul 1997 23:01:14 +0200 (CEST) X-Face: " Date: Mon, 21 Jul 1997 23:01:13 +0200 From: Stefan Esser To: Michael Smith Cc: Terry Lambert , Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? References: <199707202320.QAA09987@phaeton.artisoft.com> <199707210113.KAA19725@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707210113.KAA19725@genesis.atrad.adelaide.edu.au>; from Michael Smith on Mon, Jul 21, 1997 at 10:43:58AM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 21, Michael Smith wrote: > Terry Lambert stands accused of saying: > > How does a PCI driver for, for instance, a DEC chip based ethernet > > board find boards for which a vendor/driver assignment has not yet > > been made? > > The same way it does now. Right! > You should read the probe code I think. To save your fingers the effort, > here it is : > > static char* > tulip_pci_probe( > pcici_t config_id, > pcidi_t device_id) > { > if (PCI_VENDORID(device_id) != DEC_VENDORID) > return NULL; > if (PCI_CHIPID(device_id) == CHIPID_21040) > return "Digital 21040 Ethernet"; > Now, if we remove this information from the driver and put it > somewhere in a Big Central Localtion, like, oh say W95 does (seeing as > you respect their design decisions), the central localtion can be > updated rapidly without having to rebuild and reinstall the driver. That's my goal, indeed :) > > One big problem I can see this causing (though I admit it cures > > one of my loudest complaints: destructive probing) is that the > > vendor/device/driver association list could quicly get too large > > to fit on the same floppy as the BSD kernel. 8-(. > > You split it into two parts; the ones needed to boot with, and a > second set for "frivolous" devices. 8) Well, and you forgot the third case: You can add the information in the user configuration step. If there is a device ID that is not (yet) in the kernel, you can ask for it, and will just have to supply an eight digit hex number and the driver name (typically three characters) to assign the device. In visual config you might even be able to just select one device with an unknown ID, and then choose the driver to assign from a menu of compiled in PCI drivers :) Regards, STefan From owner-freebsd-hackers Mon Jul 21 14:07:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11571 for hackers-outgoing; Mon, 21 Jul 1997 14:07:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11559; Mon, 21 Jul 1997 14:07:25 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11882; Mon, 21 Jul 1997 14:04:10 -0700 From: Terry Lambert Message-Id: <199707212104.OAA11882@phaeton.artisoft.com> Subject: Re: pcireg.h lost children... ? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 14:04:10 -0700 (MST) Cc: terry@lambert.org, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707210113.KAA19725@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 10:43:58 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Now, if we remove this information from the driver and put it > somewhere in a Big Central Localtion, like, oh say W95 does (seeing as > you respect their design decisions), the central localtion can be > updated rapidly without having to rebuild and reinstall the driver. I don't exactly respect their design decisions; it's just that, given a choice between some of the BSD design decisions and the Win95 design decisions, I'd pick the Win95 where ever they've made tradeoffs in favor of ease of use and BSD hasn't. > Nifty, eh? Yes, if it's only a trade of location and not one of size, then abstraction is the correct apporach, when possible. > > One big problem I can see this causing (though I admit it cures > > one of my loudest complaints: destructive probing) is that the > > vendor/device/driver association list could quicly get too large > > to fit on the same floppy as the BSD kernel. 8-(. > > You split it into two parts; the ones needed to boot with, and a > second set for "frivolous" devices. 8) I was actually looking at the draft proposal for the LDAP MIB for POSIX systems, the other day. It seems to me that a locally maintained LDAP breanch accessed through a local library that could go remote if the information wasn't there, and wasn't able to try to go remote until the network services were actually up, is the correct future direction for UNIX password files, etc.. And probably this information, as well. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 14:10:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11774 for hackers-outgoing; Mon, 21 Jul 1997 14:10:48 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11769 for ; Mon, 21 Jul 1997 14:10:45 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11898; Mon, 21 Jul 1997 14:06:45 -0700 From: Terry Lambert Message-Id: <199707212106.OAA11898@phaeton.artisoft.com> Subject: Re: sendmail complains about being unable to write his pid file To: sthaug@nethelp.no Date: Mon, 21 Jul 1997 14:06:45 -0700 (MST) Cc: terry@lambert.org, andreas@klemm.gtn.com, hackers@FreeBSD.ORG In-Reply-To: <24270.869443683@verdi.nethelp.no> from "sthaug@nethelp.no" at Jul 21, 97 02:08:03 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Certainly - for a corresponding decrease in security. I'd like to have > the tighter security be the default. Or at least have it as an option > when installing. OK, I don't understand why you believe that something being owned by root, an account with password access, the password for which is succeptible to being cracked, is somehow more secure than ownership by bin, an account without password access and therefore *not* succeptible to being cracked. Can you please explain how root ownership makes something more secure? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 14:13:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11923 for hackers-outgoing; Mon, 21 Jul 1997 14:13:42 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA11914 for ; Mon, 21 Jul 1997 14:13:36 -0700 (PDT) Received: (qmail 18230 invoked by uid 1000); 21 Jul 1997 21:13:48 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970718202558.63332@mi.uni-koeln.de> XF-OrgMsg: inbox 16 869284513 Date: Mon, 21 Jul 1997 11:06:22 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Stefan Esser Subject: Re: pcireg.h lost children... ? Cc: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Stefan Esser; On 18-Jul-97 you wrote: > On Jul 17, Simon Shapiro wrote: > [ ... new macro names for PCI classes and config register bits ... ] > > It did, for a while, break compatability... > > Well, I'm sorry for that. > But I did not expect drivers to actually use those names ... Normal, routine, to be expected... :-) > And you were warned: I left no doubt in my commit messages, > that the new PCI code was a independent implementation :) Ah... ... > Hmmm, why don't you probe for known vendor and device IDs ? I do. This is sort of sanity check. We se stray PCI cards that pretend to be what they are not (especially in prototypes). It may be unnecessary paranoia... > One of the changes to the PCI code, that might follow (I have > not completely made up my mind) is, that the probe will just > associate a driver with a list of vendor/device IDs, and there > will no longer be a xxx_probe() function in the drivers. Hmmm... On this note, the DPT driver gets called with some Intel PCi devices on the motherboard that have no driver. If you enable the DPT_DEBUG_PCI option you see those. > One reason is that I want to be able to assign drivers to IDs > (chip or cards IDs) without recompilation. Sounds good. Will you not have to have a ``finite'' list of ``all'' the drivers? ... > The old approach caused trouble to people with NCR SCSI cards > based on new chips, which came with their own 4.xx BIOS, but > had the (inappropriate) 3.xx BIOS trying to initialize them. The DPT cards all report the same device ID. They are all compatible with each other. So it is even more sensible to remove this excessive testing. > > > command = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); > > if ( (command & PCI_COMMAND_MASTER_ENABLE) == 0 ) { > > printf("DPT: BUSMASTER disabled :-(\n"); > > return (NULL); > > } > > I've never heard of a PCI BIOS, that failed to enable the > bus-master functionality, but did set up the chip correctly, > else. I really can't imagine a system that would trigger > this condition! Certain motherboards do not provide bus mastering on every slot. ... > The other driver's don't test for the enable bits, and > just rely on the error indication returned by the call > to pci_map_XXX(). It is doable. Am I violating the protocol by testing? Or is it just a waste? I had hard time when not ``getting'' first. Got garbage back. Maybe it is working now... > You should not check those values from within any driver, > IMHO, but instead just try to map the regions you need, > and perform an error exit if mandatory mappings failed. OK. We will try... > BTW: There appears to be a buglet in your code: Every > base address register may only hold either a memory or > a port address, and the address type is hard-wired into > the chip! Possible. This is still experimental. The DPT is supposed to be able to EITHER memory or I/O map the same registers. > This means, that the use of base addr reg 0 for both the > call to pci_map_mem() and pci_map_port() must be wrong. > (I assume the letter is never tried, since the prior > always succeeds.) Actually, both succeed, if you arrange the code correctly. The problem i am having is that memory mapping succeeds but nothing talks. I think I am after the wrong regions. Still under investigation. > The PCI BIOS needs the type bits (low order bits of the > address base registers) to be R/O in order to assign valid > addresses. If both memory and port accesses are supported, > then one register will have the two low order bits wired > to 01, and another one will have low order 4 bits of 0000 > (or less likely some other even number). > > The PCI BIOS uses the low order bits to decide whether > some currently unused port or memory region is reserved > for that chip, and then puts the base into the register. > > You know from the data sheet, which register will hold > a port and which one will hold a memory address, if they > can be assigned. > > BTW: Your test of the memory and port enable bits is not > sufficient, if the devices are behind a PCI to PCI bridge, > as Justin Gibbs pointed out to me. (And I'll modify the > PCI code to correctly return an error indication to the > pci_map_xxx() call, in such a case.) I am learning about the nasty side of PCI-PCI bridges every day... Thanx for the help. Simon From owner-freebsd-hackers Mon Jul 21 14:48:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13734 for hackers-outgoing; Mon, 21 Jul 1997 14:48:27 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA13729 for ; Mon, 21 Jul 1997 14:48:24 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wqQHZ-0002PY-00; Mon, 21 Jul 1997 15:46:17 -0600 To: Terry Lambert Subject: Re: sendmail complains about being unable to write his pid file Cc: sthaug@nethelp.no, andreas@klemm.gtn.com, hackers@freebsd.org In-reply-to: Your message of "Mon, 21 Jul 1997 14:06:45 PDT." <199707212106.OAA11898@phaeton.artisoft.com> References: <199707212106.OAA11898@phaeton.artisoft.com> Date: Mon, 21 Jul 1997 15:46:17 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199707212106.OAA11898@phaeton.artisoft.com> Terry Lambert writes: : Can you please explain how root ownership makes something more secure? Files owned by root are harder to change via NFS than files owned by bin. root access n NFS is generally blocked, but no so with other, non-zero uids. Warner From owner-freebsd-hackers Mon Jul 21 14:52:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14041 for hackers-outgoing; Mon, 21 Jul 1997 14:52:34 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA14029 for ; Mon, 21 Jul 1997 14:52:30 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-44.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA06676 (5.67b/IDA-1.5 for ); Mon, 21 Jul 1997 23:52:25 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id XAA11093; Mon, 21 Jul 1997 23:52:20 +0200 (CEST) X-Face: " Date: Mon, 21 Jul 1997 23:52:20 +0200 From: Stefan Esser To: Simon Shapiro Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? References: <19970718202558.63332@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Simon Shapiro on Mon, Jul 21, 1997 at 11:06:22AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 21, Simon Shapiro wrote: > > Hmmm, why don't you probe for known vendor and device IDs ? > > I do. This is sort of sanity check. We se stray PCI cards that > pretend to be what they are not (especially in prototypes). > It may be unnecessary paranoia... You are of course free to be as paranoid as you want to be :) I've been accused of that too, on some occasions ... > > One of the changes to the PCI code, that might follow (I have > > not completely made up my mind) is, that the probe will just > > associate a driver with a list of vendor/device IDs, and there > > will no longer be a xxx_probe() function in the drivers. > > Hmmm... On this note, the DPT driver gets called with some Intel > PCi devices on the motherboard that have no driver. If you enable > the DPT_DEBUG_PCI option you see those. Hmmm ? Sorry, I don't really understand what this means ... The probe code of each driver will be called, until there is one that claims to know the device with the given vendor and device ID. There is no need for a chip-set driver, since the chip-set better is completely configured before the system even considers loading the primary boot sector. I could suppress the "no driver" message for host bridges and other chip-set components, and probably will do so some time in the future, based on the class code. (In fact, there will be a dummy default driver for the classes, which will only be used, if no subdevice match (prefered) or chip ID match (second) occured.) Other than codes to the DPT's probe code (which should just ignore devices that have unknown vendor/device IDs), there should be no calls to the DPT driver from the PCI code. > > One reason is that I want to be able to assign drivers to IDs > > (chip or cards IDs) without recompilation. > > Sounds good. Will you not have to have a ``finite'' list of ``all'' > the drivers? Well, in the end, we will. In the same sense as you could build a complete list of Q-Bus or S-100 cards, today :) Honestly: There are so many PCI chips that have gone through several generations, and each one needed more IDs to be added to the driver, but not much more code changes to just get it to work. (Specific optimizations can wait ...) > > The old approach caused trouble to people with NCR SCSI cards > > based on new chips, which came with their own 4.xx BIOS, but > > had the (inappropriate) 3.xx BIOS trying to initialize them. > > The DPT cards all report the same device ID. They are all compatible > with each other. So it is even more sensible to remove this excessive > testing. How do you distinguish the different card versions, then ? The device unique configuration space registers starting at 0x40 are a good place to put such information. Is this what DPT does ? > > > command = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); > > > if ( (command & PCI_COMMAND_MASTER_ENABLE) == 0 ) { > > > printf("DPT: BUSMASTER disabled :-(\n"); > > > return (NULL); > > > } > > > > I've never heard of a PCI BIOS, that failed to enable the > > bus-master functionality, but did set up the chip correctly, > > else. I really can't imagine a system that would trigger > > this condition! > > Certain motherboards do not provide bus mastering on every slot. Yes, true. Well, I'm wondering whether I should put a flag into the pci_device struct that signals required features to the PCI bus code, and one bit would indicate "this is a bus-master card". Or I could provide a function that can be called from the driver attach code, and which would perform those tests, with no need for the driver to know about the PCI command register and its bits. (E.g. pci_check(tag, REQ_BUS_MASTER | REQ_MAP0 | REQ_MAP1) which would signal success only if all the conditions are simultanously fulfilled, and if for each map type the appropriate access enable bit in the command register is set. E.g. if map 0 was a memory map and map 1 ports, then the above call would find this information in the map registers, and it would check the enable bus-master bit and the enable memory and enable I/O bit of the device and all PCI to PCI bridges on the way to the CPU ...) > > The other driver's don't test for the enable bits, and > > just rely on the error indication returned by the call > > to pci_map_XXX(). > > It is doable. Am I violating the protocol by testing? > Or is it just a waste? I had hard time when not ``getting'' > first. Got garbage back. Maybe it is working now... Well, it definitely should work to just call the map functions, and to try the alternate base register, if the first one could not be mapped. If you have trouble with this approach, then I'll have to fix the PCI code. > > BTW: There appears to be a buglet in your code: Every > > base address register may only hold either a memory or > > a port address, and the address type is hard-wired into > > the chip! > > Possible. This is still experimental. The DPT is supposed to > be able to EITHER memory or I/O map the same registers. This is true for quite a number of devices (e.g. the NCR and Adpatec SCSI chips or the DEC Ethernet chips). The port map should only be used from real-mode x86 code (DOS), which has no easy access to high memory ... > > This means, that the use of base addr reg 0 for both the > > call to pci_map_mem() and pci_map_port() must be wrong. > > (I assume the letter is never tried, since the prior ^a (ahemm :) > > always succeeds.) > > Actually, both succeed, if you arrange the code correctly. Yes, they should, and a mapping that is not actually used by the driver should not cause any harm. (The call to pci_map_port is mostly a nop, if there are no conflicts, while pci_map_mem creates a VM). > The problem i am having is that memory mapping succeeds but > nothing talks. I think I am after the wrong regions. Hmmm, not knowing anything about the device, I can't offer any advice ... Regards, STefan From owner-freebsd-hackers Mon Jul 21 15:14:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15369 for hackers-outgoing; Mon, 21 Jul 1997 15:14:28 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15362 for ; Mon, 21 Jul 1997 15:14:22 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA02162; Mon, 21 Jul 1997 16:14:15 -0600 (MDT) Date: Mon, 21 Jul 1997 16:14:15 -0600 (MDT) Message-Id: <199707212214.QAA02162@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: Terry Lambert , sthaug@nethelp.no, andreas@klemm.gtn.com, hackers@freebsd.org Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: References: <199707212106.OAA11898@phaeton.artisoft.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh writes: > In message <199707212106.OAA11898@phaeton.artisoft.com> Terry Lambert writes: > : Can you please explain how root ownership makes something more secure? > > > Files owned by root are harder to change via NFS.... Ahh, you said the dirty word, NFS. NFS stands for 'No Freaking Security', so if you're using NFS, you've already given up any chance of security. Making a bunch of changes to make the NFS folks happy seems silliness, given that for 'secure' sites it won't buy anything and only require lots of un-necessary changes to the system. Nate From owner-freebsd-hackers Mon Jul 21 15:23:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15995 for hackers-outgoing; Mon, 21 Jul 1997 15:23:26 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15985 for ; Mon, 21 Jul 1997 15:23:17 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id PAA06518; Mon, 21 Jul 1997 15:19:33 -0700 (PDT) Date: Mon, 21 Jul 1997 15:19:33 -0700 (PDT) From: Jaye Mathisen To: Terry Lambert cc: sthaug@nethelp.no, andreas@klemm.gtn.com, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: <199707212106.OAA11898@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, just to throw in my 2 bits, I don't really care who owns it, because if root is compromised, who gives a flying leap about files being bin.bin, your system is still open. So it seems then that the only issue would be if an application ran as bin, and needed access to files owned by bin. Which doesn't appear to be the case here. So I guess I would want to know why bin.bin makes them more secure, rather than just leaving it with root ownership... Seems like bin implies a false sense of security. But I could be misunderstanding the whole argument, and will retreat back into my hole. On Mon, 21 Jul 1997, Terry Lambert wrote: > > Certainly - for a corresponding decrease in security. I'd like to have > > the tighter security be the default. Or at least have it as an option > > when installing. > > OK, I don't understand why you believe that something being owned by > root, an account with password access, the password for which is > succeptible to being cracked, is somehow more secure than ownership > by bin, an account without password access and therefore *not* > succeptible to being cracked. > > Can you please explain how root ownership makes something more secure? > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > From owner-freebsd-hackers Mon Jul 21 15:23:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA16038 for hackers-outgoing; Mon, 21 Jul 1997 15:23:45 -0700 (PDT) Received: from agni.nuko.com ([206.79.130.80]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA16010; Mon, 21 Jul 1997 15:23:35 -0700 (PDT) Received: (from vinay@localhost) by agni.nuko.com (8.8.5/8.7.3) id PAA03602; Mon, 21 Jul 1997 15:21:06 -0700 (PDT) From: Vinay Bannai Message-Id: <199707212221.PAA03602@agni.nuko.com> Subject: Re: Kernel panic in driver probe() routine To: se@freebsd.org (Stefan Esser) Date: Mon, 21 Jul 1997 15:21:06 -0700 (PDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <19970722000635.41795@mi.uni-koeln.de> from "Stefan Esser" at "Jul 22, 97 00:06:35 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Stefan Esser: > On Jul 21, Vinay Bannai wrote: > > Actually it was in my attach() routine. Here it is: > > I am freeing up my memory towards the end under the label fail > > Ahhh, yes, I see ... > > But you are freeing memory not obtained through a call to > malloc(), and that is generally considered a bad thing :) > > > if (!pci_map_mem(config_id, CYCLONE_PCI_MMRR_REG, > > (vm_offset_t *)&vaddr, (vm_offset_t *)&paddr)) { > > printf("cyclone%d: couldn't map memory\n", unit); > > goto fail; > > > fail: > > if (vaddr) > > free((void *)vaddr, M_DEVBUF); > > Here vmaddr did not point to a memory region allocated by > malloc, but to one that got a virtual to physical mapping > established by a call to pmap_mapdev (/sys/i386/i386/pmap.c). STefan, You are correct. I just looked at the code for pmap.c and it in turn calls kern_alloc_pageable(). I don't exaclty understand all the stuff about maps and submaps, but seems like the virtual memory is not coming from the place where malloc() gets it!! > You may want to ask David Greenman about how to release > such a mapping. I didn't bother, since the page table entry > created for the device consumes only 4 bytes per 4KB page > you allocated, and the code to free the page table entries > is likely to be much larger, except for large regions ... > > Regards, STefan Yup. I will just ignore it for the time being and bother DG later on when I start running into DMA problems. :-) The PCI device that I am interfacing is capable of doing lot more things (since it has got a i960 processor wiht 4M of RAM). But initially I want to test by passing back and forth to the card some packets of fixed size. Are there any guidelines as to how much memory I should allocate for the Rx and Tx buffers? I am bad at picking numbers :-) Vinay -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From owner-freebsd-hackers Mon Jul 21 16:00:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA18203 for hackers-outgoing; Mon, 21 Jul 1997 16:00:18 -0700 (PDT) Received: from bitbox.follo.net (eivind@bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA18136; Mon, 21 Jul 1997 15:59:59 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.5/8.7.3) id AAA13640; Tue, 22 Jul 1997 00:59:29 +0200 (CEST) Date: Tue, 22 Jul 1997 00:59:29 +0200 (CEST) Message-Id: <199707212259.AAA13640@bitbox.follo.net> From: Eivind Eklund To: hcremean@vt.edu CC: brian@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Lee Cremeans's message of Sun, 13 Jul 1997 23:29:00 -0400 Subject: Re: PPP -alias and DCC RESUME References: <19970713232900.32111@wakky.dyn.ml.org> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I noticed something tonight: The alias_irc.c in ppp-970620 and 970629 doesn't > seem to handle DCC RESUME (a mIRCism that's supported by the EPIC versions > of ircII) correctly. When I turn off aliasing, things work, but from the > looks of the code in alias_irc.c, it should be working even with aliasing > ON. Does DCC SEND work for you with aliasing enabled? If it does, then "DCC RESUME" likely break the common format for DCC commands. I can probably modify the alias_irc.c code to handle 'DCC RESUME' as a special case, but I would need some form of specs for it; at least a trace of an IRC session where it is used (raw form). You can get hold of me as 'EE' on IRCnet if you have access to the client; I no longer have the facilities to easily test aliased connections (though I might set it up again later). Eivind. From owner-freebsd-hackers Mon Jul 21 16:20:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA19285 for hackers-outgoing; Mon, 21 Jul 1997 16:20:06 -0700 (PDT) Received: from noc.msc.edu (noc.msc.edu [137.66.12.254]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA19241 for ; Mon, 21 Jul 1997 16:19:58 -0700 (PDT) Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA15043; Mon, 21 Jul 97 18:19:49 -0500 From: jpt@msc.edu (Joseph Thomas) Received: (jpt@localhost) by uh.msc.edu (8.7.1/8.6.6) id SAA06830 for freebsd-hackers@FreeBSD.ORG; Mon, 21 Jul 1997 18:19:50 -0500 (CDT) Message-Id: <199707212319.SAA06830@uh.msc.edu> Subject: Cloned devices??? To: freebsd-hackers@FreeBSD.ORG Date: Mon, 21 Jul 1997 18:19:49 -0500 (CDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm looking for a way to do what the 'clone' device in SunOS/streams allows the driver to do. Any pointers/ideas? (Okay - let's see if I can explain this and make it understandable.) Basically, I have an application which would like to have several unique opens to a device without the application having to poll minor numbers. With the clone device, an open call to a known major/minor will cause the xxx_open() routine to find an unused minor device and return makedev(major,unique minor). A couple of advantages of this include a) user always opens one device, b) you don't clutter up your /dev directory with every possible major/minor pair. Example: /dev has node clone, major M, minor 0. application does: for ( i = 0; i < 3; i++ ) fd[i] = open ( "/dev/clone", O_RDWR ); where fd[0] would actually point to a device with major M, minor 1, fd[1] would point to major M, minor 2, and fd[2] would point to major M, minor 3. what I'd like to avoid is: /dev/clone00 major M, minor 0 /dev/clone01 major M, minor 1 /dev/clone02 major M, minor 2 /dev/clone03 major M, minor 3 . . . /dev/cloneNN major M, minor NN and application: for ( i = 0; i < 3; i++ ) for ( j = 0; j < NN; j++ ) { sprintf ( name, "/dev/clone%2d", j ); if ( ( fd[i] = open ( name, O_RDWR ) ) > 0 ) break; } Does this make sense? -- Joseph Thomas E/Mail: jpt@msc.edu Minnesota Supercomputer Center, Inc. jpt@magic.net 1200 Washington Ave So. Tel: +1 612 337 3558 Minneapolis, MN 55415-1227 FAX: +1 612 337 3400 An elephant is a mouse with an operating system. From owner-freebsd-hackers Mon Jul 21 16:46:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA20518 for hackers-outgoing; Mon, 21 Jul 1997 16:46:17 -0700 (PDT) Received: from wakky.dyn.ml.org (lee@1Cust99.Max6.Washington2.DC.MS.UU.NET [153.34.2.227]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA20506; Mon, 21 Jul 1997 16:45:59 -0700 (PDT) Received: (from lee@localhost) by wakky.dyn.ml.org (8.8.5/8.8.3) id TAA03126; Mon, 21 Jul 1997 19:45:07 -0400 (EDT) Message-ID: <19970721194506.34177@wakky.dyn.ml.org> Date: Mon, 21 Jul 1997 19:45:06 -0400 From: Lee Cremeans To: Eivind Eklund Cc: brian@freebsd.org, hackers@freebsd.org Subject: Re: PPP -alias and DCC RESUME References: <19970713232900.32111@wakky.dyn.ml.org> <199707212259.AAA13640@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.66e Reply-to: hcremean@vt.edu X-OS: FreeBSD 2.2-RELEASE X-Evil: microsoft.com Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Jul 22, 1997 at 12:59:29AM +0200, Eivind Eklund wrote: > > Does DCC SEND work for you with aliasing enabled? If it does, then > "DCC RESUME" likely break the common format for DCC commands. I can > probably modify the alias_irc.c code to handle 'DCC RESUME' as a > special case, but I would need some form of specs for it; at least a > trace of an IRC session where it is used (raw form). You can get hold > of me as 'EE' on IRCnet if you have access to the client; I no longer > have the facilities to easily test aliased connections (though I might > set it up again later). Yes, DCC SEND works fine. I have the spec here for DCC RESUME; it's attached below. ---cut here--- DCC Resume. The DCC Resume protocol is an extention to the standard DCC protocol as described in http://www2.undernet.org:8080/~cs93jtl/irc_dcc.txt It is ment to overcome the bad experiences people on slow modem connections have with DCC File transfers. Since more and more people access IRC by Slip and PPP modem connections, more and more people are affected by stopped transfers, sometimes after a looong period of downloading and hoping for a long transfer to complete correctly. The DCC Resume offers you the option to simply restart a transfer at the point it was broken off and to proceed without loss of expensive (?) connection time. The DCC Resume allows you to resume DCC transfers that failed to complete. This will only work with mIRC and compatible clients. If a user tries to send you a file that already (eventually partly) exists in your get directory then you will be shown a DCC Get dialog warning that the file exists. The dialog gives you the option to either overwrite the older file, resume a transfer, or rename the incoming file . If you select overwrite then the whole file will be downloaded from the beginning and any existing file of the same name will be erased. If you select resume then mIRC will attempt to negotiate a transfer resume to get the remaining part of the file. It will append this to the portio n of the file you already have. The negotiation method is specific to mIRC and to other clients supporting the protocol. It is not standard and will not work with other DCC implementations that do not have resume capability. The negotiation is automatic, and once the receiving user clicks the resume button, the transfer will commence as normal. If the other party does not support the DCC Resume protocol the transfer will simply not start. In those cases you have to start a complete new transfer from the very beginning. The DCC Resume standard is set by mIRC and several other IRC clients support DCC Resume already : mIRC http://www.mirc.co.uk/index.html PIRCH http://www.bcpl.lib.md.us/~frappa/pirch.html Visual IRC (ViRC) http://apollo3.com/~acable/virc.html IaIRC (InterAp IRC) http://merlin.datlin.ee/HamGroup/yury/iairc.htm ---- Here is a description of the mIRC DCC Resume Protocol. User1 is sending the file. User2 is receiving the file. To initiate a DCC Send, User1 sends: PRIVMSG User2 :DCC SEND filename ipaddress port filesize Normally, if User2 accepts the DCC Send request, User2 connects to the address and port number given by User1 and the file transfer begins. If User2 chooses to resume a file transfer of an existing file, the following negotiation takes place: User2 sends: PRIVMSG User1 :DCC RESUME filename port position filename = the filename sent by User1. port = the port number sent by User1. position = the current size of the file that User2 has. User1 then responds: PRIVMSG User2 :DCC ACCEPT filename port position This is simply replying with the same information that User2 sent as acknowledgement. At this point User2 connects to User1 address and port and the transfer begins from the specified position. NOTE: the newer versions of mIRC actually ignore the filename as it is redundant since the port uniquely identifies the connection. However, to remain compatible mIRC still sends a filename as "file.ext" in both RESUME and ACCEPT. ---- Tjerk Vonck mirc@dds.nl -- Lee C. -- Manassas, VA, USA (WakkyMouse on DALnet #watertower)|A! JW223 "People are idiots who deserve to be mocked."--Dogbert|YWD+++i P&B+++ SL+++^i My home page:http://wakky.dyn.ml.org/~lee | MD+++r P+ I++ Di "Whoa, dumber than advertised!" | $++ E5/10/70/3c/73ac Ee34/1/36 H2 PonPippi From owner-freebsd-hackers Mon Jul 21 17:21:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22200 for hackers-outgoing; Mon, 21 Jul 1997 17:21:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA22195 for ; Mon, 21 Jul 1997 17:21:39 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA12149; Mon, 21 Jul 1997 17:18:27 -0700 From: Terry Lambert Message-Id: <199707220018.RAA12149@phaeton.artisoft.com> Subject: Re: Compressed FS To: abial@korin.warman.org.pl (Andrzej Bialecki) Date: Mon, 21 Jul 1997 17:18:27 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Jul 21, 97 12:07:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm reading the Heidemann's thesis right now (on stackable FS design). He > mentions that among others they implemented a compression layer. Did > anyone do something similar under FreeBSD? It would be cool to have it, > IMHO. John has sent the compression code (and some cryptographic code) layers to severa people, including myself, with the request that we not redistribute the code without prior permission. The BSD layering is such that the VM issues are, in some cases, hard to overcome (which is why union FS's currently don't work in the main line tree). Any compression (or cryptographic) FS would face similar problems, since it would need to maintain seperate cache data for the uncompressed (or deencrypted) file blocks. Actually, you should check with John: he was working on the union FS code to make it work with the new VM. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 17:28:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22512 for hackers-outgoing; Mon, 21 Jul 1997 17:28:24 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA22501 for ; Mon, 21 Jul 1997 17:28:14 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id JAA25630; Tue, 22 Jul 1997 09:58:00 +0930 (CST) From: Michael Smith Message-Id: <199707220028.JAA25630@genesis.atrad.adelaide.edu.au> Subject: Re: Supermicro P6SNE manuals? In-Reply-To: from Warner Losh at "Jul 21, 97 01:29:51 pm" To: imp@rover.village.org (Warner Losh) Date: Tue, 22 Jul 1997 09:57:58 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, rjk@sparcmill.grauel.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > In message <199707211450.AAA23903@genesis.atrad.adelaide.edu.au> Michael Smith writes: > : Is this still on the SuperMicro board? I discovered that they do it > : the "right" way, ie. a crimp D9 on one end of a ribbon cable and a > : crimp IDC10 on the other "just works". The other pinout is an > : abomination, and as someone who spends my fair share of time pushing > : polygons laying out PCBs, I swear whoever came up with it SHOULD BE > : SHOT! > > Yes. It is on the super micro board. That would indicate the pins > are numbered 1-2-3-4-5 on the top row and 6-7-8-9-x on the bottom > row. The signals on the ribbon cable would then be numbered > 1-6-2-7-3-8-4-9-5-x. I'll pick up parts on the way home and try to > make this cable... It would? I was actually fairly sure that it was the other way 'round, in that the 12345/678910 layout made me feel ill, and I remember feeling less ill when it worked. I could, of course, be offset by the fact that it worked. 8) > Warner -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 17:28:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22533 for hackers-outgoing; Mon, 21 Jul 1997 17:28:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA22527 for ; Mon, 21 Jul 1997 17:28:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA12174; Mon, 21 Jul 1997 17:23:14 -0700 From: Terry Lambert Message-Id: <199707220023.RAA12174@phaeton.artisoft.com> Subject: Re: sendmail complains about being unable to write his pid file To: imp@rover.village.org (Warner Losh) Date: Mon, 21 Jul 1997 17:23:14 -0700 (MST) Cc: terry@lambert.org, sthaug@nethelp.no, andreas@klemm.gtn.com, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Jul 21, 97 03:46:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : Can you please explain how root ownership makes something more secure? > > Files owned by root are harder to change via NFS than files owned by > bin. root access n NFS is generally blocked, but no so with other, > non-zero uids. This only argues for read-only export of / and /user FS's, as far as I can see, and not for root rather than bin ownership of files or directories themselves. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 17:29:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA22602 for hackers-outgoing; Mon, 21 Jul 1997 17:29:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA22596 for ; Mon, 21 Jul 1997 17:29:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA12189; Mon, 21 Jul 1997 17:27:25 -0700 From: Terry Lambert Message-Id: <199707220027.RAA12189@phaeton.artisoft.com> Subject: Re: Cloned devices??? To: jpt@msc.edu (Joseph Thomas) Date: Mon, 21 Jul 1997 17:27:25 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707212319.SAA06830@uh.msc.edu> from "Joseph Thomas" at Jul 21, 97 06:19:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm looking for a way to do what the 'clone' device in > SunOS/streams allows the driver to do. Any pointers/ideas? This should be easy under devfs. A static (non-devfs) version would be pretty easy as well, but much less general. [ ... ] > /dev has node clone, major M, minor 0. > > application does: > > for ( i = 0; i < 3; i++ ) > fd[i] = open ( "/dev/clone", O_RDWR ); > > where fd[0] would actually point to a device with major M, minor 1, > fd[1] would point to major M, minor 2, > and fd[2] would point to major M, minor 3. > > > what I'd like to avoid is: > > /dev/clone00 major M, minor 0 > /dev/clone01 major M, minor 1 Why? There's really no good reason to not expose the device in the name space; for pty's, you would *definititely* want to expose the slave side in the namespace! The devfs version would not expose the slave until the master had been created via cloning, but the static would want to always export the slave. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Mon Jul 21 17:41:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23305 for hackers-outgoing; Mon, 21 Jul 1997 17:41:36 -0700 (PDT) Received: from athena.veritas.com (athena.veritas.com [192.203.46.191]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA23280 for ; Mon, 21 Jul 1997 17:41:22 -0700 (PDT) Received: from megami.veritas.com by athena.veritas.com with smtp (Smail3.1.29.0 #9) id m0wqT0t-000iJyC; Mon, 21 Jul 97 17:41 PDT Received: from sigma by megami.veritas.com with smtp (Smail3.1.29.0 #7) id m0wqT0t-000iabC; Mon, 21 Jul 97 17:41 PDT Message-Id: From: Aaron Smith To: hackers@freebsd.org Subject: pstat -T broken? Date: Mon, 21 Jul 1997 17:41:13 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk i synced (with current) and made world today, and happened to notice that 'pstat -T' fails and complains about KERN_VNODE being undefined. anyone else have this problem, or is it something with my config? aaron From owner-freebsd-hackers Mon Jul 21 17:58:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23917 for hackers-outgoing; Mon, 21 Jul 1997 17:58:06 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23894; Mon, 21 Jul 1997 17:57:50 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id KAA19390; Tue, 22 Jul 1997 10:57:03 +1000 (EST) Date: Tue, 22 Jul 1997 10:57:02 +1000 (EST) From: "Daniel O'Callaghan" To: Mike D Tancsa cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: preventing ICMP echo requests to the broadcast address In-Reply-To: <199707211843.OAA29815@granite.sentex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 21 Jul 1997, Mike D Tancsa wrote: > > Is there any easy way to always prevent someone from pinging the > broadcast addresses on my networks other than explicitly filtering > them using ipfw ? In /etc/rc.firewall, after the allow all from 127.0.0.1 to 127.0.0.1 rule add a rule '/sbin/ipfw add deny all from 0.0.0.255:0.0.0.255' Note that the above only blocks the broadcast address of class C networks - you should adjust if you use subnet sizes other than /24. > Also, while on the topic of ipfw, does anyone know how much processor > overhead ipfw adds to the system ? I suppose the more rules one > adds the worse it gets. But does anyone have a reasonable guestimate ? A 686-120/P150+ with 500 rules and passing 200 pps amounting to more than 512kbps runs at about 4.5% CPU in 'system'. It also depends on the number of rules each packet is compared against. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Mon Jul 21 18:11:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA24641 for hackers-outgoing; Mon, 21 Jul 1997 18:11:39 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA24633; Mon, 21 Jul 1997 18:11:30 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA08327; Mon, 21 Jul 1997 18:13:50 -0700 (PDT) Message-Id: <199707220113.SAA08327@implode.root.com> To: Vinay Bannai cc: se@FreeBSD.ORG (Stefan Esser), freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel panic in driver probe() routine In-reply-to: Your message of "Mon, 21 Jul 1997 15:21:06 PDT." <199707212221.PAA03602@agni.nuko.com> From: David Greenman Reply-To: dg@root.com Date: Mon, 21 Jul 1997 18:13:49 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Here vmaddr did not point to a memory region allocated by >> malloc, but to one that got a virtual to physical mapping >> established by a call to pmap_mapdev (/sys/i386/i386/pmap.c). > >STefan, > >You are correct. I just looked at the code for pmap.c and it in turn calls >kern_alloc_pageable(). I don't exaclty understand all the stuff about maps >and submaps, but seems like the virtual memory is not coming from the >place where malloc() gets it!! ... >> You may want to ask David Greenman about how to release >> such a mapping. I didn't bother, since the page table entry >> created for the device consumes only 4 bytes per 4KB page >> you allocated, and the code to free the page table entries >> is likely to be much larger, except for large regions ... >> >> Regards, STefan > >Yup. I will just ignore it for the time being and bother DG later on when >I start running into DMA problems. :-) > >The PCI device that I am interfacing is capable of doing lot more things >(since it has got a i960 processor wiht 4M of RAM). But initially I want >to test by passing back and forth to the card some packets of fixed >size. Are there any guidelines as to how much memory I should allocate for >the Rx and Tx buffers? I am bad at picking numbers :-) You can free it by calling kmem_free(kernel_map, addr, size). This will remove the mapping and return the virtual address space back to the kernel. As Stefan said, for small allocations it isn't worth the trouble, but it is for large allocations. This is a little different from malloced memory where real (physical) memory is consumed and it is always desired to free it when it will no longer be used. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jul 21 18:20:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA25084 for hackers-outgoing; Mon, 21 Jul 1997 18:20:18 -0700 (PDT) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA25079 for ; Mon, 21 Jul 1997 18:20:14 -0700 (PDT) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id SAA27799 for hackers@freebsd.org; Mon, 21 Jul 1997 18:10:56 -0700 Date: Mon, 21 Jul 1997 18:10:56 -0700 From: Joe McGuckin Message-Id: <199707220110.SAA27799@monk.via.net> To: hackers@freebsd.org Subject: MAX physical memory for FreeBSD ? X-Sun-Charset: US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Linux has a 1G limit on physical memory. What's the limit for FreeBSD? From owner-freebsd-hackers Mon Jul 21 18:36:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA25868 for hackers-outgoing; Mon, 21 Jul 1997 18:36:22 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA25861 for ; Mon, 21 Jul 1997 18:36:20 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA08759; Mon, 21 Jul 1997 18:38:37 -0700 (PDT) Message-Id: <199707220138.SAA08759@implode.root.com> To: Aaron Smith cc: hackers@FreeBSD.ORG Subject: Re: pstat -T broken? In-reply-to: Your message of "Mon, 21 Jul 1997 17:41:13 PDT." From: David Greenman Reply-To: dg@root.com Date: Mon, 21 Jul 1997 18:38:36 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >i synced (with current) and made world today, and happened to notice that >'pstat -T' fails and complains about KERN_VNODE being undefined. anyone >else have this problem, or is it something with my config? I had to comment out support for that sysctl due to design problems with it resulting in systemn crashes. Sysctl just isn't up to passing potentially 10's of megabytes back to user processes. Further, there is also a significant security concern with providing so much information about all of the open files in the system. The information provided by pstat -T can be had via sysctl(8) and pstat -s. pstat -T should probably be nuked entirely or changed to use other mechanisms to get the information. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jul 21 19:06:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA27499 for hackers-outgoing; Mon, 21 Jul 1997 19:06:02 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27494 for ; Mon, 21 Jul 1997 19:05:54 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id VAA09073; Mon, 21 Jul 1997 21:05:49 -0500 (EST) From: "John S. Dyson" Message-Id: <199707220205.VAA09073@dyson.iquest.net> Subject: Re: MAX physical memory for FreeBSD ? In-Reply-To: <199707220110.SAA27799@monk.via.net> from Joe McGuckin at "Jul 21, 97 06:10:56 pm" To: joe@via.net (Joe McGuckin) Date: Mon, 21 Jul 1997 21:05:49 -0500 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Linux has a 1G limit on physical memory. > > What's the limit for FreeBSD? > There is no known limitation, other than the limitation due to the virtual space taken up by the kernel (256MB or so.) It is likely that a system as large as 1G would require a kernel that has 512M-1GB of virtual space. To attain that requires special tuning, but should work. Also, due to some unfortunate decisions in the BSDI startup-code, BSDI binary support is also broken when tuning the kernel size > 256MB. John From owner-freebsd-hackers Mon Jul 21 19:14:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA27973 for hackers-outgoing; Mon, 21 Jul 1997 19:14:19 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27967 for ; Mon, 21 Jul 1997 19:14:14 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA26015; Tue, 22 Jul 1997 11:44:05 +0930 (CST) From: Michael Smith Message-Id: <199707220214.LAA26015@genesis.atrad.adelaide.edu.au> Subject: Re: Is support of Adaptec 152x truely flakey? In-Reply-To: <199707220057.UAA08147@townhouse.dyn.ml.org> from Matthew Hunt at "Jul 21, 97 08:57:39 pm" To: mph@pobox.com (Matthew Hunt) Date: Tue, 22 Jul 1997 11:44:05 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Matthew Hunt stands accused of saying: > > > You could try putting a printf in uha_init in i386/isa/ultra14f.c in > > the function uha_init() thus : > > > > model = inb(ur->id); > > submodel = inb(ur->id + 1); > > printf("uha%d: model %d submodel %d\n", uha->unit, model, submodel); > > > > I suspect that the 34FB has a different set of identifiers... > > When I first looked at the code, I did just that. I also removed the > check on the model and submodel, so that the code would forge ahead > into the unknown. The results were less than inspiring. From my > logs: > > Jul 9 23:47:41 townhouse /kernel: uha0: model=ff submodel=ff Ouch. Looks like it's Just Not There. I presume you're sure you had the I/O address correct? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 19:20:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA28415 for hackers-outgoing; Mon, 21 Jul 1997 19:20:12 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA28408 for ; Mon, 21 Jul 1997 19:20:07 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA09222; Mon, 21 Jul 1997 19:22:26 -0700 (PDT) Message-Id: <199707220222.TAA09222@implode.root.com> To: Joe McGuckin cc: hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-reply-to: Your message of "Mon, 21 Jul 1997 18:10:56 PDT." <199707220110.SAA27799@monk.via.net> From: David Greenman Reply-To: dg@root.com Date: Mon, 21 Jul 1997 19:22:26 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Linux has a 1G limit on physical memory. > >What's the limit for FreeBSD? There isn't any specific limit, but some kernel parameters need to be tweaked before more than 256MB can be used. Someday this will hopefully be made a bit more automatic. Wcarchive has 512MB of RAM and I've heard of a few FreeBSD systems running with 1GB of RAM. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Mon Jul 21 19:27:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA28804 for hackers-outgoing; Mon, 21 Jul 1997 19:27:56 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA28799; Mon, 21 Jul 1997 19:27:44 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA26105; Tue, 22 Jul 1997 11:56:49 +0930 (CST) From: Michael Smith Message-Id: <199707220226.LAA26105@genesis.atrad.adelaide.edu.au> Subject: Re: pcireg.h lost children... ? In-Reply-To: <199707212104.OAA11882@phaeton.artisoft.com> from Terry Lambert at "Jul 21, 97 02:04:10 pm" To: terry@lambert.org (Terry Lambert) Date: Tue, 22 Jul 1997 11:56:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > Now, if we remove this information from the driver and put it > > somewhere in a Big Central Localtion, like, oh say W95 does (seeing as > > you respect their design decisions), the central localtion can be > > updated rapidly without having to rebuild and reinstall the driver. > > I don't exactly respect their design decisions; it's just that, > given a choice between some of the BSD design decisions and the > Win95 design decisions, I'd pick the Win95 where ever they've made > tradeoffs in favor of ease of use and BSD hasn't. "I don't respect their decisions, except where I respect them". Erk. > > Nifty, eh? > > Yes, if it's only a trade of location and not one of size, then > abstraction is the correct apporach, when possible. More to the point, localisation of this sort of data makes management of said data much easier. > I was actually looking at the draft proposal for the LDAP MIB for > POSIX systems, the other day. It seems to me that a locally > maintained LDAP breanch accessed through a local library that > could go remote if the information wasn't there, and wasn't able > to try to go remote until the network services were actually up, > is the correct future direction for UNIX password files, etc.. > > And probably this information, as well. Yeah. Insert a new network card. See a message saying "waiting for a network connection so I can get details on this new network card". Nope. My initial preference actually would be to load the entire table into memory during the boot process, pull out the values that match the installed hardware and ditch the remainder. This naturally wins if the file containing the table is somewhere tidy like in /boot or on the hypothetical boot filesystem. Speaking of network drivers; a while back you were blathering about how we should consider supporting 32-bit NDIS drivers via a module interface. Do you still think this? I spent some time reading what (little) Microsoft have made public about the new NDIS 5.x spec and TBH it looks like a monster. Is there an older, saner spec that's worth perusing anywhere? > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 19:28:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA28882 for hackers-outgoing; Mon, 21 Jul 1997 19:28:29 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA28865; Mon, 21 Jul 1997 19:28:21 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA26119; Tue, 22 Jul 1997 11:58:13 +0930 (CST) From: Michael Smith Message-Id: <199707220228.LAA26119@genesis.atrad.adelaide.edu.au> Subject: Re: pcireg.h lost children... ? In-Reply-To: <19970721230113.24412@mi.uni-koeln.de> from Stefan Esser at "Jul 21, 97 11:01:13 pm" To: se@freebsd.org (Stefan Esser) Date: Tue, 22 Jul 1997 11:58:12 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, Shimon@i-connect.net, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser stands accused of saying: > > Well, and you forgot the third case: You can add the > information in the user configuration step. If there > is a device ID that is not (yet) in the kernel, you > can ask for it, and will just have to supply an eight > digit hex number and the driver name (typically three > characters) to assign the device. In visual config > you might even be able to just select one device with > an unknown ID, and then choose the driver to assign > from a menu of compiled in PCI drivers :) That's all part of the plan. I want to see if I can't integrate the ISA PnP stuff too. Doug R., are you still following this thread? > Regards, STefan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 20:57:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03289 for hackers-outgoing; Mon, 21 Jul 1997 20:57:35 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03284 for ; Mon, 21 Jul 1997 20:57:31 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA26773; Tue, 22 Jul 1997 13:27:13 +0930 (CST) From: Michael Smith Message-Id: <199707220357.NAA26773@genesis.atrad.adelaide.edu.au> Subject: Re: utmp/wtmp interface In-Reply-To: <199707211442.AAA00370@labs.usn.blaze.net.au> from David Nugent at "Jul 22, 97 00:42:38 am" To: davidn@labs.usn.blaze.net.au (David Nugent) Date: Tue, 22 Jul 1997 13:27:12 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Nugent stands accused of saying: > > > It's all there. What's missing? > > > > Uhm, some idea of what you're heading towards. I misread the lastlog.3 > > manpage and misunderstood how much of it had been updated too. > > All that's different is a standardised API. In fact, this goes for > all of the modules. Nothing has (yet) changed about any of the > file formats - which a "suggested" alternate implementation for Argh. Yes, I missed the #ifdef's. *blush* > What I am attempting to do is to define an API to access these > files, not radically change the format of the files overnight. Ok, going back to this. With the xutmpinfo struct; is the plan to only support one, or a colocated array of several terminated with one with xi_type set to XUT_NONE? [file format changes] > definitely require a change in format. Personally, I prever a > text-based format with extensions in keyword=data style or > something similar. You can deal with that in any language > - even /bin/sh - with very little loss in performance. Actually, I would have suggested a textual format, but I thought that the screams would be audible from here. If you think it's a goer, you have my absolute support. > The idea is not to change the format of the files immediately, > but to first define an API to access them so that it allows Understood. > Absolutely it is, and the penalty is paid by the non-threaded > version, and it makes the code more complex then it need be in > any case. The point is whether there is any benefit in making it > thread-safe. :-) Good question. Maybe save worrying about that until it needs to be? > David -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon Jul 21 22:49:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08005 for hackers-outgoing; Mon, 21 Jul 1997 22:49:32 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08000; Mon, 21 Jul 1997 22:49:30 -0700 (PDT) Received: from localhost (brightmn@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id BAA10705; Fri, 4 Jul 1997 01:52:33 GMT Date: Fri, 4 Jul 1997 01:52:33 +0000 (GMT) From: Alfred Perlstein To: Mike D Tancsa cc: questions@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: preventing ICMP echo requests to the broadcast address In-Reply-To: <199707211843.OAA29815@granite.sentex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Also, while on the topic of ipfw, does anyone know how much processor > overhead ipfw adds to the system ? I suppose the more rules one > adds the worse it gets. But does anyone have a reasonable guestimate ? i assume very little. because ipfw rules are very simple, if you have a common action to take with certain packets try to put it first in the rule list, that way not as many rules have to be checked. figuring that IPs are 32 bit numbers it's not a very complex formula that ipfw has to go through... Alfred From owner-freebsd-hackers Mon Jul 21 23:31:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09878 for hackers-outgoing; Mon, 21 Jul 1997 23:31:22 -0700 (PDT) Received: from avon-gw.uk1.vbc.net (jdd@avon-gw.uk1.vbc.net [194.207.2.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09872 for ; Mon, 21 Jul 1997 23:31:19 -0700 (PDT) Received: (from jdd@localhost) by avon-gw.uk1.vbc.net (8.8.2/8.7.3) id HAA28669; Tue, 22 Jul 1997 07:31:17 +0100 (BST) Date: Tue, 22 Jul 1997 07:31:16 +0100 (BST) From: Jim Dixon X-Sender: jdd@avon-gw.uk1.vbc.net To: David Greenman cc: hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-Reply-To: <199707220222.TAA09222@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 21 Jul 1997, David Greenman wrote: > >Linux has a 1G limit on physical memory. > > > >What's the limit for FreeBSD? > > There isn't any specific limit, but some kernel parameters need to be > tweaked before more than 256MB can be used. Which? We have a machine (a root name server) that needs to be brought up to 512 MB urgently. > Someday this will hopefully > be made a bit more automatic. Wcarchive has 512MB of RAM and I've heard > of a few FreeBSD systems running with 1GB of RAM. -- Jim Dixon VBCnet GB Ltd http://www.vbc.net tel +44 117 929 1316 fax +44 117 927 2015 From owner-freebsd-hackers Tue Jul 22 00:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12657 for hackers-outgoing; Tue, 22 Jul 1997 00:25:58 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12648 for ; Tue, 22 Jul 1997 00:25:47 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 2690 invoked by uid 1001); 22 Jul 1997 07:25:42 +0000 (GMT) To: terry@lambert.org Cc: hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: Your message of "Mon, 21 Jul 1997 17:23:14 -0700 (MST)" References: <199707220023.RAA12174@phaeton.artisoft.com> X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 22 Jul 1997 09:25:41 +0200 Message-ID: <2688.869556341@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > : Can you please explain how root ownership makes something more secure? > > > > Files owned by root are harder to change via NFS than files owned by > > bin. root access n NFS is generally blocked, but no so with other, > > non-zero uids. > > This only argues for read-only export of / and /user FS's, as far > as I can see, and not for root rather than bin ownership of files or > directories themselves. The only argument I've heard so far *for* the bin ownership is Terry Lambert's: > The ability to update machines remotely via NFS, which proxies root > as "nobody" in most sane configurations. But if you export the file systems read-only, you can't perform remote updates via NFS. If you *do* export the file systems read-write, in order to enable remote updates, you're at the mercy of any machine that can mount file systems (or guess file handles) from your machine. I've been the administrator for several large NFS-based installations. We *never* did remote updates of /, /bin etc. via NFS, it was always rdist or a tar/rsh-pipe. These days I'd probably use a similar but ssh-based method. As for Terry's other comment, > OK, I don't understand why you believe that something being owned by > root, an account with password access, the password for which is > succeptible to being cracked, is somehow more secure than ownership > by bin, an account without password access and therefore *not* > succeptible to being cracked. In the absence of NFS, having a program owned by root instead of bin may not be more secure. But it is certainly no *less* secure - if my root account is cracked then file ownership of bin means nothing anyway. So in short: I want root ownership as default because it is *no less* secure for a local (non-NFS) installation, and is *more secure* in the presence of NFS. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Tue Jul 22 01:06:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15148 for hackers-outgoing; Tue, 22 Jul 1997 01:06:26 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15142 for ; Tue, 22 Jul 1997 01:06:22 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id BAA22961; Tue, 22 Jul 1997 01:05:40 -0700 (PDT) Date: Tue, 22 Jul 1997 01:05:38 -0700 (PDT) From: Jaye Mathisen To: Jim Dixon cc: David Greenman , hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Other than setting MAXMEM, and making sure you have the latest pmap.c (I think patches) you'd be fine. I had 512MB in a box, and it worked fine, and I distinctly remember somebody on this list with 1GB. On Tue, 22 Jul 1997, Jim Dixon wrote: > On Mon, 21 Jul 1997, David Greenman wrote: > > > >Linux has a 1G limit on physical memory. > > > > > >What's the limit for FreeBSD? > > > > There isn't any specific limit, but some kernel parameters need to be > > tweaked before more than 256MB can be used. > > Which? We have a machine (a root name server) that needs to be brought > up to 512 MB urgently. > > > Someday this will hopefully > > be made a bit more automatic. Wcarchive has 512MB of RAM and I've heard > > of a few FreeBSD systems running with 1GB of RAM. > > -- > Jim Dixon VBCnet GB Ltd http://www.vbc.net > tel +44 117 929 1316 fax +44 117 927 2015 > From owner-freebsd-hackers Tue Jul 22 01:10:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15540 for hackers-outgoing; Tue, 22 Jul 1997 01:10:36 -0700 (PDT) Received: from mail.tamu.edu (mail.tamu.edu [128.194.103.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15532; Tue, 22 Jul 1997 01:10:32 -0700 (PDT) Received: from dropzone.tamu.edu (dropzone.tamu.edu [165.91.210.99]) by mail.tamu.edu (8.8.5/8.8.5) with SMTP id DAA27674; Tue, 22 Jul 1997 03:10:31 -0500 (CDT) Received: from jumprun.tamu.edu by dropzone.tamu.edu (SMI-8.6/SMI-SVR4) id DAA28936; Tue, 22 Jul 1997 03:06:10 -0500 Received: from localhost by jumprun.tamu.edu (SMI-8.6/SMI-SVR4) id DAA03279; Tue, 22 Jul 1997 03:10:40 -0500 Date: Tue, 22 Jul 1997 03:10:40 -0500 (CDT) From: "Jo, SanKu" To: freebsd-multimedia@freebsd.org cc: freebsd-hackers@freebsd.org Subject: VIF : the bandwidth taken by multicasting packet Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy ! Because I hope to check the Bandwidth taken by the IP multicastingrouter(FreeBSD box), I tried to use iotcl(Channel_descriptor, SIOCGETVIFCNT, struct *sioc_vif_req). I heard this function retruns the input and output Bandwidth. There are two cases for testing. 1. When Host-A is source and Host-B is receiver, the Bandwidth rate value returned by the function is correct. 2. When Host-B is source and Host-A is receiver, the Bandwidth rate value(out_bytes) retruned by the function is wrong. Even the case witout any receiver in Backbone(as Host-A), the function returns the whole bandwidth rate(in_bytes) which is taken by the source, HOST-B. I think the prune function is all right. Below is my configuration with multicast routers denoted by asterisks: ======++=====BackBOne <--in || -->out || HOST-A VIF Research Subnet HOST-B ------++---------- --------------------- || ---------- |sparc* | ethernet | freebsd 2.1 * | || |sparc | | 128.194.169.93 |-----------|169.53 166.4 |---++-------| 166.5 | | 3.8 | | 3.3 | || | | ------------------ --------------------- || ---------- Its' default gateway is freebsd How can I get correct bandwidth for the second case ? Is it possible or not to get it ? And where can I get some information for hacking the multicasting function in FreeBSD ? Any comment will be very appreciated. Thank you for your kind attention ! Best regards, Jo, SanKu Texas A&M University. Http://ee.tamu.edu/~skjo From owner-freebsd-hackers Tue Jul 22 01:12:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15648 for hackers-outgoing; Tue, 22 Jul 1997 01:12:16 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15632 for ; Tue, 22 Jul 1997 01:12:10 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id BAA12568; Tue, 22 Jul 1997 01:14:22 -0700 (PDT) Message-Id: <199707220814.BAA12568@implode.root.com> To: Jim Dixon cc: hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-reply-to: Your message of "Tue, 22 Jul 1997 07:31:16 BST." From: David Greenman Reply-To: dg@root.com Date: Tue, 22 Jul 1997 01:14:22 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> There isn't any specific limit, but some kernel parameters need to be >> tweaked before more than 256MB can be used. > >Which? We have a machine (a root name server) that needs to be brought >up to 512 MB urgently. Ugh. Actually, the kernel virtual address space must be increased and this requires, in addition to changing some kernel parameters (which are hardcoded in a couple of source files), that you do a "make world" to fix certain kernel start address assumptions that are in some of the system utilities. Patches attached. Note that the process limit increases aren't strictly necessary, but are probably desired. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project Index: i386/conf/Makefile.i386 =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/Makefile.i386,v retrieving revision 1.89.2.3 diff -c -r1.89.2.3 Makefile.i386 *** Makefile.i386 1997/06/29 16:44:41 1.89.2.3 --- Makefile.i386 1997/07/02 08:56:28 *************** *** 36,42 **** .endif COPTS= ${INCLUDES} ${IDENT} -DKERNEL CFLAGS= ${COPTFLAGS} ${CWARNFLAGS} ${DEBUG} ${COPTS} ! LOAD_ADDRESS?= F0100000 .if defined(PROF) CFLAGS+= -malign-functions=4 .if ${PROFLEVEL} >= 2 --- 36,42 ---- .endif COPTS= ${INCLUDES} ${IDENT} -DKERNEL CFLAGS= ${COPTFLAGS} ${CWARNFLAGS} ${DEBUG} ${COPTS} ! LOAD_ADDRESS?= E0100000 .if defined(PROF) CFLAGS+= -malign-functions=4 .if ${PROFLEVEL} >= 2 Index: i386/include/pmap.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/pmap.h,v retrieving revision 1.46 diff -c -r1.46 pmap.h *** pmap.h 1996/10/13 03:14:57 1.46 --- pmap.h 1997/04/07 08:12:53 *************** *** 91,97 **** #define NKPT 9 /* actual number of kernel page tables */ #endif #ifndef NKPDE ! #define NKPDE 63 /* addressable number of page tables/pde's */ #endif /* --- 91,97 ---- #define NKPT 9 /* actual number of kernel page tables */ #endif #ifndef NKPDE ! #define NKPDE 127 /* addressable number of page tables/pde's */ #endif /* Index: i386/include/vmparam.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/vmparam.h,v retrieving revision 1.21.2.1 diff -c -r1.21.2.1 vmparam.h *** vmparam.h 1997/03/25 04:54:02 1.21.2.1 --- vmparam.h 1997/04/07 08:12:53 *************** *** 52,67 **** */ #define MAXTSIZ (16UL*1024*1024) /* max text size */ #ifndef DFLDSIZ ! #define DFLDSIZ (64UL*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ ! #define MAXDSIZ (128UL*1024*1024) /* max data size */ #endif #ifndef DFLSSIZ #define DFLSSIZ (8UL*1024*1024) /* initial stack size limit */ #endif #ifndef MAXSSIZ ! #define MAXSSIZ (64UL*1024*1024) /* max stack size */ #endif #ifndef SGROWSIZ #define SGROWSIZ (128UL*1024) /* amount to grow stack */ --- 52,67 ---- */ #define MAXTSIZ (16UL*1024*1024) /* max text size */ #ifndef DFLDSIZ ! #define DFLDSIZ (256UL*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ ! #define MAXDSIZ (256UL*1024*1024) /* max data size */ #endif #ifndef DFLSSIZ #define DFLSSIZ (8UL*1024*1024) /* initial stack size limit */ #endif #ifndef MAXSSIZ ! #define MAXSSIZ (128UL*1024*1024) /* max stack size */ #endif #ifndef SGROWSIZ #define SGROWSIZ (128UL*1024) /* amount to grow stack */ *************** *** 114,120 **** #define VM_MIN_ADDRESS ((vm_offset_t)0) /* virtual sizes (bytes) for various kernel submaps */ ! #define VM_KMEM_SIZE (32 * 1024 * 1024) /* read and exec are the same thing */ #define VM_PROT_READ_IS_EXEC --- 114,120 ---- #define VM_MIN_ADDRESS ((vm_offset_t)0) /* virtual sizes (bytes) for various kernel submaps */ ! #define VM_KMEM_SIZE (96 * 1024 * 1024) /* read and exec are the same thing */ #define VM_PROT_READ_IS_EXEC From owner-freebsd-hackers Tue Jul 22 01:17:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15885 for hackers-outgoing; Tue, 22 Jul 1997 01:17:26 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15880 for ; Tue, 22 Jul 1997 01:17:23 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id BAA12645; Tue, 22 Jul 1997 01:19:19 -0700 (PDT) Message-Id: <199707220819.BAA12645@implode.root.com> To: Jaye Mathisen cc: Jim Dixon , hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-reply-to: Your message of "Tue, 22 Jul 1997 01:05:38 PDT." From: David Greenman Reply-To: dg@root.com Date: Tue, 22 Jul 1997 01:19:19 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Other than setting MAXMEM, and making sure you have the latest pmap.c (I >think patches) you'd be fine. > >I had 512MB in a box, and it worked fine, and I distinctly remember >somebody on this list with 1GB. The machine will boot and may even work with certain loads, but machines that need lots of networking buffers or other kernel resources will run out of kernel virtual memory and will need the patches I sent in a previous message. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Jul 22 02:12:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA18145 for hackers-outgoing; Tue, 22 Jul 1997 02:12:31 -0700 (PDT) Received: from schubert.promo.de (schubert.Promo.DE [194.45.188.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA18139 for ; Tue, 22 Jul 1997 02:12:26 -0700 (PDT) Received: from [194.45.188.81] (stefan.Promo.DE [194.45.188.81]) by schubert.promo.de (8.8.5/8.8.5) with ESMTP id LAA28506; Tue, 22 Jul 1997 11:02:20 +0200 (MET DST) X-Sender: stefan@mail.promo.de Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Jul 1997 11:06:46 +0200 To: netatalk-admins@umich.edu, freebsd-hackers@freebsd.org From: Stefan Bethke Subject: [ANNOUNCE] MacIP Gateway for FreeBSD - 2nd beta release Cc: Ian Stephenson , Raul Zighelboim Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yep, so much for "release engineering"... ABOUT MACIPGW ============= This is the 2nd beta release of macipgw, a MacIP gateway for FreeBSD. MacIP is a protocol that allows the encapsulation of IP packets in AppleTalk packets, thus allowing Macs connected through an AppleTalk-only network (such as LocalTalk or Appe Remote Access) to use TCP/IP-based services. To use macipgw, you need FreeBSD 2.1.5 or newer with AppleTalk kernel patches (see ftp://ftp.promo.de/people/stefan/netatalk/) or FreeBSD 2.2.1 or newer. Also, you'll need to install netatalk 1.4b2 or later. Also, you'll need one tunnel device for macipgw, see tun(4) for details. Please direct questions, comments, diffs to . The latest beta version of macipgw can be found at ftp://ftp.promo.de/pub/people/stefan/netatalk/ http://www.promo.de/pub/people/stefan/netatalk/ July 22, 1997, Stefan Bethke WHATS NEW ========= New in 1.0b2: - Fixed a compiler warning in macip.c - -z zone now does what it is supposed to do - now works correctly if there are no zones The whole idea of the gateway being a router and handling ICMP is crap; it will be removed in a later release. INSTALLING ========== A `make depend all install' as root should work. If you have installed the netatalk include files (atalk) neither in /usr/include nor in /usr/local/include, adapt the Makefile appropiatly. Please see the man page macipgw(8) for details on how to start macipgw. Cheers, Stefan -- Stefan Bethke Promo Datentechnik | Tel. +49-40-851744-0 + Systemberatung GmbH | Fax. +49-40-851744-44 Eduardstrasse 46-48 | e-mail: stefan@Promo.DE D-20257 Hamburg | http://www.Promo.DE/ From owner-freebsd-hackers Tue Jul 22 02:15:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA18278 for hackers-outgoing; Tue, 22 Jul 1997 02:15:41 -0700 (PDT) Received: from ns.uk.peer.net ([194.117.157.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA18244 for ; Tue, 22 Jul 1997 02:14:59 -0700 (PDT) Received: (from aledm@localhost) by ns.uk.peer.net (8.6.12/8.6.12) id KAA06877; Tue, 22 Jul 1997 10:38:16 +0100 Date: Tue, 22 Jul 1997 10:38:13 +0100 (BST) From: Aled Morris X-Sender: aledm@ns.uk.peer.net To: hackers@freebsd.org cc: "Perry E. Metzger" Subject: Re: is there a market for this? In-Reply-To: <199707212126.RAA06332@jekyll.piermont.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 21 Jul 1997, Perry E. Metzger wrote on the NANOG mailing list: > I have a friend who's in the high speed optoelectronics biz and > already does lots of OC-[N] equipment, and I mentioned to him that I > thought that there was probably a market for PCI cards that spoke IP > over OC-3/OC-12. Before I strongly encourage him to do this, I was > curious as to whether anyone else felt there was a real market for > such things. (Perry, I hope you don't mind me distributing your message like this!) Hackers - please reply directly to Perry, not me. Aled -- tel +44 973 207987 O- From owner-freebsd-hackers Tue Jul 22 02:16:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA18380 for hackers-outgoing; Tue, 22 Jul 1997 02:16:43 -0700 (PDT) Received: from mail.wup.de (ns.wup.de [149.237.200.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA18347; Tue, 22 Jul 1997 02:16:29 -0700 (PDT) Received: (from root@localhost) by mail.wup.de (8.8.6/8.8.6) id LAA25674; Tue, 22 Jul 1997 11:15:37 +0200 (CEST) Message-ID: <19970722111536.51938@wup.de> Date: Tue, 22 Jul 1997 11:15:36 +0200 From: Andreas Klemm To: hackers@freebsd.org Cc: ports@freebsd.org Subject: FBSD 2.2.2 - problem: no colors when using mutt in a color xterm Reply-To: andreas.klemm@wup.de, andreas@klemm.gtn.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 X-phone: Wiechers & Partner +49 2173 3964 161 X-fax: Wiechers & Partner +49 2173 3964 222 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! At home I'm using FreeBSD-current and X11R6.3. There it's possible, to get mutt configured to use colors. I start xterm +xm -tn xterm-color, start mutt from within this xterm session and get nice colors. When doing this on FreeBSD 2.2.2 using X11R6.2 (the FreeBSD version shipped with 2.2.2), then I only get black and white display. Is some solor support not implemented in 2.2.2 ??? Andreas /// From owner-freebsd-hackers Tue Jul 22 02:49:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA19764 for hackers-outgoing; Tue, 22 Jul 1997 02:49:44 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA19756 for ; Tue, 22 Jul 1997 02:49:38 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.6/8.8.5) with SMTP id LAA13176; Tue, 22 Jul 1997 11:50:29 +0200 (CEST) Date: Tue, 22 Jul 1997 11:50:28 +0200 (CEST) From: Andrzej Bialecki To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Compressed FS In-Reply-To: <199707220018.RAA12149@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 21 Jul 1997, Terry Lambert wrote: > The BSD layering is such that the VM issues are, in some cases, > hard to overcome (which is why union FS's currently don't work > in the main line tree). Any compression (or cryptographic) FS > would face similar problems, since it would need to maintain > seperate cache data for the uncompressed (or deencrypted) file > blocks. I see... But I had the impression that unions and portals work pretty well under -current - I used them several times and they didn't burn the house down :-) Current's LINT file contains information about these FSs being broken. Is it still true? Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-hackers Tue Jul 22 03:56:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA21928 for hackers-outgoing; Tue, 22 Jul 1997 03:56:23 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA21909; Tue, 22 Jul 1997 03:56:08 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 22 Jul 1997 6:53:41 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA13633; Tue, 22 Jul 97 06:53:34 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id GAA25966; Tue, 22 Jul 1997 06:51:19 -0400 Message-Id: <19970722065118.42843@ct.picker.com> Date: Tue, 22 Jul 1997 06:51:18 -0400 From: Randall Hopper To: andreas.klemm@wup.de, andreas@klemm.gtn.com Cc: hackers@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: FBSD 2.2.2 - problem: no colors when using mutt in a color xterm References: <19970722111536.51938@wup.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970722111536.51938@wup.de>; from Andreas Klemm on Tue, Jul 22, 1997 at 11:15:36AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm: |At home I'm using FreeBSD-current and X11R6.3. There it's possible, to get |mutt configured to use colors. | |I start xterm +xm -tn xterm-color, start mutt from within this |xterm session and get nice colors. | |When doing this on FreeBSD 2.2.2 using X11R6.2 (the FreeBSD version |shipped with 2.2.2), then I only get black and white display. | |Is some solor support not implemented in 2.2.2 ??? Yes, you have at least two options: Option #1: If compiled with either ncurses or Slang: setenv TERM xterm-color to activate a terminal entry that has the color-capability set. This has the conn that the xterm-color entry isn't as well written as the xterm one, so some of your terminal emulation won't work as well. Read on... Option #2: If compiled with Slang, just use your regular "xterm" terminal entry (i.e. leave TERM set to "xterm") and: setenv COLORTERM y I recommend compiling with Slang. I've been running with it on FreeBSD and Solaris for a good while now, doing color with both mutt and slrn (a news reader). Randall From owner-freebsd-hackers Tue Jul 22 05:36:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA25498 for hackers-outgoing; Tue, 22 Jul 1997 05:36:40 -0700 (PDT) Received: from extrouter.test.cdu.elektra.ru ([193.125.114.71]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA25453; Tue, 22 Jul 1997 05:36:04 -0700 (PDT) Received: from mailhub.cdu.ru (mailhub.cdu.ru [172.16.10.50]) by extrouter.test.cdu.elektra.ru (8.8.6/8.8.6) with ESMTP id QAA00334; Tue, 22 Jul 1997 16:34:59 +0400 (MSD) Received: from mailhub.cdu.ru (Win95.cdu.ru [172.16.2.10]) by mailhub.cdu.ru (8.8.6/8.8.6) with ESMTP id QAA00462; Tue, 22 Jul 1997 16:35:19 +0400 (MSD) Message-Id: <199707221235.QAA00462@mailhub.cdu.ru> From: "Win95" To: "FreeBSD bugs" , "FreeBSD current" , "FreeBSD hackers" , "FreeBSD hubs" , "FreeBSD hardware" , "FreeBSD isp" , "FreeBSD questions" , "FreeBSD security" Subject: I have a problem with Ethernet adapters! Date: Tue, 22 Jul 1997 16:27:08 +0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I've installed the FreeBSD 2.2.2-RELEASE on three PC (Gateway2000 P5-100) to make a Firewall. But there is something strange with my Ethernet adapters :-( There is my schema: | | | | x------------x | x------------x | <------X ext_router X-----X------X int_router X----X to my x------------x | x------------x | provider | | x----------x | X-------X mail_hub | | | x----------x | | | | x----------x | X-------X client | | x----------x | | All computers have FreeBSD 2.2.2-RELEASE. ext_router and int_router have two Ethernet adapters: 3Com 3C900 and SMC 80xx. mail_hub have 3Com 3C509 Ethernet adapter. Now I try to describe my problem: When I try to download a file from ext_router to int_router via FTP, transfer rate is around 700 KBytes/sec. The same transfere rate is when I try to transfer a file from int_router to mail_hub or even from ext_router to mail_hub! But if only I try to UPLOAD a file from int_router to ext_router, then transfer rate is only around 200 KBytes/sec! ;-((((( I have only one question: WHY? There is output of command "ifconfig -a" on int_router: vx0: flags=8843 mtu 1500 inet 193.125.114.36 netmask 0xffffffe0 broadcast 193.125.114.63 ether 00:60:97:b5:f6:37 ed0: flags=8843 mtu 1500 inet 172.16.10.35 netmask 0xffff0000 broadcast 172.16.255.255 ether 00:00:c0:50:6d:c3 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 Maybe, a SIMPLEX flag is wrong? HELP ME! It's very important for me! If you answer me by email, it may be more fast! PS: I'm so sorry for my English :-( Yours sincerely, Pavel ----------------------------------------------------------- Pavel P. Zabortsev, software engineer CDO UPS of Russia Tel.: (095) 220-4513, 220-4350 E-mail: ppz@cdu.elektra.ru ppz@usa.net ----------------------------------------------------------- From owner-freebsd-hackers Tue Jul 22 06:07:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA26731 for hackers-outgoing; Tue, 22 Jul 1997 06:07:20 -0700 (PDT) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26719; Tue, 22 Jul 1997 06:07:13 -0700 (PDT) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id XAA09218; Tue, 22 Jul 1997 23:06:03 +1000 (EST) Message-ID: <19970722230602.13588@rf900.physics.usyd.edu.au> Date: Tue, 22 Jul 1997 23:06:02 +1000 From: David Dawes To: andreas.klemm@wup.de, andreas@klemm.gtn.com Cc: hackers@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: FBSD 2.2.2 - problem: no colors when using mutt in a color xterm References: <19970722111536.51938@wup.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970722111536.51938@wup.de>; from Andreas Klemm on Tue, Jul 22, 1997 at 11:15:36AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Jul 22, 1997 at 11:15:36AM +0200, Andreas Klemm wrote: >At home I'm using FreeBSD-current and X11R6.3. There it's possible, to get >mutt configured to use colors. > >I start xterm +xm -tn xterm-color, start mutt from within this >xterm session and get nice colors. > >When doing this on FreeBSD 2.2.2 using X11R6.2 (the FreeBSD version >shipped with 2.2.2), then I only get black and white display. > >Is some solor support not implemented in 2.2.2 ??? The most common reason for xterm colour not working with XFree86 releases prior to XFree86 3.3 is that the colour resources are set in the XTerm-color app-defaults file, not the one called XTerm. One solution is to put: *customization: -color in your ~/.Xdefaults file. Another is to put the colour resource settings from the XTerm-color app-defaults file into the XTerm app-defaults file. In XFree86 3.3, the default configuation is colour-friendly. (BTW, FreeBSD 2.2.2 ships with XFree86 3.2 as far as I know, not X11R6.2 -- and the xterm in the standard X11R6.x releases doesn't do colour anyway.) David From owner-freebsd-hackers Tue Jul 22 06:43:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA28547 for hackers-outgoing; Tue, 22 Jul 1997 06:43:41 -0700 (PDT) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA28537 for ; Tue, 22 Jul 1997 06:43:36 -0700 (PDT) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA19374 for ; Tue, 22 Jul 1997 09:43:04 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id JAA00304 for ; Tue, 22 Jul 1997 09:42:38 -0400 (EDT) Message-Id: <199707221342.JAA00304@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: getting t_param called... Date: Tue, 22 Jul 1997 09:42:37 -0400 From: Brian McGovern Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a quick question on interrelationships between the ioctl() routine in a driver, and the routine thats in the t_param field of the tty structure. I believe I read someplace (correct me if I'm wrong), that the kernel, upon sensing an ioctl() call that COULD change line parameters, would call the routine specified in t_param on the ioctl()'s completion. >From what I can see, this is not the case. I may be wrong. I hope I'm wrong. But, right now I'm seeing baud rate changes that aren't being set on the hardware. Can someone clairfy this for me, or just tell me I was dreaming when I read about this? (It is possible...) :) -Brian From owner-freebsd-hackers Tue Jul 22 06:48:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA28848 for hackers-outgoing; Tue, 22 Jul 1997 06:48:16 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA28814 for ; Tue, 22 Jul 1997 06:47:55 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id PAA29497; Tue, 22 Jul 1997 15:30:33 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id HAA17133; Tue, 22 Jul 1997 07:41:50 +0200 (CEST) Message-ID: <19970722074150.52808@gtn.com> Date: Tue, 22 Jul 1997 07:41:50 +0200 From: Andreas Klemm To: Jaye Mathisen Cc: Terry Lambert , sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file References: <199707212106.OAA11898@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Jaye Mathisen on Mon, Jul 21, 1997 at 03:19:33PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Jul 21, 1997 at 03:19:33PM -0700, Jaye Mathisen wrote: > > Well, just to throw in my 2 bits, I don't really care who owns it, because > if root is compromised, who gives a flying leap about files being bin.bin, > your system is still open. Ok, true, but we don't speak about an already compromised server machine, we speak about a server machine, that might be less compromised, by giving the files other permissions. Ok, I also agree, that it's not a fine thing to do the following: server: /etc/exports /usr rw=client1 server: /etc/hosts.equiv client1 But if someone would do so who is not such a security freak, it would help, that the machine isn't crashed within minutes ... -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-hackers Tue Jul 22 06:52:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA29112 for hackers-outgoing; Tue, 22 Jul 1997 06:52:57 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA29101 for ; Tue, 22 Jul 1997 06:52:49 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id PAA29436; Tue, 22 Jul 1997 15:30:24 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id HAA16792; Tue, 22 Jul 1997 07:34:59 +0200 (CEST) Message-ID: <19970722073459.03298@gtn.com> Date: Tue, 22 Jul 1997 07:34:59 +0200 From: Andreas Klemm To: Warner Losh Cc: Terry Lambert , sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file References: <199707212106.OAA11898@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: ; from Warner Losh on Mon, Jul 21, 1997 at 03:46:17PM -0600 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Jul 21, 1997 at 03:46:17PM -0600, Warner Losh wrote: > In message <199707212106.OAA11898@phaeton.artisoft.com> Terry Lambert writes: > : Can you please explain how root ownership makes something more secure? > > > Files owned by root are harder to change via NFS than files owned by > bin. root access n NFS is generally blocked, but no so with other, > non-zero uids. Right ! I also experienced that fact once again in detail, when teaching a NFS course in our company. You have to give root access explicitely with the export flag root=client_machine_1:...:client_machine_n When adding hosts to /etc/hosts.equiv on the server you say your NFS client accounts are the same as on your local machine, in some computing environment it's necessary to do so ... Figure out what happens, if a client machine decides to compromise the server by making bin a login account ;-) Especially, if the client was given ,rw' or ,access' rights. I'd also recommend strongly, to change permissions to root root.wheel where possible ! -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-hackers Tue Jul 22 06:55:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA29280 for hackers-outgoing; Tue, 22 Jul 1997 06:55:39 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA29274 for ; Tue, 22 Jul 1997 06:55:34 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id PAA29470; Tue, 22 Jul 1997 15:30:29 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id HAA17101; Tue, 22 Jul 1997 07:37:11 +0200 (CEST) Message-ID: <19970722073711.20412@gtn.com> Date: Tue, 22 Jul 1997 07:37:11 +0200 From: Andreas Klemm To: Nate Williams Cc: Warner Losh , Terry Lambert , sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file References: <199707212106.OAA11898@phaeton.artisoft.com> <199707212214.QAA02162@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199707212214.QAA02162@rocky.mt.sri.com>; from Nate Williams on Mon, Jul 21, 1997 at 04:14:15PM -0600 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Jul 21, 1997 at 04:14:15PM -0600, Nate Williams wrote: > Warner Losh writes: > > In message <199707212106.OAA11898@phaeton.artisoft.com> Terry Lambert writes: > > : Can you please explain how root ownership makes something more secure? > > > > > > Files owned by root are harder to change via NFS.... > > Ahh, you said the dirty word, NFS. NFS stands for 'No Freaking > Security', so if you're using NFS, you've already given up any chance of > security. Nate, might be the case ... but can you give me reason, why making things even worse, if people have to use NFS ... Or are you arguing, there is no reason to make it any better secure, by changing file permissions, because you think it's insecure(tm) ?! ;-)) -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-hackers Tue Jul 22 07:04:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA29840 for hackers-outgoing; Tue, 22 Jul 1997 07:04:19 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA29786 for ; Tue, 22 Jul 1997 07:04:01 -0700 (PDT) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id RAA00732 for ; Tue, 22 Jul 1997 17:03:11 +0300 (EEST) Date: Tue, 22 Jul 1997 17:03:11 +0300 (EEST) From: Narvi To: hackers@freebsd.org Subject: NFS error messgaes: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is what I saw with my 2.2-stable: nfs_bioread: non vmio buf found, discarding With the last ~2 hours, there are already 14 of them all together. The environment - 2.2 stable, updated some days ago + patches to make the de0 driver work (de-970327) + if_media. Hardware - "yellow" intel FX chipset motherboard, P75 (non-overclocked), 32MB RAM. Sander There is no love, no good, no happiness and no future - all these are just illusions. From owner-freebsd-hackers Tue Jul 22 07:14:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA00517 for hackers-outgoing; Tue, 22 Jul 1997 07:14:37 -0700 (PDT) Received: from smtp1.ts.kiev.ua (viking.ts.kiev.ua [193.124.229.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA00508 for ; Tue, 22 Jul 1997 07:14:29 -0700 (PDT) Received: from aviion.ts.kiev.ua by smtp1.ts.kiev.ua with SMTP id QAA17096; (8.8.3/zah/2.1) Tue, 22 Jul 1997 16:58:56 +0300 (EET DST) Received: from nbki.ipri.kiev.ua by aviion.ts.kiev.ua with ESMTP id OAA12491; (8.6.11/zah/2.1) Tue, 22 Jul 1997 14:50:59 GMT Received: from cki.ipri.kiev.ua by nbki.ipri.kiev.ua with ESMTP id QAA22511; (8.6.9/zah/1.1) Tue, 22 Jul 1997 16:44:36 +0100 Received: from 194.44.146.14 (mac.ipri.kiev.ua [194.44.146.14]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with SMTP id QAA02998; Tue, 22 Jul 1997 16:46:12 +0300 (EET DST) Message-ID: <33D4ABF9.78B8@cki.ipri.kiev.ua> Date: Tue, 22 Jul 1997 15:47:53 +0300 From: Ruslan Shevchenko Reply-To: rssh@cki.ipri.kiev.ua Organization: IPRI X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K) MIME-Version: 1.0 To: Bob Bishop CC: hackers@FreeBSD.ORG Subject: Re: Iomega Zip References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bob Bishop wrote: > > Hi, > > Anyone using Iomega Zip drives with FBSD? Any hints/comments? TIA > I use parallel ZIP drive. work well. > -- > Bob Bishop (0118) 977 4017 international code +44 118 > rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Tue Jul 22 07:17:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA00670 for hackers-outgoing; Tue, 22 Jul 1997 07:17:17 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA00665 for ; Tue, 22 Jul 1997 07:17:15 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id IAA04808; Tue, 22 Jul 1997 08:17:00 -0600 (MDT) Date: Tue, 22 Jul 1997 08:17:00 -0600 (MDT) Message-Id: <199707221417.IAA04808@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andreas Klemm Cc: Nate Williams , Warner Losh , Terry Lambert , sthaug@nethelp.no, hackers@freebsd.org Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: <19970722073711.20412@gtn.com> References: <199707212106.OAA11898@phaeton.artisoft.com> <199707212214.QAA02162@rocky.mt.sri.com> <19970722073711.20412@gtn.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Files owned by root are harder to change via NFS.... > > > > Ahh, you said the dirty word, NFS. NFS stands for 'No Freaking > > Security', so if you're using NFS, you've already given up any chance of > > security. ... > Or are you arguing, there is no reason to make it any better > secure, by changing file permissions, because you think it's > insecure(tm) ?! ;-)) Yep. Changing the locks on the back-door of your house while leaving the front-door wide open is a false sense of security. Nate From owner-freebsd-hackers Tue Jul 22 07:45:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02418 for hackers-outgoing; Tue, 22 Jul 1997 07:45:55 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA01892; Tue, 22 Jul 1997 07:38:14 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA22798; Tue, 22 Jul 1997 15:32:17 +0200 From: Luigi Rizzo Message-Id: <199707221332.PAA22798@labinfo.iet.unipi.it> Subject: polling the status of a dma channel To: hackers@freebsd.org, multimedia@freebsd.org Date: Tue, 22 Jul 1997 15:32:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Recently I and others had a need to poll the status of a dma channel to determine if a transfer was proceeding or not. I came out with the following function which I placed in /sys/i386/isa/isa.c -- the place I believe it belongs to. Maybe we should consider adding this function to isa.c ? It would be useful for the sound driver and probably other drivers as well. Cheers Luigi ------------- /* * isa_dmapoll returns the number of pending bytes for a dma transfer * on the given channel. */ int isa_dmapoll(int chan) { u_long phy = 0 ; u_long cnt = 0 ; u_long flags ; int waport; if (dma_inuse & (1 << chan) == 0) { printf("chan %d not acquired\n", chan); return -1 ; } if (dma_busy & (1 << chan) == 0) { printf("chan %d not busy\n", chan); return -2 ; } flags = splhigh(); if ((chan & 4) == 0) { /* 8-bit channel */ outb(DMA1_FFC, 0); waport = DMA1_CHN(chan); phy= inb(waport) + (inb(waport) <<8) + (inb(dmapageport[chan]) <<16 ); cnt = inb(waport+1) + (inb(waport+1)<<8) +1; cnt &= 0xffff ; } else { outb(DMA2_FFC, 0); waport = DMA2_CHN(chan - 4); phy= inb(waport) + (inb(waport) <<8) + (inb(dmapageport[chan]) <<16 ); cnt = inb(waport+1) + (inb(waport+1)<<8) + 1; phy <<= 1; cnt <<= 1; cnt &= 0x1ffff ; } splx(flags); return cnt ; } Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Tue Jul 22 08:35:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04940 for hackers-outgoing; Tue, 22 Jul 1997 08:35:07 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA04926 for ; Tue, 22 Jul 1997 08:35:00 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA05427; Tue, 22 Jul 1997 09:34:41 -0600 (MDT) Date: Tue, 22 Jul 1997 09:34:41 -0600 (MDT) Message-Id: <199707221534.JAA05427@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Andreas Klemm Cc: Jaye Mathisen , Terry Lambert , sthaug@nethelp.no, hackers@freebsd.org Subject: Re: sendmail complains about being unable to write his pid file In-Reply-To: <19970722074150.52808@gtn.com> References: <199707212106.OAA11898@phaeton.artisoft.com> <19970722074150.52808@gtn.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Well, just to throw in my 2 bits, I don't really care who owns it, because > > if root is compromised, who gives a flying leap about files being bin.bin, > > your system is still open. > > Ok, true, but we don't speak about an already compromised server machine, > we speak about a server machine, that might be less compromised, by > giving the files other permissions. If you export files 'rw', you're machine can be compromised by any machine that has access to the packets. You're fooling yourself if you believe otherwise. Nate From owner-freebsd-hackers Tue Jul 22 08:52:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA06021 for hackers-outgoing; Tue, 22 Jul 1997 08:52:35 -0700 (PDT) Received: from internet.milkyway.com (milkyway.com [198.53.167.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA06016 for ; Tue, 22 Jul 1997 08:52:33 -0700 (PDT) Received: id LAA24487; Tue, 22 Jul 1997 11:41:28 -0400 Received: by gateway id LAA16411 for ; Tue, 22 Jul 1997 11:39:29 -0400 Received: by gateway id AA05702; Tue, 22 Jul 97 11:43:14 EDT Message-Id: <19970722114314.26901@milkyway.com> Date: Tue, 22 Jul 1997 11:43:14 -0400 From: Brian Campbell To: freebsd-hackers@FreeBSD.org Subject: ccd / scsi Reply-To: brianc@pobox.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have a suggestion (either positive or negative) for a pair of quiet, reasonably quick 2G SCSI drives for use with CCD? I'm assuming identical drives would be preferrable. From owner-freebsd-hackers Tue Jul 22 09:06:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA06860 for hackers-outgoing; Tue, 22 Jul 1997 09:06:44 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA06834 for ; Tue, 22 Jul 1997 09:06:34 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id RAA00505; Tue, 22 Jul 1997 17:06:04 +0100 (BST) Date: Tue, 22 Jul 1997 17:06:04 +0100 (BST) From: Doug Rabson To: Narvi cc: hackers@freebsd.org Subject: Re: NFS error messgaes: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Narvi wrote: > > This is what I saw with my 2.2-stable: > > nfs_bioread: non vmio buf found, discarding Don't worry about it. This is just informational. You should only see it for kernels build with DIAGNOSTIC. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 From owner-freebsd-hackers Tue Jul 22 09:22:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08825 for hackers-outgoing; Tue, 22 Jul 1997 09:22:57 -0700 (PDT) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08798 for ; Tue, 22 Jul 1997 09:22:35 -0700 (PDT) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id RAA02239; Tue, 22 Jul 1997 17:28:43 +0100 (BST) Date: Tue, 22 Jul 1997 17:28:42 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Michael Smith cc: David Nugent , freebsd-hackers@freebsd.org Subject: Re: utmp/wtmp interface In-Reply-To: <199707220357.NAA26773@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Michael Smith wrote: > David Nugent stands accused of saying: > > > Absolutely it is, and the penalty is paid by the non-threaded > > version, and it makes the code more complex then it need be in > > any case. The point is whether there is any benefit in making it > > thread-safe. :-) > > Good question. Maybe save worrying about that until it needs to be? But isn't the time of definition of the API the only chance to do it cheaply (ie. by having the caller pass in all required buffers, avoiding the need for static buffers in the library)? Qpologies if I've missed the point here. From owner-freebsd-hackers Tue Jul 22 09:44:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA10152 for hackers-outgoing; Tue, 22 Jul 1997 09:44:27 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA10142 for ; Tue, 22 Jul 1997 09:44:11 -0700 (PDT) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.8.4/8.8.4) with SMTP id TAA01816; Tue, 22 Jul 1997 19:09:39 +0300 (EEST) Date: Tue, 22 Jul 1997 19:09:38 +0300 (EEST) From: Narvi To: Doug Rabson cc: hackers@freebsd.org Subject: Re: NFS error messgaes: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Doug Rabson wrote: > On Tue, 22 Jul 1997, Narvi wrote: > > > > > This is what I saw with my 2.2-stable: > > > > nfs_bioread: non vmio buf found, discarding > > Don't worry about it. This is just informational. You should only see it > for kernels build with DIAGNOSTIC. Eek. Where did that DIAGNOSTIC sneak into my kernel config file? Got to double check it next time. :-) Sander There is no love, no good, no happiness and no future - all these are just illusions. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 951 1891 > Fax: +44 181 381 1039 > > From owner-freebsd-hackers Tue Jul 22 10:53:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA14675 for hackers-outgoing; Tue, 22 Jul 1997 10:53:28 -0700 (PDT) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA14669 for ; Tue, 22 Jul 1997 10:53:22 -0700 (PDT) Received: from mlor.its.rpi.edu (mlor.its.rpi.edu [128.113.24.92]) by mail1.its.rpi.edu (8.8.5/8.8.5) with SMTP id NAA61314 for ; Tue, 22 Jul 1997 13:53:16 -0400 Received: by mlor.its.rpi.edu (NX5.67f2/NX3.0M) id AA00801; Tue, 22 Jul 97 13:52:48 -0400 Message-Id: <9707221752.AA00801@mlor.its.rpi.edu> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.118.2) From: Garance A Drosehn Date: Tue, 22 Jul 97 13:52:47 -0400 To: freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface Reply-To: gad@eclipse.its.rpi.edu References: Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew Gordon wrote: > On Tue, 22 Jul 1997, Michael Smith wrote: > > David Nugent stands accused of saying: > > > > > Absolutely it is, and the penalty is paid by the non-threaded > > > version, and it makes the code more complex then it need be > > > in any case. The point is whether there is any benefit in > > > making it thread-safe. :-) > > > > Good question. Maybe save worrying about that until it needs > > to be? > > But isn't the time of definition of the API the only chance to > do it cheaply (ie. by having the caller pass in all required > buffers, avoiding the need for static buffers in the library)? First, I have to admit I missed the beginning of this discussion, because I was ignoring mailing lists for about a week or so. On the other hand, I don't intend to keep quiet just because I don't know the details of what I'm talking about... :-) In any case, I agree with Andrew. If you want this to be an attractive solution for a utmp/wtmp interface, then it would be better if the proposed interface at least allows for reentrant versions to be written. I don't think there needs to be much of a penalty to allow for this. On your subroutines, just require a parameter for a buffer area. Include some way that a user-program can find out how large that area must be (at run-time, not compile-time). If the user passes in a NULL for that parameter, have the routines use some static buffer area. That way people who don't care about being thread-safe can still take the easy way out, but at least the interface allows for reentrant versions to be written. Disclaimer: I've done almost nothing for FreeBSD development, but I did spend many years doing systems-programming on a mainframe operating system. From that background, I prefer to write things reentrant, at least as much as possible. I'm not saying that the actual implementation needs to be reentrant, as that will probably run into some practical problems. I'm just saying that the defined interface should allow for reentrant implementations, so that anyone who *needs* to implement a reentrant version (for whatever reason) can do that without defining a new interface. I'm also interested in this topic because we (here at RPI) do work on several unix platforms, and I'd love to see a good interface for utmp/wtmp that could be implemented on all of them. I'm not sure I could help to test that out, because I'm about six months behind in a number of other projects, but I certainly think a good API would be a welcome improvement in the land of unix. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From owner-freebsd-hackers Tue Jul 22 10:57:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA14881 for hackers-outgoing; Tue, 22 Jul 1997 10:57:58 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA14876 for ; Tue, 22 Jul 1997 10:57:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA13607; Tue, 22 Jul 1997 10:53:44 -0700 From: Terry Lambert Message-Id: <199707221753.KAA13607@phaeton.artisoft.com> Subject: Re: Compressed FS To: abial@korin.warman.org.pl (Andrzej Bialecki) Date: Tue, 22 Jul 1997 10:53:44 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Andrzej Bialecki" at Jul 22, 97 11:50:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I see... But I had the impression that unions and portals work pretty well > under -current - I used them several times and they didn't burn the house > down :-) > > Current's LINT file contains information about these FSs being broken. Is > it still true? Yes, especially on creates/appends/writes to unioned files. I believe the portal stuff is actually fairly stable, if not much used. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 11:04:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA15292 for hackers-outgoing; Tue, 22 Jul 1997 11:04:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA15284 for ; Tue, 22 Jul 1997 11:04:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13642; Tue, 22 Jul 1997 11:01:01 -0700 From: Terry Lambert Message-Id: <199707221801.LAA13642@phaeton.artisoft.com> Subject: Re: Compressed FS To: terry@lambert.org (Terry Lambert) Date: Tue, 22 Jul 1997 11:01:01 -0700 (MST) Cc: abial@korin.warman.org.pl, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707220018.RAA12149@phaeton.artisoft.com> from "Terry Lambert" at Jul 21, 97 05:18:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rereading this, it could have been confusing... > > I'm reading the Heidemann's thesis right now (on stackable FS design). He > > mentions that among others they implemented a compression layer. Did > > anyone do something similar under FreeBSD? It would be cool to have it, > > IMHO. > > John has sent the compression code (and some cryptographic code) ^^^^ John Heidemann > layers to severa people, including myself, with the request that > we not redistribute the code without prior permission. > > The BSD layering is such that the VM issues are, in some cases, > hard to overcome (which is why union FS's currently don't work > in the main line tree). Any compression (or cryptographic) FS > would face similar problems, since it would need to maintain > seperate cache data for the uncompressed (or deencrypted) file > blocks. > > Actually, you should check with John: he was working on the ^^^^ John Dyson > union FS code to make it work with the new VM. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 11:09:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA15676 for hackers-outgoing; Tue, 22 Jul 1997 11:09:44 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA15667 for ; Tue, 22 Jul 1997 11:09:41 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id JAA12582; Tue, 22 Jul 1997 09:56:37 -0700 (PDT) Date: Tue, 22 Jul 1997 09:56:36 -0700 (PDT) From: Jaye Mathisen To: David Greenman cc: Jim Dixon , hackers@FreeBSD.ORG Subject: Re: MAX physical memory for FreeBSD ? In-Reply-To: <199707220819.BAA12645@implode.root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hmph. Well, David's the expert. I know I used mine for a newsserver for a while, and didn't have a problem with it, but it was only for a couple days, and a few make worlds. On Tue, 22 Jul 1997, David Greenman wrote: > >Other than setting MAXMEM, and making sure you have the latest pmap.c (I > >think patches) you'd be fine. > > > >I had 512MB in a box, and it worked fine, and I distinctly remember > >somebody on this list with 1GB. > > The machine will boot and may even work with certain loads, but machines > that need lots of networking buffers or other kernel resources will run out > of kernel virtual memory and will need the patches I sent in a previous > message. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-hackers Tue Jul 22 11:14:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16090 for hackers-outgoing; Tue, 22 Jul 1997 11:14:23 -0700 (PDT) Received: from netroplex.com (ns1.netroplex.com [206.171.95.130]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16085 for ; Tue, 22 Jul 1997 11:14:20 -0700 (PDT) Received: from default (hahaha@max008-39.netroplex.com [207.212.27.39]) by netroplex.com (8.8.5/8.8.2) with ESMTP id LAA13305 for ; Tue, 22 Jul 1997 11:14:45 -0700 (PDT) Message-Id: <199707221814.LAA13305@netroplex.com> From: "Rod Ebrahimi" To: Subject: FreeBSD and NT Date: Tue, 22 Jul 1997 11:13:17 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am currently involved in a new Internet Presence Provider establishment and would really like to use FreeBSD on our systems. One of the reasons we are skeptical and would rather use NT is mainly setup time and expertise, most of us working on this project do not know much about Unix (only basic knowledge) but in turn know NT in and out. One of my questions is are you familiar with any people and/or firms that have experts that will help us through our setup in the Southern California area? Also, if we were to run FreeBSD as a e-mail server could we easily add/delete users also specifying their @domain, example: mike@here.com and mike@there.com and John@overthere.com all on this same box? Thank you very much for your time.... Rod Ebrahimi From owner-freebsd-hackers Tue Jul 22 11:22:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16522 for hackers-outgoing; Tue, 22 Jul 1997 11:22:17 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA16501; Tue, 22 Jul 1997 11:22:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13674; Tue, 22 Jul 1997 11:17:04 -0700 From: Terry Lambert Message-Id: <199707221817.LAA13674@phaeton.artisoft.com> Subject: Re: pcireg.h lost children... ? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 22 Jul 1997 11:17:04 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707220226.LAA26105@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 22, 97 11:56:49 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't exactly respect their design decisions; it's just that, > > given a choice between some of the BSD design decisions and the > > Win95 design decisions, I'd pick the Win95 where ever they've made > > tradeoffs in favor of ease of use and BSD hasn't. > > "I don't respect their decisions, except where I respect them". Erk. You are confusing my recognition of a "better than BSD decision" with your assumption that "because it's better than BSD, it's the best possible decision". This is hogwash; I am merely choosing the lesser of two evils any time I point at Microsoft as a model. > > I was actually looking at the draft proposal for the LDAP MIB for > > POSIX systems, the other day. It seems to me that a locally > > maintained LDAP breanch accessed through a local library that > > could go remote if the information wasn't there, and wasn't able > > to try to go remote until the network services were actually up, > > is the correct future direction for UNIX password files, etc.. > > > > And probably this information, as well. > > Yeah. Insert a new network card. See a message saying "waiting for a > network connection so I can get details on this new network card". > Nope. Right. "Nope". Because this is hardly what I was suggesting. I can access a locally stored dbm LDAP database using dbm. I don't have to use a network connection. This type of information, like the credentials necessary to get to the point where the network is up and credentials can be remotely obtained, *must*, by definition, be locally stored. Just so that you're aware, this problem was solved before outside the BSD camp at Novell, when providing NDS-based logons to UnixWare; UnixWare had to be brought up to the point where the net was up before the NDS calls could hope to go remote. This is not a new idea; it's an old idea which has been proven to be workable in a real-world situation. > My initial preference actually would be to load the entire table into > memory during the boot process, pull out the values that match the > installed hardware and ditch the remainder. This naturally wins if > the file containing the table is somewhere tidy like in /boot or on > the hypothetical boot filesystem. Yes; this is probably where it should live. It doesn't really matter, though, so long as it's on the root FS somewhere, since it will be accessed via kernel level file I/O. If it wasn't clear before, I'm not really for an SVR4-style BFS. > Speaking of network drivers; a while back you were blathering about > how we should consider supporting 32-bit NDIS drivers via a module > interface. > > Do you still think this? I spent some time reading what (little) > Microsoft have made public about the new NDIS 5.x spec and TBH it > looks like a monster. Is there an older, saner spec that's worth > perusing anywhere? If you are an MSDN level II developer (or better), there's some sane stuff that was published as part of the DDK DOCS directory that deals with it. My personal preference would be for NDIS 3.x, initially, and an only slightly more recent version for the power management features (specifically, how to make a stack come back up after a power down event). There's *some* stuff on the USU (*.usu.edu) FTP servers, where they keep all the NetWare stuff. Alternately, there is a driver developement kit you can get from Microsoft; they sendit to all the board vendors who want it. Really, the only reason for supporting it is to support new hardware for which we don't want to write drivers. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 11:29:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA17076 for hackers-outgoing; Tue, 22 Jul 1997 11:29:31 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA17070 for ; Tue, 22 Jul 1997 11:29:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA13692; Tue, 22 Jul 1997 11:25:58 -0700 From: Terry Lambert Message-Id: <199707221825.LAA13692@phaeton.artisoft.com> Subject: Re: sendmail complains about being unable to write his pid file To: sthaug@nethelp.no Date: Tue, 22 Jul 1997 11:25:58 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <2688.869556341@verdi.nethelp.no> from "sthaug@nethelp.no" at Jul 22, 97 09:25:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only argument I've heard so far *for* the bin ownership is Terry > Lambert's: There is also the "It's historically BSD" argument. This particular argument seems strong enough to keep us in the dark ages with regard to centralization of system configuration data, and in regard to seperate startup scripts for support of third party application installs/deinstalls without rc file munging. So why isn't the "history" argument good enough here? > > The ability to update machines remotely via NFS, which proxies root > > as "nobody" in most sane configurations. > > But if you export the file systems read-only, you can't perform remote > updates via NFS. This was a seperate suggestion for those people too anal to accept the "Oh, no! They've compromised 'bin' after compromising 'root' on the client machine!" argument. > If you *do* export the file systems read-write, in order > to enable remote updates, you're at the mercy of any machine that can mount > file systems (or guess file handles) from your machine. This is why you have netgroups: so that for all machines but the machine allowed to originate updates, it's read-only; for the machine allowed to originate updates, it's read/write. There are many, many ways to compromise an NFS server machine; not all of them rely on NFS. > In the absence of NFS, having a program owned by root instead of bin may > not be more secure. But it is certainly no *less* secure - if my root > account is cracked then file ownership of bin means nothing anyway. Not true. In order to crack bin, one *must* crack root. There is no way to proxy a bin credential otherwise. On the other hand, root ownership is certainly how SVR4 does it; that should endear the idea to everyone. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 12:10:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20179 for hackers-outgoing; Tue, 22 Jul 1997 12:10:31 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20172 for ; Tue, 22 Jul 1997 12:10:25 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.6/8.8.6) id QAA07522; Tue, 22 Jul 1997 16:10:05 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199707221910.QAA07522@gaia.coppe.ufrj.br> Subject: make world fails in 2.2-STABLE from 97.07.21 To: hackers@freebsd.org Date: Tue, 22 Jul 1997 16:10:05 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Subject says all. This machine is a RELENG2_2 distribution snap from 97.6.28. I'm trying it's first upgrade. Here's the output (partially deleted) of make world: -------------------------------------------------------------- make world started on Tue Jul 22 15:30:38 EST 1997 -------------------------------------------------------------- -------------------------------------------------------------- Making hierarchy -------------------------------------------------------------- cd /usr/cvsup/RELENG_2_2/src && make hierarchy cd /usr/cvsup/RELENG_2_2/src/etc && make distrib-dirs mtree -deU -f /usr/cvsup/RELENG_2_2/src/etc/mtree/BSD.root.dist -p / mtree -deU -f /usr/cvsup/RELENG_2_2/src/etc/mtree/BSD.var.dist -p /var if [ -d /usr/share/locale ] ; then cd /usr/share/locale; for l in da_DK de_AT de_CH de_DE en_AU en_CA en_GB en_US es_ES fi_FI fr_BE fr_CA fr_CH fr_FR is_IS it_CH it_IT nl_BE nl_NL no_NO pt_PT sv_SE ; do if [ -h $l.ISO_8859-1 ]; then rm $l.ISO_8859-1; fi ; done; fi mtree -deU -f /usr/cvsup/RELENG_2_2/src/etc/mtree/BSD.usr.dist -p /usr missing: ./src (not created: File exists) mtree -deU -f /usr/cvsup/RELENG_2_2/src/etc/mtree/BSD.include.dist -p /usr/include cd /; rm -f /sys; ln -s usr/src/sys sys cd /usr/share/locale; set - `cat /usr/cvsup/RELENG_2_2/src/etc/locale.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done cd /usr/share/nls; set - `cat /usr/cvsup/RELENG_2_2/src/etc/locale.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done; rm -rf POSIX; ln -s C POSIX -------------------------------------------------------------- Rebuilding /usr/share/mk -------------------------------------------------------------- cd /usr/cvsup/RELENG_2_2/src && make mk cd /usr/cvsup/RELENG_2_2/src/share/mk && make install cd /usr/cvsup/RELENG_2_2/src/share/mk && install -c -o bin -g bin -m 444 bsd.README bsd.dep.mk bsd.doc.mk bsd.info.mk bsd.kern.mk bsd.kmod.mk bsd.lib.mk bsd.libnames.mk bsd.man.mk bsd.obj.mk bsd.own.mk bsd.port.mk bsd.port.subdir.mk bsd.prog.mk bsd.sgml.mk bsd.subdir.mk sys.mk /usr/share/mk -------------------------------------------------------------- Cleaning up the source tree -------------------------------------------------------------- cd /usr/cvsup/RELENG_2_2/src && make cleandir <<< Removed text >>> -------------------------------------------------------------- Rebuilding the obj tree -------------------------------------------------------------- cd /usr/cvsup/RELENG_2_2/src && make obj <<< Removed text >>> -------------------------------------------------------------- Rebuilding bootstrap tools -------------------------------------------------------------- cd /usr/cvsup/RELENG_2_2/src && make bootstrap cd /usr/cvsup/RELENG_2_2/src/usr.bin/make && make depend && make -DNOINFO -DNOMAN -DNOPROFILE all install cleandir obj <<< make compiled perfectly >>> cd /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall && make depend && make -DNOINFO -DNOMAN -DNOPROFILE all install cleandir obj rm -f .depend mkdep -f .depend -a /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/xinstall.c cc -O2 -m486 -pipe -fexpensive-optimizations -c /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c: In function `flags_to_string': /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:72: `UF_NOUNLINK' undeclared (first use this function) /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:72: (Each undeclared identifier is reported only once /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:72: for each function it appears in.) /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:82: `SF_NOUNLINK' undeclared (first use this function) /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c: In function `string_to_flags': /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:141: `SF_NOUNLINK' undeclared (first use this function) /usr/cvsup/RELENG_2_2/src/usr.bin/xinstall/../../bin/ls/stat_flags.c:150: `UF_NOUNLINK' undeclared (first use this function) *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-hackers Tue Jul 22 12:12:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20333 for hackers-outgoing; Tue, 22 Jul 1997 12:12:16 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20316 for ; Tue, 22 Jul 1997 12:12:13 -0700 (PDT) Received: from earth.mat.net (root@[206.246.122.2]) by cais.cais.com (8.8.5/CJKv1.99-CAIS) with SMTP id PAA11888; Tue, 22 Jul 1997 15:12:11 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id PAA14916; Tue, 22 Jul 1997 15:12:09 -0400 Date: Tue, 22 Jul 1997 15:12:21 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Rod Ebrahimi cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD and NT In-Reply-To: <199707221814.LAA13305@netroplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Rod Ebrahimi wrote: > I am currently involved in a new Internet Presence Provider establishment > and would really like to use FreeBSD on our systems. One of the reasons we > are skeptical and would rather use NT is mainly setup time and expertise, > most of us working on this project do not know much about Unix (only basic > knowledge) but in turn know NT in and out. One of my questions is are you > familiar with any people and/or firms that have experts that will help us > through our setup in the Southern California area? Also, if we were to run > FreeBSD as a e-mail server could we easily add/delete users also specifying > their @domain, example: mike@here.com and mike@there.com and > John@overthere.com all on this same box? > > Thank you very much for your time.... I do some consulting for an ISP here that is so happy with FreeBSD that they're one by one changing out all the Win95 and BSDI systems with FreeBSD, but, for a commercial establishment, unless you're going to do it one box at a time, so you can learn, I sure wouldn't recommend changing to ANY os that you don't have local expertise in. FreeBSD is excellent for your application, but you CAN'T have big failures because you don't have local support. I're recommend either starting with what you know, and adding in FreeBSD as you can stand it, or (better) getting someone local in LA who knows FreeBSD to give you a hand. It's not all that rough to do, and you can learn it, but you don't want to put a new company at risk. > > Rod Ebrahimi > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Tue Jul 22 12:13:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20385 for hackers-outgoing; Tue, 22 Jul 1997 12:13:02 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA20377 for ; Tue, 22 Jul 1997 12:12:58 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id MAA14067; Tue, 22 Jul 1997 12:14:08 -0700 Date: Tue, 22 Jul 1997 12:14:07 -0700 (PDT) From: Alex Belits To: Rod Ebrahimi cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD and NT In-Reply-To: <199707221814.LAA13305@netroplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Rod Ebrahimi wrote: > I am currently involved in a new Internet Presence Provider establishment As I understand it, "Internet Presence Provider" == Internet Service Provider (ISP) that mostly handles HTTP servers, FTP servers, nameservers and mail relaying, but not ISDN lines and plain modem dialins? > and would really like to use FreeBSD on our systems. One of the reasons we > are skeptical and would rather use NT is mainly setup time Even if FreeBSD required more time to install than NT (it doesn't) the choice of the operating system for a large HTTP or mail server that should be running for many years based on its *INSTALLATION TIME* is the most wrong thing, ISP can make. It's like to choose the car closest to the dealer's office because it takes less time to walk to it. > and expertise, > most of us working on this project do not know much about Unix (only basic > knowledge) but in turn know NT in and out. If you are going to use NT for a large web server, I suggest you to choose other kind of business immediately. > One of my questions is are you > familiar with any people and/or firms that have experts that will help us > through our setup in the Southern California area? If you can't do it yourself using the documentation that is supplied with the system you are not qualified to operate an ISP of any size. It's impossible to be as much clueless about system to need someone's help installing it, and then operate a complex network environment that an ISP requires. You need to permanently hire a sysadmin (even the most clueless one, but who knows how to configure network). There are a lot of people who can do this job, but definitely _not_ as one-time installation. Place an ad in some local newspaper, and they will answer immediately. > Also, if we were to run > FreeBSD as a e-mail server could we easily add/delete users also specifying > their @domain, example: mike@here.com and mike@there.com and > John@overthere.com all on this same box? Yes. -- Alex From owner-freebsd-hackers Tue Jul 22 13:14:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA24391 for hackers-outgoing; Tue, 22 Jul 1997 13:14:27 -0700 (PDT) Received: (from jmb@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA24360; Tue, 22 Jul 1997 13:13:48 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199707222013.NAA24360@hub.freebsd.org> Subject: Re: FreeBSD and NT To: info@pagecreators.com (Rod Ebrahimi) Date: Tue, 22 Jul 1997 13:13:42 -0700 (PDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199707221814.LAA13305@netroplex.com> from "Rod Ebrahimi" at Jul 22, 97 11:13:17 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rod Ebrahimi wrote: > > I am currently involved in a new Internet Presence Provider establishment > and would really like to use FreeBSD on our systems. One of the reasons we > are skeptical and would rather use NT is mainly setup time and expertise, > most of us working on this project do not know much about Unix (only basic > knowledge) but in turn know NT in and out. One of my questions is are you > familiar with any people and/or firms that have experts that will help us > through our setup in the Southern California area? Also, if we were to run sigh...shame i am in washington d.c. > FreeBSD as a e-mail server could we easily add/delete users also specifying > their @domain, example: mike@here.com and mike@there.com and > John@overthere.com all on this same box? very easy....sendmail does with a "virtualusertable". here is a little note from the the README file: /usr/src/usr.sbin/sendmail/cf/README virtusertable A domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine. For example, if the virtuser table contained: info@foo.com foo-info info@bar.com bar-info @baz.org jane@elsewhere.net then mail addressed to info@foo.com will be sent to the address foo-info, mail addressed to info@bar.com will be delivered to bar-info, and mail addressed to anyone at baz.org will be sent to jane@elsewhere.net. The username from the original address is passed as %1 allowing: @foo.org %1@elsewhere.com meaning someone@foo.org will be sent to someone@elsewhere.com. All the host names on the left hand side (foo.com, bar.com, and baz.org) must be in $=w. The default map definition is: hash -o /etc/virtusertable A new definition can be specified as the second argument of the FEATURE macro, such as FEATURE(virtusertable, dbm -o /etc/mail/virtusers) jmb -- Jonathan M. Bresler FreeBSD Core Team, Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-hackers Tue Jul 22 13:23:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25114 for hackers-outgoing; Tue, 22 Jul 1997 13:23:47 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA25108 for ; Tue, 22 Jul 1997 13:23:44 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16581 (5.67b/IDA-1.5 for ); Tue, 22 Jul 1997 22:23:41 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id WAA15000; Tue, 22 Jul 1997 22:23:40 +0200 (CEST) X-Face: " Date: Tue, 22 Jul 1997 22:23:38 +0200 From: Stefan Esser To: brianc@pobox.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ccd / scsi References: <19970722114314.26901@milkyway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970722114314.26901@milkyway.com>; from Brian Campbell on Tue, Jul 22, 1997 at 11:43:14AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 22, Brian Campbell wrote: > Does anyone have a suggestion (either positive or negative) for a pair > of quiet, reasonably quick 2G SCSI drives for use with CCD? I'm assuming > identical drives would be preferrable. I have had good luck with my 2GB Atlas, which is more noisy than my (5400RPM) 2GB IBM DORS when idle, but less noisy under high load. The Atlas II is significantly faster, and the 2GB version is currently available for some 540DM (+VAT) over here, which makes me think you should get it for US$310. They doubled capacity per platter compared to the original Atlas by using MR heads ... Power consumption is specified as 7.6W (idle) and 10W seeking. Bonnie results are very good, you better buy an Ultra-SCSI card if you want to connect both drives to the same host- adapter :) There is also a 2GB variant of the Viking, which looks like a follow-on to the Grand-Prix (which was not such a great drive). It got slightly better sustained throughput specs, but I guess I'd rather buy the Atlas II ... Regards, STefan From owner-freebsd-hackers Tue Jul 22 13:24:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25219 for hackers-outgoing; Tue, 22 Jul 1997 13:24:45 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25205 for ; Tue, 22 Jul 1997 13:24:39 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.6/8.8.5) with SMTP id WAA07995; Tue, 22 Jul 1997 22:25:00 +0200 (CEST) Date: Tue, 22 Jul 1997 22:25:00 +0200 (CEST) From: Andrzej Bialecki To: Terry Lambert cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Compressed FS In-Reply-To: <199707221801.LAA13642@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Terry Lambert wrote: > Rereading this, it could have been confusing... Oh, my... It was, indeed. I wouldn't have thought about _both_ of them simultaneously :-) Now I'm reading our vnode(9) manpages coupled with McKusick bible. When I'm through, I'll try to ask some more meaningful questions to John D. Thanks. Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-hackers Tue Jul 22 13:35:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA26270 for hackers-outgoing; Tue, 22 Jul 1997 13:35:51 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA26258 for ; Tue, 22 Jul 1997 13:35:48 -0700 (PDT) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id PAA25974 for freebsd-hackers@FreeBSD.org; Tue, 22 Jul 1997 15:40:11 -0500 (CDT) Message-Id: <199707222040.PAA25974@iworks.InterWorks.org> Date: Tue, 22 Jul 1997 15:40:11 -0500 (CDT) From: "Daniel M. Eischen" To: freebsd-hackers@FreeBSD.org Subject: I2O Spec available Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Found in a wired article http://www.wired.com/news/news/technology/story/5343.html a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 pages in a PDF file. ftp://ftp.i2osig.org/ver1-5.pdf Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Tue Jul 22 13:46:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27151 for hackers-outgoing; Tue, 22 Jul 1997 13:46:19 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA27131 for ; Tue, 22 Jul 1997 13:46:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14032; Tue, 22 Jul 1997 13:41:57 -0700 From: Terry Lambert Message-Id: <199707222041.NAA14032@phaeton.artisoft.com> Subject: Re: FreeBSD and NT To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Tue, 22 Jul 1997 13:41:57 -0700 (MST) Cc: info@pagecreators.com, hackers@FreeBSD.ORG In-Reply-To: from "Alex Belits" at Jul 22, 97 12:14:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I am currently involved in a new Internet Presence Provider establishment > > As I understand it, "Internet Presence Provider" == Internet Service > Provider (ISP) that mostly handles HTTP servers, FTP servers, nameservers > and mail relaying, but not ISDN lines and plain modem dialins? I believe the difference is that a presence provider makes it appear that your company has a permananent internet presence. Generally, this is accomplished by virtual domain hosting; this idea is supported by the email question that he asked. This would provide you with a DNS entry for an FTP server, an HTTP server, and a mail server. Generally, as an IP alias configured for the box, and one or more mail exchanger entries in the DNS, depending on how the mail services were being handled. > > and expertise, > > most of us working on this project do not know much about Unix (only basic > > knowledge) but in turn know NT in and out. > > If you are going to use NT for a large web server, I suggest you to > choose other kind of business immediately. Not necessarily. IIS, despite it's proprietary technology, is relatively robust. Where you will fall down is in using the Microsoft Exchange mail services. The "Internet connector" for SMTP services is not sufficient for virtual domain hosting, since it uses aliases for maildrops instead of true virtual domains. The reason for this is that it attempts to keep a single copy of a mail message with multiple target addresses. If your customer is going to use a POP-lookup product, like qpopper, etc., you will be unable to provide them the ability to fan the mail back out to the local users. Specifically, there is no facility for placing an RFC821 complian "for xxx" component matching the RCPT TO: in the RFC821 exchange, since it wants to keep a single copy of the message. Per user data would interfere with this ability, unless they hired programmers who knew what they were doing. Post.Office has this same problem. Microsoft Exchange is also vanilla SMTP; they do not support the ESMTP "EHLO", or the "ETRN" extension for per domain queue dumping, as in the most recent version of Sendmail. They don't even support the dangerously insecure "TURN" command. Post.Office has this same problem. Post.Office *does* support, as of 3.1, a local ESMTP extension "XREMOTEQUEUE". Unfortunately, this command is not documented anywhere, at least that I have been able to determine. This means that using an NT machine as a Point Of Presence" mail server is not a good idea, in general. > > Also, if we were to run > > FreeBSD as a e-mail server could we easily add/delete users also specifying > > their @domain, example: mike@here.com and mike@there.com and > > John@overthere.com all on this same box? > > Yes. Yes. See the sendmail FAQ on www.sendmail.org; Section 3.7 discusses virtual domain hosting, in detail. If you are planning to have multiple user dialing in via POP, you will need a uniquifier for the mail drop. You will need to handle this via address rewriting. Alternately, you could dump them all into the same mailbox, and have the client support fanning them out to the correct users base on the "Received: ... for " optional header item (which sendmail supports correctly). If they are are calling in and triggering the mail queue dump via ETRN or a hacked fingerd (a common pre-ETRN hack) or via the non-standard XREMOTEQUEUE private extension, well, then you won't have nearly the problems; you'll simply leave the mail in the queue (note: MS Exchange does not have per domain queus any more than it avoids folding multiple messages for a single domain into a single message, so it can't support this without a lot of work). As a final plug (not much of one, since I am looking for work elsewhere right now), my current employer has a product called "XtraMail". It allows clients to call up to a single POP mailbox and download all the mail from a hosted virtual domain and locally fan it out; it's an ESMTP/POP3 server that runs on Windows95 and NT (server and workstation), so at the very least, you will save yourself supporting non-NT/95 clients. Support is probably going to be your biggest issue, anyway. A 60 day demo version (soft upgradeable) is availble from www.artisoft.com. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 14:23:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA29404 for hackers-outgoing; Tue, 22 Jul 1997 14:23:48 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA29384; Tue, 22 Jul 1997 14:23:42 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA19139 (5.67b/IDA-1.5); Tue, 22 Jul 1997 23:23:00 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id XAA17852; Tue, 22 Jul 1997 23:22:02 +0200 (CEST) X-Face: " Date: Tue, 22 Jul 1997 23:22:01 +0200 From: Stefan Esser To: Bruce Evans Cc: hackers@FreeBSD.ORG, luigi@labinfo.iet.unipi.it, multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: snd driver attach routine References: <199707211133.VAA10007@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707211133.VAA10007@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 21, 1997 at 09:33:47PM +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 21, Bruce Evans wrote: > >I could easily change the return type of > >the PCI attach function. Should I ??? > > If anything is attached above the driver level, then you need a status > from the driver attach to decide whether to clean up or attach more. > For ISA, only interrupts are attached at a high level, but they shouldn't > be, so ISA attach function shouldn't need to return status (but they > should clean up if they fail). I'm not sure about PCI. Ok. I'll make the PCI code in -current expect the drivers' attach() functions to return a success indication, but will for now leave the code in 2.2 alone ... Don't know when I'll get around to adding the new PCI probe/attach framework, so don't hold your your breath :) Regards, STefan From owner-freebsd-hackers Tue Jul 22 14:35:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA00243 for hackers-outgoing; Tue, 22 Jul 1997 14:35:29 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00237 for ; Tue, 22 Jul 1997 14:35:24 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id HAA24458; Wed, 23 Jul 1997 07:33:51 +1000 (EST) Date: Wed, 23 Jul 1997 07:33:50 +1000 (EST) From: "Daniel O'Callaghan" To: Terry Lambert cc: Alex Belits , info@pagecreators.com, hackers@FreeBSD.ORG Subject: Re: FreeBSD and NT In-Reply-To: <199707222041.NAA14032@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ On Tue, 22 Jul 1997, Terry Lambert wrote: > Microsoft Exchange is also vanilla SMTP; they do not support > the ESMTP "EHLO", or the "ETRN" extension for per domain queue > dumping, as in the most recent version of Sendmail. They don't > even support the dangerously insecure "TURN" command. > > Post.Office has this same problem. Post.Office *does* support, > as of 3.1, a local ESMTP extension "XREMOTEQUEUE". Unfortunately, > this command is not documented anywhere, at least that I have > been able to determine. > > This means that using an NT machine as a Point Of Presence" mail > server is not a good idea, in general. Another thing, I don't know of a WinNT SMTP agent which allows you to turn off mail relay for non-local domains. i.e. spam@savetrees.com -> someone@somewhere.else. Although non-standard, sendmail does allow this. So if you are happy to act as a relay for cyberpromo, use NT. Danny From owner-freebsd-hackers Tue Jul 22 14:42:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA00734 for hackers-outgoing; Tue, 22 Jul 1997 14:42:13 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00728 for ; Tue, 22 Jul 1997 14:42:09 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA03391; Tue, 22 Jul 1997 14:26:52 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd003388; Tue Jul 22 21:26:42 1997 Message-ID: <33D52523.41C67EA6@whistle.com> Date: Tue, 22 Jul 1997 14:24:51 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Alex Belits CC: Rod Ebrahimi , hackers@FreeBSD.ORG Subject: Re: FreeBSD and NT References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alex Belits wrote: > > On Tue, 22 Jul 1997, Rod Ebrahimi wrote: > > > I am currently involved in a new Internet Presence Provider establishment > [...] excuse alex for a rather less-than-diplomatic answer > > Also, if we were to run > > FreeBSD as a e-mail server could we easily add/delete users also specifying > > their @domain, example: mike@here.com and mike@there.com and that depends on what services you are exporting on behalf of these users.. for mail and web access, (and ftp I think though I've never done it) the answer is yes. > > John@overthere.com all on this same box? > > Yes. > > -- > Alex From owner-freebsd-hackers Tue Jul 22 14:42:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA00750 for hackers-outgoing; Tue, 22 Jul 1997 14:42:16 -0700 (PDT) Received: from labs.usn.blaze.net.au (root@labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00729 for ; Tue, 22 Jul 1997 14:42:11 -0700 (PDT) Received: from labs.usn.blaze.net.au (davidn@local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id HAA00327; Wed, 23 Jul 1997 07:41:00 +1000 (EST) Message-Id: <199707222141.HAA00327@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Andrew Gordon cc: Michael Smith , freebsd-hackers@freebsd.org Subject: Re: utmp/wtmp interface In-reply-to: Your message of "Tue, 22 Jul 1997 17:28:42 +0100." X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 07:41:00 +1000 From: David Nugent Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Absolutely it is, and the penalty is paid by the non-threaded > > > version, and it makes the code more complex then it need be in > > > any case. The point is whether there is any benefit in making it > > > thread-safe. :-) > > > > Good question. Maybe save worrying about that until it needs to be? > > But isn't the time of definition of the API the only chance to do it > cheaply (ie. by having the caller pass in all required buffers, > avoiding the need for static buffers in the library)? Ok, can you suggest an alternative interface which does that, avoids being 'messy' (like avoiding long parameter lists or passing obscure structs etc), isn't going to cause a significant problem with performance, and doesn't come up against limitations if the called-supplied buffer is not large enough? If you missed it, the code being discussed is at http://www.freebsd.org/~davidn/utmpwtmp/libutil-new.tar.gz. I'd be delighted to look at suggested alternatives which are a lot more concrete than suggested based on general principles. Context or unified diffs against that would be wonderful. I said right here (or in -current, don't recall which precisely) after I had started it that I was not happy with memory management, and using a static buffer seemed to be the only way I could do this cleanly without overly-complicating the API itself. This uses static data in precisely the same way that, for example, getpw*() and getgr*(). I don't much like the style of those interfaces either for exactly the reasons we are now discussing, but these are traditional APIs. The difference, however, is that this is libutil, not libc. We don't yet have a libutil_r, and it'd be nice if we could avoid having one at all. > Qpologies if I've missed the point here. No qpologies (sic) necessary. :-) BTW, apologies to Michael for misunderstanding his previous post on this. His suggestion, I realised later, regarding the 'self- describing format' as he calls it, applied to utmp, not wtmp as I had thought at the time. Yes, once we get to it, this wouldn't be a bad way to go, although I still think this would probably be overkill. The point here isn't so much to redefine the file format (now), but to make it possible later. Perhaps some general ideas like these should be raised now so that we can at least allow for possible extensions in the API. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jul 22 14:49:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA01349 for hackers-outgoing; Tue, 22 Jul 1997 14:49:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA01340 for ; Tue, 22 Jul 1997 14:49:17 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA14151; Tue, 22 Jul 1997 14:44:31 -0700 From: Terry Lambert Message-Id: <199707222144.OAA14151@phaeton.artisoft.com> Subject: Re: FreeBSD and NT To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Tue, 22 Jul 1997 14:44:31 -0700 (MST) Cc: terry@lambert.org, abelits@phobos.illtel.denver.co.us, info@pagecreators.com, hackers@FreeBSD.ORG In-Reply-To: from "Daniel O'Callaghan" at Jul 23, 97 07:33:50 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Another thing, I don't know of a WinNT SMTP agent which allows you to > turn off mail relay for non-local domains. i.e. spam@savetrees.com -> > someone@somewhere.else. Although non-standard, sendmail does allow this. > > So if you are happy to act as a relay for cyberpromo, use NT. Post.Office 3.2 and XtraMail 1.1 both have this capability. It is also possible (but a hard configuration) to run sendmail on NT. The configuration is hard because there isn't an M4 for NT. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 15:22:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA02988 for hackers-outgoing; Tue, 22 Jul 1997 15:22:30 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA02948 for ; Tue, 22 Jul 1997 15:20:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA14256; Tue, 22 Jul 1997 15:15:33 -0700 From: Terry Lambert Message-Id: <199707222215.PAA14256@phaeton.artisoft.com> Subject: Re: I2O Spec available To: deischen@iworks.InterWorks.org (Daniel M. Eischen) Date: Tue, 22 Jul 1997 15:15:33 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707222040.PAA25974@iworks.InterWorks.org> from "Daniel M. Eischen" at Jul 22, 97 03:40:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > pages in a PDF file. > > ftp://ftp.i2osig.org/ver1-5.pdf This site no longer accepts anonymous FTP requests. Any chance that someone who got it while it was available could put it up? Did anyone mirror the whole site? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 15:47:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA04354 for hackers-outgoing; Tue, 22 Jul 1997 15:47:58 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA04341 for ; Tue, 22 Jul 1997 15:47:47 -0700 (PDT) Received: from labs.usn.blaze.net.au (davidn@local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id IAA00521; Wed, 23 Jul 1997 08:47:08 +1000 (EST) Message-Id: <199707222247.IAA00521@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: utmp/wtmp interface In-reply-to: Your message of "Tue, 22 Jul 1997 13:27:12 +0930." <199707220357.NAA26773@genesis.atrad.adelaide.edu.au> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 08:47:07 +1000 From: David Nugent Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What I am attempting to do is to define an API to access these > > files, not radically change the format of the files overnight. > > Ok, going back to this. With the xutmpinfo struct; is the plan to > only support one, or a colocated array of several terminated with one > with xi_type set to XUT_NONE? The latter. It is must be an array if it is not NULL. [wtmp] > Actually, I would have suggested a textual format, but I thought that > the screams would be audible from here. If you think it's a goer, you > have my absolute support. Given the space savings, I can't see any reason for it NOT to be text. All but a couple of the fields are text anyway. :) I recently played with a 13mb wtmp which reduced down to 4.8mb when converted to variable-length text (this was a 8-character username system too), which should give you some idea of the potential savings. This will make it harder for things like last(1) to page back through the file from the end, but life is sometimes tough. Besides, last(1) will use the API, which will handle this transparently in any case, including the buffering. > > The point is whether there is any benefit in making it > > thread-safe. :-) > > Good question. Maybe save worrying about that until it needs to be? Well, given the lack of easy alternatives, I did that. :) Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Tue Jul 22 16:09:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA05355 for hackers-outgoing; Tue, 22 Jul 1997 16:09:45 -0700 (PDT) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA05325 for ; Tue, 22 Jul 1997 16:08:43 -0700 (PDT) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.5/8.8.5) with SMTP id TAA11807; Tue, 22 Jul 1997 19:08:54 -0400 (EDT) Date: Tue, 22 Jul 1997 19:08:53 -0400 (EDT) From: "David E. Cross" To: Terry Lambert cc: "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available In-Reply-To: <199707222215.PAA14256@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Terry Lambert wrote: > > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > > pages in a PDF file. > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. > > Any chance that someone who got it while it was available could > put it up? > The site is still up... It has a limit of 10 simultaneous connects though. -- David From owner-freebsd-hackers Tue Jul 22 16:25:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA06171 for hackers-outgoing; Tue, 22 Jul 1997 16:25:59 -0700 (PDT) Received: from aaka.3skel.com (aaka.3skel.com [207.240.134.73]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA06165 for ; Tue, 22 Jul 1997 16:25:55 -0700 (PDT) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by aaka.3skel.com (8.8.5/8.8.2) with ESMTP id TAA26528 for ; Tue, 22 Jul 1997 19:25:52 -0400 (EDT) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by fnur.3skel.com (8.8.5/8.8.2) with ESMTP id TAA19022 for ; Tue, 22 Jul 1997 19:25:51 -0400 (EDT) Message-ID: <33D5417F.F4F213A@3skel.com> Date: Tue, 22 Jul 1997 19:25:51 -0400 From: Dan Janowski Organization: Triskelion Systems, Inc. X-Mailer: Mozilla 4.0b5C (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Re: FreeBSD and NT X-Priority: 3 (Normal) References: <199707222013.NAA24360@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan M. Bresler wrote: > > Rod Ebrahimi wrote: > > > > I am currently involved in a new Internet Presence Provider establishment > virtusertable A domain-specific form of aliasing, allowing multiple > virtual domains to be hosted on one machine. For example, > if the virtuser table contained: > > info@foo.com foo-info > info@bar.com bar-info I currently use this, and it works very well. I wrote a little convenience script that compiles the hash map, but that's about it. Dan -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY From owner-freebsd-hackers Tue Jul 22 16:53:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA07776 for hackers-outgoing; Tue, 22 Jul 1997 16:53:39 -0700 (PDT) Received: from ppp1666.on.sympatico.ca (ppp1654.on.sympatico.ca [206.172.249.118]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA07770 for ; Tue, 22 Jul 1997 16:53:35 -0700 (PDT) Received: from localhost (tim@localhost) by ppp1666.on.sympatico.ca (8.8.5/8.7.3) with SMTP id TAA15867; Tue, 22 Jul 1997 19:51:34 -0400 (EDT) Date: Tue, 22 Jul 1997 19:51:31 -0400 (EDT) From: Tim Vanderhoek Reply-To: ac199@hwcn.org To: Terry Lambert cc: "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available In-Reply-To: <199707222215.PAA14256@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Terry Lambert wrote: > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. Double-check. :) (Maybe you're to well-known, since I'm anonymous enough to connect to it?). -- tIM...HOEk OPTIMIZATION: the process of using many one-letter variables names hoping that the resultant code will run faster. From owner-freebsd-hackers Tue Jul 22 17:01:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA08354 for hackers-outgoing; Tue, 22 Jul 1997 17:01:21 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA08348 for ; Tue, 22 Jul 1997 17:01:13 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA10313; Tue, 22 Jul 1997 16:51:12 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010305; Tue Jul 22 23:51:08 1997 Message-ID: <33D546FC.446B9B3D@whistle.com> Date: Tue, 22 Jul 1997 16:49:16 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available References: <199707222215.PAA14256@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > > pages in a PDF file. > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. > > Any chance that someone who got it while it was available could > put it up? > > Did anyone mirror the whole site? I wasn't quick enough for mirroring the whole site unfortunatly.. wish I'd though of it.. :) > From owner-freebsd-hackers Tue Jul 22 17:13:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09319 for hackers-outgoing; Tue, 22 Jul 1997 17:13:41 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09304 for ; Tue, 22 Jul 1997 17:13:31 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA10978; Tue, 22 Jul 1997 17:08:53 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010974; Wed Jul 23 00:08:49 1997 Message-ID: <33D54B21.794BDF32@whistle.com> Date: Tue, 22 Jul 1997 17:06:57 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert CC: "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available References: <199707222215.PAA14256@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > > pages in a PDF file. > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. > > Any chance that someone who got it while it was available could > put it up? > > Did anyone mirror the whole site? > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. nope it's still wide open ftp> ls -laR rields only this file plus the usual anon setup files. seems to be a sunos system of some sort. Note that the doc is said to be 'incomplete' julian From owner-freebsd-hackers Tue Jul 22 17:16:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09559 for hackers-outgoing; Tue, 22 Jul 1997 17:16:40 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA09546 for ; Tue, 22 Jul 1997 17:16:36 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA14544; Tue, 22 Jul 1997 17:13:10 -0700 From: Terry Lambert Message-Id: <199707230013.RAA14544@phaeton.artisoft.com> Subject: Re: I2O Spec available To: ac199@hwcn.org Date: Tue, 22 Jul 1997 17:13:09 -0700 (MST) Cc: terry@lambert.org, deischen@iworks.InterWorks.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tim Vanderhoek" at Jul 22, 97 07:51:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Tue, 22 Jul 1997, Terry Lambert wrote: > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > > > This site no longer accepts anonymous FTP requests. > > Double-check. :) (Maybe you're to well-known, since I'm anonymous > enough to connect to it?). It let me connect as 10 of 10, but refused login with a refusal which looked like a bad account, not a limitation. In any case, there is nothing else on the site to mirror (which is too bad; getting the mailing lists would have been nice), and I have a copy now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Jul 22 17:20:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA09927 for hackers-outgoing; Tue, 22 Jul 1997 17:20:22 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA09922 for ; Tue, 22 Jul 1997 17:20:19 -0700 (PDT) Received: from localhost (duccini@localhost) by ra.bpsi.net (8.8.5/8.6.9) with SMTP id TAA15853; Tue, 22 Jul 1997 19:17:32 -0500 (CDT) Date: Tue, 22 Jul 1997 19:17:31 -0500 (CDT) From: "David V. Duccini" To: Julian Elischer cc: Terry Lambert , "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available In-Reply-To: <33D546FC.446B9B3D@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Any chance that someone who got it while it was available could > > put it up? > > > > Did anyone mirror the whole site? > > I wasn't quick enough for mirroring the whole site unfortunatly.. > wish I'd though of it.. i'm on right now grabbing it....viola! 20 seconds but i'm browsing through the directories right now...I don't see really anything else worth grabbing/mirroring???? ------------------------------------------------------------------------------- duccini@bpsi.net BackPack Software, Inc. www.backpack.com +1 612.645.7550 voice BPSI Internet Services www.bpsi.net +1 612.645.9798 fax 1.800eMail info@one800.net www.one800.net ------------------------------------------------------------------------------- From owner-freebsd-hackers Tue Jul 22 17:53:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA12073 for hackers-outgoing; Tue, 22 Jul 1997 17:53:58 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA12056 for ; Tue, 22 Jul 1997 17:53:41 -0700 (PDT) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id TAA26552; Tue, 22 Jul 1997 19:58:18 -0500 (CDT) Message-Id: <199707230058.TAA26552@iworks.InterWorks.org> Date: Tue, 22 Jul 1997 19:58:18 -0500 (CDT) From: "Daniel M. Eischen" To: terry@lambert.org Subject: Re: I2O Spec available Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > > pages in a PDF file. > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. > > Any chance that someone who got it while it was available could > put it up? I have it at work and can put it up for a limited time at my anonymous ftp site if it remains a problem connecting ftp.i2osig.org. I see from other e-mails that others have been able to get it. Let me know and I'll put it up tomorrow. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Tue Jul 22 18:11:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA12876 for hackers-outgoing; Tue, 22 Jul 1997 18:11:47 -0700 (PDT) Received: from netroplex.com (ns1.netroplex.com [206.171.95.130]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA12868 for ; Tue, 22 Jul 1997 18:11:44 -0700 (PDT) Received: from default (max008-92.netroplex.com [207.212.27.92]) by netroplex.com (8.8.5/8.8.2) with ESMTP id SAA17951 for ; Tue, 22 Jul 1997 18:12:09 -0700 (PDT) Message-Id: <199707230112.SAA17951@netroplex.com> From: "Rod Ebrahimi" To: Subject: Database Date: Tue, 22 Jul 1997 18:10:53 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While on the subject of NT and FreeBSD, I wanted to address another issue. For management and ease we are looking into developing a database system that will be web based (privately) and enable employees to add/delete/modify users from the comfort of there own browser, which also in turn placed them on the billing list and sent invoices and/or charged Credit Cards on the fly. I would appreciate any information on this matter... Are there any well known Database designers that I should look for? Thank you for your time... Rod From owner-freebsd-hackers Tue Jul 22 18:14:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA13042 for hackers-outgoing; Tue, 22 Jul 1997 18:14:31 -0700 (PDT) Received: from ra.bpsi.net (ra.bpsi.net [199.199.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA13035 for ; Tue, 22 Jul 1997 18:14:19 -0700 (PDT) Received: from localhost (duccini@localhost) by ra.bpsi.net (8.8.5/8.6.9) with SMTP id UAA17429; Tue, 22 Jul 1997 20:11:30 -0500 (CDT) Date: Tue, 22 Jul 1997 20:11:29 -0500 (CDT) From: "David V. Duccini" To: "Daniel M. Eischen" cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available In-Reply-To: <199707230058.TAA26552@iworks.InterWorks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Any chance that someone who got it while it was available could > > put it up? > > I have it at work and can put it up for a limited time at > my anonymous ftp site if it remains a problem connecting > ftp.i2osig.org. I see from other e-mails that others have > been able to get it. i've got it ftp.bpsi.net /pub/i20/ i can put it off of an http server as well ------------------------------------------------------------------------------- duccini@bpsi.net BackPack Software, Inc. www.backpack.com +1 612.645.7550 voice BPSI Internet Services www.bpsi.net +1 612.645.9798 fax 1.800eMail info@one800.net www.one800.net ------------------------------------------------------------------------------- From owner-freebsd-hackers Tue Jul 22 18:27:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA13699 for hackers-outgoing; Tue, 22 Jul 1997 18:27:29 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA13689 for ; Tue, 22 Jul 1997 18:27:24 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id SAA12430 for ; Tue, 22 Jul 1997 18:27:22 -0700 (PDT) Date: Tue, 22 Jul 1997 18:27:22 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Is /usr/src/sys self-contained? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ie, let's say I want to mess around with the DPT driver, but I CVSUP regularly, so I don't want cvsup to wipe out all the good stuff I get when I apply the DPT patches... If I cp -pR /usr/src/sys to /usr/src/sys.DPT, will my kernel builds work right in the /usr/src/sys.DPT directory? Or is there word on when the DPT driver will be integrated into 2.2.2? I just bought one, and am anxious to beat the crap out of it, but I keep my tree pretty up-to-date via CVSUP as well, although I'm not a cvs user by any means. Or is my only option to keep re-applying the damn patch? From owner-freebsd-hackers Tue Jul 22 18:44:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14486 for hackers-outgoing; Tue, 22 Jul 1997 18:44:25 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14453; Tue, 22 Jul 1997 18:44:09 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA04452; Wed, 23 Jul 1997 11:12:40 +0930 (CST) From: Michael Smith Message-Id: <199707230142.LAA04452@genesis.atrad.adelaide.edu.au> Subject: Re: pcireg.h lost children... ? In-Reply-To: <199707221817.LAA13674@phaeton.artisoft.com> from Terry Lambert at "Jul 22, 97 11:17:04 am" To: terry@lambert.org (Terry Lambert) Date: Wed, 23 Jul 1997 11:12:39 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > > I don't exactly respect their design decisions; it's just that, > > > given a choice between some of the BSD design decisions and the > > > Win95 design decisions, I'd pick the Win95 where ever they've made > > > tradeoffs in favor of ease of use and BSD hasn't. > > > > "I don't respect their decisions, except where I respect them". Erk. > > You are confusing my recognition of a "better than BSD decision" > with your assumption that "because it's better than BSD, it's > the best possible decision". You are confusing "respect" and "worship". > > Yeah. Insert a new network card. See a message saying "waiting for a > > network connection so I can get details on this new network card". > > Nope. > > Right. "Nope". Because this is hardly what I was suggesting. I can > access a locally stored dbm LDAP database using dbm. I don't have > to use a network connection. This type of information, like the > credentials necessary to get to the point where the network is up > and credentials can be remotely obtained, *must*, by definition, > be locally stored. ... and by extension about the only thing that's left worth having in the remote database is information for hardware that isn't involved in getting to that stage, ie. soundcards. Not what I'd describe as terribly helpful, no? > Just so that you're aware, this problem was solved before outside > the BSD camp at Novell, when providing NDS-based logons to UnixWare; > UnixWare had to be brought up to the point where the net was up > before the NDS calls could hope to go remote. Accessing user credentials is just ever so _slightly_ different to accessing configuration information for operation-critical hardware. > > Speaking of network drivers; a while back you were blathering about > > how we should consider supporting 32-bit NDIS drivers via a module > > interface. > > > > Do you still think this? I spent some time reading what (little) > > Microsoft have made public about the new NDIS 5.x spec and TBH it > > looks like a monster. Is there an older, saner spec that's worth > > perusing anywhere? > > If you are an MSDN level II developer (or better), there's some > sane stuff that was published as part of the DDK DOCS directory > that deals with it. I am not, as I have repeatedly stated. At this point, I am not willing to - be listed or recognised by Microsoft as a supporter in any way shape or form. - haemorrhage money paying for documentation that is rarely going to be of use. > My personal preference would be for NDIS 3.x, initially, and an > only slightly more recent version for the power management features > (specifically, how to make a stack come back up after a power down > event). My concern is whether NDIS 3.x drivers are likely to be available as a long-term future constant. > There's *some* stuff on the USU (*.usu.edu) FTP servers, where they > keep all the NetWare stuff. Ta. > Alternately, there is a driver developement kit you can get from > Microsoft; they sendit to all the board vendors who want it. As a non-board vendor, how does one qualify for this? > Really, the only reason for supporting it is to support new hardware > for which we don't want to write drivers. ... or can't. This is exactly the reason for doing it. In addition, the reading I've done does actually imply that the architecture is reasonably sane, even if it does offload too much work (IMHO) onto the card. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Jul 22 19:05:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA15711 for hackers-outgoing; Tue, 22 Jul 1997 19:05:20 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15701 for ; Tue, 22 Jul 1997 19:05:15 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id TAA15053; Tue, 22 Jul 1997 19:04:44 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma015049; Tue Jul 22 19:04:30 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id TAA23468; Tue, 22 Jul 1997 19:04:24 -0700 (PDT) From: Archie Cobbs Message-Id: <199707230204.TAA23468@bubba.whistle.com> Subject: Re: cvs commit: src/sys/net rtsock.c In-Reply-To: <9707170044.AA06065@chad.anasazi.com> from "Chad R. Larson" at "Jul 16, 97 05:44:12 pm" To: chad@anasazi.com Date: Tue, 22 Jul 1997 19:04:24 -0700 (PDT) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ this was on -current and -stable mailing lists; moved to -hackers ] > Can you spell lint? I knew that you could... > > If FreBSD's not gonna have a Lint, folks in development mode should turn > on all the compiler warning flags. Make world in the field can be much > less verbose. I agree. The kernel should be compiled with -Wall from now on. Then maybe the warnings will get annoying enough for people to start fixing them (I volunteer to help). Personally, I couldn't function without gcc -Wall... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-freebsd-hackers Tue Jul 22 19:37:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA17704 for hackers-outgoing; Tue, 22 Jul 1997 19:37:18 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA17699 for ; Tue, 22 Jul 1997 19:37:11 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA04985; Wed, 23 Jul 1997 12:06:59 +0930 (CST) From: Michael Smith Message-Id: <199707230236.MAA04985@genesis.atrad.adelaide.edu.au> Subject: Re: Is /usr/src/sys self-contained? In-Reply-To: from Jaye Mathisen at "Jul 22, 97 06:27:22 pm" To: mrcpu@cdsnet.net (Jaye Mathisen) Date: Wed, 23 Jul 1997 12:06:58 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen stands accused of saying: > > ie, let's say I want to mess around with the DPT driver, but I CVSUP > regularly, so I don't want cvsup to wipe out all the good stuff > I get when I apply the DPT patches... > > If I cp -pR /usr/src/sys to /usr/src/sys.DPT, will my kernel builds work > right in the /usr/src/sys.DPT directory? Yes. I have about a dozen kernel source tree scattered around in various degrees of disarray. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Jul 22 20:13:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19463 for hackers-outgoing; Tue, 22 Jul 1997 20:13:29 -0700 (PDT) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19458 for ; Tue, 22 Jul 1997 20:13:26 -0700 (PDT) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.6/8.8.6) with ESMTP id XAA05985; Tue, 22 Jul 1997 23:13:49 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.6/8.8.6) with SMTP id XAA25783; Tue, 22 Jul 1997 23:14:02 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Tue, 22 Jul 1997 23:14:01 -0400 (EDT) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca Reply-To: hoek@hwcn.org To: Rod Ebrahimi cc: hackers@FreeBSD.ORG Subject: Re: Database In-Reply-To: <199707230112.SAA17951@netroplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 22 Jul 1997, Rod Ebrahimi wrote: > While on the subject of NT and FreeBSD, I wanted to address another issue. > For management and ease we are looking into developing a database system > that will be web based (privately) and enable employees to > add/delete/modify users from the comfort of there own browser, which also > in turn placed them on the billing list and sent invoices and/or charged > Credit Cards on the fly. I would appreciate any information on this > matter... Are there any well known Database designers that I should look > for? If you're doing this yourself, you might definately ("might definately" what the heck is that? :) want to at least look into PHP or something else like it. I have a feeling there is a port of it, but if not, see http://www.vex.net/php. [this is a html preprocessor which allows you to add php scripts (fairly straightforward) into your html. It includes support for a number of popular database packages] -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk From owner-freebsd-hackers Tue Jul 22 20:21:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19991 for hackers-outgoing; Tue, 22 Jul 1997 20:21:02 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19981 for ; Tue, 22 Jul 1997 20:20:58 -0700 (PDT) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id WAA26835; Tue, 22 Jul 1997 22:25:41 -0500 (CDT) Message-Id: <199707230325.WAA26835@iworks.InterWorks.org> Date: Tue, 22 Jul 1997 22:25:41 -0500 (CDT) From: "Daniel M. Eischen" To: duccini@bpsi.net Subject: Re: I2O Spec available Cc: freebsd-hackers@FreeBSD.ORG, terry@lambert.org Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I have it at work and can put it up for a limited time at > > my anonymous ftp site if it remains a problem connecting > > ftp.i2osig.org. I see from other e-mails that others have > > been able to get it. > > i've got it ftp.bpsi.net /pub/i20/ I've also got it at: ftp://ftp.pcnet.com/users/eischen/I2O/ver1-5.pdf.gz > i can put it off of an http server as well That would be good :) Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Tue Jul 22 22:11:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA24707 for hackers-outgoing; Tue, 22 Jul 1997 22:11:25 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-195.rdcy01.pacbell.net [206.170.5.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24702 for ; Tue, 22 Jul 1997 22:11:21 -0700 (PDT) Received: from shockwave.com (localhost [127.0.0.1]) by precipice.shockwave.com (8.8.6/8.7.3) with ESMTP id WAA13342 for ; Tue, 22 Jul 1997 22:09:10 -0700 (PDT) Message-Id: <199707230509.WAA13342@precipice.shockwave.com> To: hackers@freebsd.org Subject: how to tell if getchar() will block -- select doesn't cut it Date: Tue, 22 Jul 1997 22:09:10 -0700 From: Paul Traina Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had some fun this week -- I'd added some asynchronous event code to a little line editor so that I could deal with some events while waiting from user input... The code looked something like: > > if (read data available on stdin) { > c = getchar(); > go do more processing; > } > > This worked fine and dandy except that pasting into a window running this > program didn't work properly -- characters seemed to get lost. > > The obvious problem is that the paste was sending down many characters, > stdio read more than one character and stored it in a local buffer, so > there was data available for getchar(), but of course, the low level buffer > had already been slurped in, so the select wasn't returning true. > > I worked around this by checking, in a non-portable fashion, if stdio had > any data available for it (if (fp->_r >= 0 || fp->_ur >= 0)) but quite > frankly, non-portable code sucks. > > I did a reasonable perusal of the source code in stdio and I can't seem > to find any portable way to ask the general question: > > Is getchar() going to block if I call it? > > Ideas? > From owner-freebsd-hackers Tue Jul 22 23:20:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA27266 for hackers-outgoing; Tue, 22 Jul 1997 23:20:00 -0700 (PDT) Received: from precipice.shockwave.com (ppp-206-170-5-195.rdcy01.pacbell.net [206.170.5.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA27258 for ; Tue, 22 Jul 1997 23:19:57 -0700 (PDT) Received: from shockwave.com (localhost [127.0.0.1]) by precipice.shockwave.com (8.8.6/8.7.3) with ESMTP id XAA13468; Tue, 22 Jul 1997 23:17:39 -0700 (PDT) Message-Id: <199707230617.XAA13468@precipice.shockwave.com> To: Marc Slemko cc: hackers@FreeBSD.ORG Subject: Re: how to tell if getchar() will block -- select doesn't cut it In-reply-to: Your message of "Wed, 23 Jul 1997 00:18:40 MDT." Date: Tue, 22 Jul 1997 23:17:39 -0700 From: Paul Traina Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yeah, I had thought of that, however, that means that the whole code-loop is forced to become non-blocking aware. I use that technique in some other places in related code. Thanks for the idea though, Paul From owner-freebsd-hackers Tue Jul 22 23:28:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA27691 for hackers-outgoing; Tue, 22 Jul 1997 23:28:43 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA27686 for ; Tue, 22 Jul 1997 23:28:39 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA22005; Wed, 23 Jul 1997 08:15:22 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.6/8.8.6) id HAA04980; Wed, 23 Jul 1997 07:59:42 +0200 (CEST) Message-ID: <19970723075942.03679@gtn.com> Date: Wed, 23 Jul 1997 07:59:42 +0200 From: Andreas Klemm To: Nate Williams Cc: Warner Losh , Terry Lambert , sthaug@nethelp.no, hackers@FreeBSD.ORG Subject: Re: sendmail complains about being unable to write his pid file References: <199707212106.OAA11898@phaeton.artisoft.com> <199707212214.QAA02162@rocky.mt.sri.com> <19970722073711.20412@gtn.com> <199707221417.IAA04808@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199707221417.IAA04808@rocky.mt.sri.com>; from Nate Williams on Tue, Jul 22, 1997 at 08:17:00AM -0600 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Jul 22, 1997 at 08:17:00AM -0600, Nate Williams wrote: > > > > Files owned by root are harder to change via NFS.... > > > > > > Ahh, you said the dirty word, NFS. NFS stands for 'No Freaking > > > Security', so if you're using NFS, you've already given up any chance of > > > security. > ... > > Or are you arguing, there is no reason to make it any better > > secure, by changing file permissions, because you think it's > > insecure(tm) ?! ;-)) > > Yep. Changing the locks on the back-door of your house while leaving > the front-door wide open is a false sense of security. Well, if the back door is cloced you can concentrate on the front-door ;-) -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-hackers Tue Jul 22 23:37:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA28193 for hackers-outgoing; Tue, 22 Jul 1997 23:37:23 -0700 (PDT) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA28188 for ; Tue, 22 Jul 1997 23:37:19 -0700 (PDT) Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id XAA20188; Tue, 22 Jul 1997 23:37:25 -0700 (PDT) From: Josh MacDonald Message-Id: <199707230637.XAA20188@paris.CS.Berkeley.EDU> To: Paul Traina cc: hackers@freebsd.org Subject: Re: how to tell if getchar() will block -- select doesn't cut it In-reply-to: Your message of "Tue, 22 Jul 1997 23:17:39 PDT." <199707230617.XAA13468@precipice.shockwave.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20181.869639838.1@paris.CS.Berkeley.EDU> Date: Tue, 22 Jul 1997 23:37:20 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's a bad idea to try and use the stdio library while trying to be select() aware in the first place. It's a bad practice to make non- blocking reads when you don't think anything is available because you'll end up spinning with no input available. Then your line editor chews CPU while idle. If I were you I would write the 30 or 40 lines of code that replace stdio's getchar with whatever you need for user input that is integrated with your select event loop. -josh > Yeah, I had thought of that, however, that means that the whole code-loop > is forced to become non-blocking aware. I use that technique in some > other places in related code. > > Thanks for the idea though, > > Paul > From owner-freebsd-hackers Wed Jul 23 00:12:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00463 for hackers-outgoing; Wed, 23 Jul 1997 00:12:59 -0700 (PDT) Received: from acromail.ml.org (acroal.vip.best.com [206.86.222.181]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA00451 for ; Wed, 23 Jul 1997 00:12:53 -0700 (PDT) Received: from localhost (kernel@localhost) by acromail.ml.org (8.8.6/8.8.5) with SMTP id AAA26189; Wed, 23 Jul 1997 00:12:36 -0700 (PDT) Date: Wed, 23 Jul 1997 00:12:36 -0700 (PDT) From: FreeBSD Technical Reader To: Josh MacDonald cc: Paul Traina , hackers@FreeBSD.ORG Subject: Re: how to tell if getchar() will block -- select doesn't cut it In-Reply-To: <199707230637.XAA20188@paris.CS.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Your right about this what I tend to do in this case is nonblocking of file descriptors when opening them thn using fdopen to attach a file pointer to them then i use stdio library only for output (i.e. printf for output and read for input, this gets around the lameness with stdio buffering input especially for interacive stuff where your reading from serial devices becuase you don't want input line buffered but you can use fflush to flush outputs (i don't know of there being a way to force stdio functions i.e. getchar to see everything that has come in on those devices). On Tue, 22 Jul 1997, Josh MacDonald wrote: > It's a bad idea to try and use the stdio library while trying to be > select() aware in the first place. It's a bad practice to make non- > blocking reads when you don't think anything is available because > you'll end up spinning with no input available. Then your line editor > chews CPU while idle. If I were you I would write the 30 or 40 lines of > code that replace stdio's getchar with whatever you need for user input > that is integrated with your select event loop. > > -josh > > > Yeah, I had thought of that, however, that means that the whole code-loop > > is forced to become non-blocking aware. I use that technique in some > > other places in related code. > > > > Thanks for the idea though, > > > > Paul > > > From owner-freebsd-hackers Wed Jul 23 00:32:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA01466 for hackers-outgoing; Wed, 23 Jul 1997 00:32:36 -0700 (PDT) Received: from polya.blah.org (slmel57p24.ozemail.com.au [203.108.203.232]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA01460 for ; Wed, 23 Jul 1997 00:32:31 -0700 (PDT) Received: (from ada@localhost) by polya.blah.org (8.8.6/8.8.5) id RAA18787 for freebsd-hackers@freebsd.org; Wed, 23 Jul 1997 17:32:24 +1000 (EST) From: Ada T Lim Message-Id: <199707230732.RAA18787@polya.blah.org> Subject: Adaptec 1460 To: freebsd-hackers@freebsd.org Date: Wed, 23 Jul 1997 17:32:23 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any support for the 1460B? This card is detected by BSD/OS as being identical to the 1520, except for being on the PCMCIA bus. I am considering buying one of these cards. Ada From owner-freebsd-hackers Wed Jul 23 01:00:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA02618 for hackers-outgoing; Wed, 23 Jul 1997 01:00:20 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA02613 for ; Wed, 23 Jul 1997 01:00:16 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA07932; Wed, 23 Jul 1997 17:29:57 +0930 (CST) From: Michael Smith Message-Id: <199707230759.RAA07932@genesis.atrad.adelaide.edu.au> Subject: Re: Adaptec 1460 In-Reply-To: <199707230732.RAA18787@polya.blah.org> from Ada T Lim at "Jul 23, 97 05:32:23 pm" To: ada@not-enough.bandwidth.org (Ada T Lim) Date: Wed, 23 Jul 1997 17:29:57 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ada T Lim stands accused of saying: > Is there any support for the 1460B? > > This card is detected by BSD/OS as being identical to the 1520, except for > being on the PCMCIA bus. The PAO code should support this, perhaps with a little frobbage. > I am considering buying one of these cards. If you're desperate for SCSI on your notebook, it'll do OK, but not terribly wonderfully. > Ada -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jul 23 01:16:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA03373 for hackers-outgoing; Wed, 23 Jul 1997 01:16:18 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03355; Wed, 23 Jul 1997 01:16:14 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA08097; Wed, 23 Jul 1997 17:44:32 +0930 (CST) From: Michael Smith Message-Id: <199707230814.RAA08097@genesis.atrad.adelaide.edu.au> Subject: Re: polling the status of a dma channel In-Reply-To: <199707221332.PAA22798@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 22, 97 03:32:17 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 23 Jul 1997 17:44:31 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > I came out with the following function which I placed in > /sys/i386/isa/isa.c -- the place I believe it belongs to. > > Maybe we should consider adding this function to isa.c ? It would be > useful for the sound driver and probably other drivers as well. It looks pretty good to me. If there are no objections, I'll commit it tonight... > Cheers -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jul 23 02:25:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA06283 for hackers-outgoing; Wed, 23 Jul 1997 02:25:10 -0700 (PDT) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA06278 for ; Wed, 23 Jul 1997 02:25:03 -0700 (PDT) Received: from sister.ludd.luth.se (gozer@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id LAA09531; Wed, 23 Jul 1997 11:24:54 +0200 Date: Wed, 23 Jul 1997 11:24:47 +0200 (MET DST) From: Johan Larsson To: Terry Lambert cc: "Daniel M. Eischen" , freebsd-hackers@FreeBSD.ORG Subject: Re: I2O Spec available In-Reply-To: <199707222215.PAA14256@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It's now available on ftp://ftp.moon.pp.se/pub/docs/ver1-5.pdf and http://www.moon.pp.se/docs/ ./johan On Tue, 22 Jul 1997, Terry Lambert wrote: > > Found in a wired article http://www.wired.com/news/news/technology/story/5343.html > > a link to a publicly available I2O spec. Haven't yet read the spec - it's 503 > > pages in a PDF file. > > > > ftp://ftp.i2osig.org/ver1-5.pdf > > This site no longer accepts anonymous FTP requests. > > Any chance that someone who got it while it was available could > put it up? > > Did anyone mirror the whole site? > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * finger gozer@mother.ludd.luth.se for more information... +-+-+ * From owner-freebsd-hackers Wed Jul 23 03:04:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA08003 for hackers-outgoing; Wed, 23 Jul 1997 03:04:56 -0700 (PDT) Received: from mail.wup.de (ns.wup.de [149.237.200.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA07995 for ; Wed, 23 Jul 1997 03:04:47 -0700 (PDT) Received: (from root@localhost) by mail.wup.de (8.8.6/8.8.6) id MAA00937; Wed, 23 Jul 1997 12:04:31 +0200 (CEST) Message-ID: <19970723120431.25710@wup.de> Date: Wed, 23 Jul 1997 12:04:31 +0200 From: Andreas Klemm To: hackers@FreeBSD.ORG Subject: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... Reply-To: akl@wup.de, andreas@FreeBSD.ORG, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 X-phone: Wiechers & Partner +49 2173 3964 161 X-fax: Wiechers & Partner +49 2173 3964 222 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi ! Little trouble with our companies FreeBSD www server (2.2-STABLE from about 2 weeks ago). Am about creating a virtual www server. For this purpose I created an IP alias for the interface vx0 vx0: flags=8843 mtu 1500 inet 149.237.200.7 netmask 0xffffff00 broadcast 149.237.200.255 inet 149.237.200.100 netmask 0xffffff00 broadcast 149.237.200.255 inet 149.237.31.7 netmask 0xffffff00 broadcast 149.237.31.255 ether 00:60:97:17:3d:0e lp0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 As you can see, three IP aliases are bound to vx0. And now comes a strange error. Only pings to 149.237.200.100 fail !!! Is there a possible +-1 problem ??? Pings to 149.237.200.7 and 149.237.31.7 are always successfull. Is maybe alias[0] not initialized ??? Andreas /// From owner-freebsd-hackers Wed Jul 23 03:26:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA08808 for hackers-outgoing; Wed, 23 Jul 1997 03:26:42 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA08793; Wed, 23 Jul 1997 03:26:24 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id TAA08506; Wed, 23 Jul 1997 19:55:48 +0930 (CST) From: Michael Smith Message-Id: <199707231025.TAA08506@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... In-Reply-To: <19970723120431.25710@wup.de> from Andreas Klemm at "Jul 23, 97 12:04:31 pm" To: akl@wup.de, andreas@FreeBSD.ORG, hackers@FreeBSD.ORG Date: Wed, 23 Jul 1997 19:55:48 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm stands accused of saying: > > vx0: flags=8843 mtu 1500 > inet 149.237.200.7 netmask 0xffffff00 broadcast 149.237.200.255 > inet 149.237.200.100 netmask 0xffffff00 broadcast 149.237.200.255 Read the handbook, or look at the example in /etc/rc.conf; the second address overlaps the netmask for the first, and as such should be added with a netmask of all ones (255.255.255.255). > Andreas /// -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jul 23 04:12:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA10504 for hackers-outgoing; Wed, 23 Jul 1997 04:12:38 -0700 (PDT) Received: from sunny.wup.de (mail2.wup.de [149.237.200.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA10499 for ; Wed, 23 Jul 1997 04:12:27 -0700 (PDT) Received: (from andreas@localhost) by sunny.wup.de (8.8.6/8.8.6) id NAA01696; Wed, 23 Jul 1997 13:07:56 +0200 (MET DST) Message-ID: <19970723130756.47300@sunny.wup.de> Date: Wed, 23 Jul 1997 13:07:56 +0200 From: Andreas Klemm To: Michael Smith Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... References: <19970723120431.25710@wup.de> <199707231025.TAA08506@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707231025.TAA08506@genesis.atrad.adelaide.edu.au>; from Michael Smith on Wed, Jul 23, 1997 at 07:55:48PM +0930 X-phone: Wiechers & Partner +49 2173 3964 161 X-fax: Wiechers & Partner +49 2173 3964 222 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Jul 23, 1997 at 07:55:48PM +0930, Michael Smith wrote: > Andreas Klemm stands accused of saying: > > > > vx0: flags=8843 mtu 1500 > > inet 149.237.200.7 netmask 0xffffff00 broadcast 149.237.200.255 > > inet 149.237.200.100 netmask 0xffffff00 broadcast 149.237.200.255 > > Read the handbook, or look at the example in /etc/rc.conf; the second > address overlaps the netmask for the first, and as such should be > added with a netmask of all ones (255.255.255.255). Aiiieee ;-) Thanks. Well, I know the usage of IP aliases on sun sparcstations and the entries in /etc/rc.conf look so simple, that it's really easy to overlook that ... Maybe we should add a comment in rc.conf ? -- aklemm@wup.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - From owner-freebsd-hackers Wed Jul 23 04:18:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA10718 for hackers-outgoing; Wed, 23 Jul 1997 04:18:56 -0700 (PDT) Received: from sunny.wup.de (mail2.wup.de [149.237.200.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA10701 for ; Wed, 23 Jul 1997 04:18:44 -0700 (PDT) Received: (from andreas@localhost) by sunny.wup.de (8.8.6/8.8.6) id NAA01766; Wed, 23 Jul 1997 13:14:21 +0200 (MET DST) Message-ID: <19970723131420.57273@sunny.wup.de> Date: Wed, 23 Jul 1997 13:14:20 +0200 From: Andreas Klemm To: Michael Smith Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... References: <19970723120431.25710@wup.de> <199707231025.TAA08506@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707231025.TAA08506@genesis.atrad.adelaide.edu.au>; from Michael Smith on Wed, Jul 23, 1997 at 07:55:48PM +0930 X-phone: Wiechers & Partner +49 2173 3964 161 X-fax: Wiechers & Partner +49 2173 3964 222 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Jul 23, 1997 at 07:55:48PM +0930, Michael Smith wrote: > Andreas Klemm stands accused of saying: > > > > vx0: flags=8843 mtu 1500 > > inet 149.237.200.7 netmask 0xffffff00 broadcast 149.237.200.255 > > inet 149.237.200.100 netmask 0xffffff00 broadcast 149.237.200.255 > > Read the handbook, or look at the example in /etc/rc.conf; the second > address overlaps the netmask for the first, and as such should be > added with a netmask of all ones (255.255.255.255). Hmm, I just noticed, that the broadcast address then looks a bit strange: inet 149.237.200.100 netmask 0xffffffff broadcast 149.237.31.100 Should I then use the following command ifconfig vx0 149.237.200.100 netmask 0xffffffff broadcast 149.237.200.255 alias Or should alias IP adresses not broadcast at all ? Thanks for further information. I hope this is not a RTFM question ;) Andreas /// -- aklemm@wup.de /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ - Support Unix - From owner-freebsd-hackers Wed Jul 23 05:24:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA13592 for hackers-outgoing; Wed, 23 Jul 1997 05:24:26 -0700 (PDT) Received: from mail.ican.net (mail.ican.net [204.92.49.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA13581 for ; Wed, 23 Jul 1997 05:24:21 -0700 (PDT) Received: from oddjob.ican.net (oddjob.ican.net [204.92.49.7]) by mail.ican.net (8.8.6/8.8.6) with ESMTP id IAA19859; Wed, 23 Jul 1997 08:23:50 -0400 (EDT) Received: (from josh@localhost) by oddjob.ican.net (8.8.6/8.8.6) id IAA04207; Wed, 23 Jul 1997 08:24:19 -0400 (EDT) Message-ID: <19970723082419.33054@ican.net> Date: Wed, 23 Jul 1997 08:24:19 -0400 From: Josh Tiefenbach To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Is /usr/src/sys self-contained? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Jaye Mathisen on Tue, Jul 22, 1997 at 06:27:22PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Jul 22, 1997 at 06:27:22PM -0700, Jaye Mathisen wrote: > > > ie, let's say I want to mess around with the DPT driver, but I CVSUP > regularly, so I don't want cvsup to wipe out all the good stuff > I get when I apply the DPT patches... > Just watch it - the latest rev of the DPT driver (1.1.9 i think) goes off and sticks stuff outside of /usr/src/sys. I dont have an exact list handy. josh -- Josh Tiefenbach - Systems Engineer - ACC TelEnterprises - josh@ican.net From owner-freebsd-hackers Wed Jul 23 06:07:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA15565 for hackers-outgoing; Wed, 23 Jul 1997 06:07:16 -0700 (PDT) Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.29.70]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15560 for ; Wed, 23 Jul 1997 06:07:11 -0700 (PDT) Received: from d01lms03.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA28328; Wed, 23 Jul 1997 13:11:44 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU032 id 5010300006145941; Wed, 23 Jul 1997 09:08:02 -0400 From: Stephen Wehr To: Subject: Where is source code for fstat command? Message-Id: <5010300006145941000002L012*@MHS> Date: Wed, 23 Jul 1997 09:08:02 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wanted to get the source code for just the "fstat" command. I was looking in the src directory of the 2.2.2 release, but it's a little hard to divine which file the source for fstat may be in. - Can you point me to the right one? - Will it work to just download this one file without the rest of the package? - How do I unpack the *.a? file? Thanks in advance for your help. -------------------------- Steve Wehr IBM OS/390 OpenEdition Development PRGE/P334, Poughkeepsie, NY USA (914) 435-1099 (IBM tieline) 295-1099 >From VM: IBMUSM10(SWEHR) From Internet: swehr@us.ibm.com From owner-freebsd-hackers Wed Jul 23 06:41:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA17319 for hackers-outgoing; Wed, 23 Jul 1997 06:41:01 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17308 for ; Wed, 23 Jul 1997 06:40:52 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.6/8.7.3) id PAA15360; Wed, 23 Jul 1997 15:40:36 +0200 (MEST) From: Søren Schmidt Message-Id: <199707231340.PAA15360@sos.freebsd.dk> Subject: Re: Where is source code for fstat command? In-Reply-To: <5010300006145941000002L012*@MHS> from Stephen Wehr at "Jul 23, 97 09:08:02 am" To: swehr@us.ibm.com (Stephen Wehr) Date: Wed, 23 Jul 1997 15:40:36 +0200 (MEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Stephen Wehr who wrote: > I wanted to get the source code for just the "fstat" command. > I was looking in the src directory of the 2.2.2 release, but it's > a little hard to divine which file the source for fstat may be in. > > - Can you point me to the right one? sos> whereis fstat fstat: /usr/bin/fstat /usr/share/man/man1/fstat.1.gz /usr/src/usr.bin/fstat sos> > - Will it work to just download this one file without the rest > of the package? Depends, fstat.c and the Makefile should do it.. > - How do I unpack the *.a? file? Erhm you mean the distribution files ?? Try the install.sh script in the directory from where you get the source distribution... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Wed Jul 23 07:11:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA19129 for hackers-outgoing; Wed, 23 Jul 1997 07:11:08 -0700 (PDT) Received: from relay1.cit.ru (relay1.cit.ru [193.125.82.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA19081 for ; Wed, 23 Jul 1997 07:10:28 -0700 (PDT) Received: from free.tula.su by relay1.cit.ru with UUCP id SAA26581; (8.8.2-MVC-141196/vak/1.9) Wed, 23 Jul 1997 18:05:12 +0400 (MSD) Received: from blik.UUCP by free.tula.su with UUCP id RAA14322; (8.8.5-MVC-230497/vak/1.9) 9b Received: by blik.samara.su id AA07475 (5.65/IDA-simtel for hackers@freebsd.org); Wed, 23 Jul 1997 19:43:59 +0500 To: hackers@freebsd.org Message-Id: Organization: Center of Information Technology From: "Igor" Date: Wed, 23 Jul 97 19:43:59 +0500 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: kernel debugging Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I starting DDB and set breakpoint to rt_xaddrs $ b rt_xaddrs $ c then I do # route delete xxx.xxx.xxx. then DDB say's: Breakpoint at rt_addrs I do $ trace and receive _rt_xaddrs(...) at _rt_xaddrs _route_output(...) at _route_output _raw_usrreq(...) at _raw_usrreq ..... _syscall(...) at _syscall Bad user frame pointer: 0xXXXXXX ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Why I receive this ? Then I want make kernel core dump and I do (in DDB) $ panic 2. What another way making kernel dump ? Then I do (after restart my PC) # gdb -k -s /kernel.gdb -e ... -c ... gdb> bt ... rt_xaddr(...) raw_usrreq(...) ... gdb> 3. Why I can't see route_output in steck ? --- igor@blik.samara.su (Igor) From owner-freebsd-hackers Wed Jul 23 07:16:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA19411 for hackers-outgoing; Wed, 23 Jul 1997 07:16:00 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA19392 for ; Wed, 23 Jul 1997 07:15:55 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id XAA09392; Wed, 23 Jul 1997 23:44:36 +0930 (CST) From: Michael Smith Message-Id: <199707231414.XAA09392@genesis.atrad.adelaide.edu.au> Subject: Re: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... In-Reply-To: <19970723131420.57273@sunny.wup.de> from Andreas Klemm at "Jul 23, 97 01:14:20 pm" To: andreas@sunny.wup.de (Andreas Klemm) Date: Wed, 23 Jul 1997 23:44:36 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm stands accused of saying: > > Hmm, I just noticed, that the broadcast address then looks a bit > strange: > inet 149.237.200.100 netmask 0xffffffff broadcast 149.237.31.100 > > Should I then use the following command > > ifconfig vx0 149.237.200.100 netmask 0xffffffff broadcast 149.237.200.255 alias > > Or should alias IP adresses not broadcast at all ? As far as I can tell, the broadcast attached to aliases is never used. > Thanks for further information. I hope this is not a RTFM question ;) It _should_ be. If it's not, you had better contribute to TFM! -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Jul 23 08:03:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA22476 for hackers-outgoing; Wed, 23 Jul 1997 08:03:01 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22453; Wed, 23 Jul 1997 08:02:54 -0700 (PDT) Received: from 166.72.151.198 (slip166-72-151-198.nd.us.ibm.net [166.72.151.198]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id PAA52760; Wed, 23 Jul 1997 15:02:49 GMT Message-ID: <33D61D15.AA791100@ibm.net> Date: Wed, 23 Jul 1997 10:02:47 -0500 From: Jay Erickson Reply-To: Jay.Erickson@ibm.net Organization: Life X-Mailer: Mozilla 4.01 (Macintosh; I; 68K) MIME-Version: 1.0 To: "questions@FreeBSD.ORG" , hardware@FreeBSD.ORG, hackers@FreeBSD.ORG, scsi@FreeBSD.ORG CC: Mark Dawson , brian@ibm.net, Tao@gate.sinica.ed Subject: Compaq's Built in SCSI X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I searched the archives and didn't find a definitive answer. I want to install FreeBSD on a couple of Compaq Proliant 1000's with the built in SCSI controller or Compaq's Smart SCSI controller. The Installer kernel doesn't seem to recognize either. Please help give me some driver help or at least point me in the right direction. TIA Jay.Erickson@IBM.net erickson@Nserver.grandforks.af.mil <-- My reliable FreeBSD box From owner-freebsd-hackers Wed Jul 23 08:39:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25121 for hackers-outgoing; Wed, 23 Jul 1997 08:39:46 -0700 (PDT) Received: from bacchus.eng.umd.edu (bacchus.eng.umd.edu [129.2.94.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25110 for ; Wed, 23 Jul 1997 08:39:42 -0700 (PDT) Received: from [10.0.0.4] (annex13-29.dial.umd.edu [128.8.24.29]) by bacchus.eng.umd.edu (8.8.5/8.8.5) with ESMTP id LAA02739; Wed, 23 Jul 1997 11:39:32 -0400 (EDT) X-Sender: crb@bacchus.eng.umd.edu Message-Id: In-Reply-To: <199707230313.UAA19474@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Jul 1997 11:39:16 -0400 To: hackers@FreeBSD.ORG From: "Christopher R. Bowman" Subject: Re: hackers-digest V3 #276 Cc: brianc@milkyway.com Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >hackers-digest Tuesday, 22 July 1997 Volume 03 : Number 276 > >From: Brian Campbell >Date: Tue, 22 Jul 1997 11:43:14 -0400 >Subject: ccd / scsi > >Does anyone have a suggestion (either positive or negative) for a pair >of quiet, reasonably quick 2G SCSI drives for use with CCD? I'm assuming >identical drives would be preferrable. > I can't really recommend drives for ccd configurations, since I don't run one, but I have had 0 problems with my IBM UltraStar 2ES Ultra-Fast drive and at $350 it's a pretty good deal. I haven't got 40 MB transfers going becauase either the 53c875 driver doesn't support them or I haven't gotten it configured right, but I have been happy with it. --------- Christopher R. Bowman crb@eng.umd.edu My home page From owner-freebsd-hackers Wed Jul 23 08:50:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25851 for hackers-outgoing; Wed, 23 Jul 1997 08:50:37 -0700 (PDT) Received: from hotpoint.dcs.qmw.ac.uk (hotpoint.dcs.qmw.ac.uk [138.37.88.162]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25813; Wed, 23 Jul 1997 08:50:25 -0700 (PDT) Received: from md@ruby.dcs.qmw.ac.uk [138.37.88.139]; by hotpoint.dcs.qmw.ac.uk (8.8.6/8.8.5/S-4.0) with ESMTP; id QAA01629; Wed, 23 Jul 1997 16:50:01 +0100 (BST) Received: from md@localhost; by ruby.dcs.qmw.ac.uk (8.8.4/8.8.4/C-3.2); id QAA02371; Wed, 23 Jul 1997 16:50:00 +0100 (BST) Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.ruby.cs.qmw.ac.uk.sun4.41 via MS.5.6.ruby.cs.qmw.ac.uk.sun4_41; Wed, 23 Jul 1997 16:49:59 +0100 (BST) Message-ID: Date: Wed, 23 Jul 1997 16:49:59 +0100 (BST) From: Mark Dawson To: "questions@FreeBSD.ORG" , hardware@FreeBSD.ORG, hackers@FreeBSD.ORG, scsi@FreeBSD.ORG, Jay.Erickson@ibm.net Subject: Re: Compaq's Built in SCSI CC: brian@ibm.net, Tao@gate.sinica.ed In-Reply-To: <33D61D15.AA791100@ibm.net> References: <33D61D15.AA791100@ibm.net> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I want to install FreeBSD on a couple of Compaq Proliant 1000's with the > built in SCSI controller or Compaq's Smart SCSI controller. The > Installer kernel doesn't seem to recognize either. See for a boot floppy image and a kernel for FreeBSD-2.2.2 that should recognise the Smart and Smart-2 controllers on your Compaq box. Please see the README at the above location for further details and let me know how you get on as its not been tested on a ProLiant 1000 before. Regards, Mark From owner-freebsd-hackers Wed Jul 23 09:22:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27857 for hackers-outgoing; Wed, 23 Jul 1997 09:22:48 -0700 (PDT) Received: from main.gbdata.com (USR1-1.detnet.com [207.113.12.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27852; Wed, 23 Jul 1997 09:22:41 -0700 (PDT) Received: (from gclarkii@localhost) by main.gbdata.com (8.8.5/8.8.5) id LAA00741; Wed, 23 Jul 1997 11:22:04 -0500 (CDT) From: Gary Clark II Message-Id: <199707231622.LAA00741@main.gbdata.com> Subject: Re: FreeBSD 2.2, ping to an ip alias for interface vx0 fails ... To: akl@wup.de, andreas@FreeBSD.ORG, hackers@FreeBSD.ORG Date: Wed, 23 Jul 1997 11:22:04 -0500 (CDT) In-Reply-To: <19970723120431.25710@wup.de> from Andreas Klemm at "Jul 23, 97 12:04:31 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm wrote: > Hi ! > > Little trouble with our companies FreeBSD www server (2.2-STABLE > from about 2 weeks ago). > > Am about creating a virtual www server. > > For this purpose I created an IP alias for the interface vx0 > > vx0: flags=8843 mtu 1500 > inet 149.237.200.7 netmask 0xffffff00 broadcast 149.237.200.255 > inet 149.237.200.100 netmask 0xffffff00 broadcast 149.237.200.255 ^^^^^^^^ Set this netmask to 255.255.255.255. The config on a sub net gets the standard netmask. All ifconfigs thereafter get all 1s... > inet 149.237.31.7 netmask 0xffffff00 broadcast 149.237.31.255 > ether 00:60:97:17:3d:0e > lp0: flags=8810 mtu 1500 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > As you can see, three IP aliases are bound to vx0. > > And now comes a strange error. Only pings to 149.237.200.100 > fail !!! Is there a possible +-1 problem ??? > > Pings to 149.237.200.7 and 149.237.31.7 are always successfull. > > Is maybe alias[0] not initialized ??? > > Andreas /// > Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups - http://WWW.GBData.com for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/FAQ.latin1 From owner-freebsd-hackers Wed Jul 23 09:52:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29435 for hackers-outgoing; Wed, 23 Jul 1997 09:52:30 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29430 for ; Wed, 23 Jul 1997 09:52:25 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id JAA13253; Wed, 23 Jul 1997 09:52:23 -0700 (PDT) Date: Wed, 23 Jul 1997 09:52:23 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org cc: cts@cdsnet.net Subject: More MMAP troubls (non-INN). Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Using the _seq unique ID stuff in msql, we are seeing corrupted databases with duplicated rows, just plain garbage, and other anomalies. It's acting as if some modification to an mmap'd page is getting lost somewhere. This is under a version of FreeBSD from around January. Will upgrade and see if it still happens. I'm pretty suspicious of our mmap. Is there some kind of a test suite out on the net? From owner-freebsd-hackers Wed Jul 23 10:31:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA01681 for hackers-outgoing; Wed, 23 Jul 1997 10:31:13 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA01670 for ; Wed, 23 Jul 1997 10:31:06 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id TAA02343 for ; Wed, 23 Jul 1997 19:31:41 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id TAA07666 for freebsd-hackers@freefall.cdrom.com; Wed, 23 Jul 1997 19:31:05 +0200 (MEST) Date: Wed, 23 Jul 1997 19:31:05 +0200 (MEST) From: Christoph Kukulies Message-Id: <199707231731.TAA07666@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: cvs and NIS - problem Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I don't want to make a problem report out of it at the moment without having discussed this in the list: A user came to me today who is maintaing his whole stuff, projects, thesis and such using cvs - not a bad idea as such. And during investigating his problem I came to the conclusion that there might be some NIS/yp problem. I created a directory /a/kuku/cvsroot on hub.freebsd.org, imported a tree as a new project, and did a checkout on hub having set my CVSROOT variable to /a/kuku/cvsroot. Now I went to my local machine (gil) and set my CVSROOT variable to :ext:kuku@hub.freebsd.org:/a/kuku/cvsroot and did a cvs checkout test I got: gil> cvs checkout test cvs server: Updating test U test/test.c gil> Fine. Now I do the same on my NIS machine (the NIS server): toots> cvs checkout test cvs [checkout aborted]: unknown access method: ext toots> (this appears very quickly after launching the command so I assume it is a decision taken by the client locally) What's this? A NIS problem? I browsed the cvs source (contrib) but didn't find a source location that matched the message exactly though it must be something with the server access method in client.c I suspect. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Jul 23 11:06:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03807 for hackers-outgoing; Wed, 23 Jul 1997 11:06:47 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03777; Wed, 23 Jul 1997 11:06:37 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id LAA26238; Wed, 23 Jul 1997 11:06:33 -0700 (PDT) Date: Wed, 23 Jul 1997 11:06:30 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org cc: current@freebsd.org Subject: -current report. :) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I took the plunge, and upgraded my crash-ridden 2.2.2 INN newsserver to 3.0-current as of 7/19, and it's been solid as the proverbial rock for a few days now. Operations that would crash it instantly (or within a couple minutes), now work just yippee-skippee. Not actually suggesting that anybody do it, but for my purposes, it fixed a lot of problems. One other thing I noticed: My de0 interface would report a few errors/hour connected to my LinkSwitch 3000 100MB switch. Under 3.0, 0. SO it's either not reporting them, or whatever was wrong is fixed. Either way, a big old fat zero in the error column gives me a nice false sense of security. :) From owner-freebsd-hackers Wed Jul 23 11:11:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04077 for hackers-outgoing; Wed, 23 Jul 1997 11:11:02 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04071 for ; Wed, 23 Jul 1997 11:10:58 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA24892; Wed, 23 Jul 1997 12:10:00 -0600 (MDT) Message-Id: <199707231810.MAA24892@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jaye Mathisen cc: hackers@FreeBSD.ORG Subject: Re: Is /usr/src/sys self-contained? In-reply-to: Your message of "Tue, 22 Jul 1997 18:27:22 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 12:09:59 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Or is there word on when the DPT driver will be integrated into 2.2.2? This is getting real close. It should happen by Saturday. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Wed Jul 23 11:55:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06826 for hackers-outgoing; Wed, 23 Jul 1997 11:55:10 -0700 (PDT) Received: from sinbin.demos.su (sinbin.demos.su [194.87.0.31]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06820 for ; Wed, 23 Jul 1997 11:55:07 -0700 (PDT) Received: from skraldespand.demos.su by sinbin.demos.su with ESMTP id WAA22448; (8.6.12/D) Wed, 23 Jul 1997 22:54:00 +0400 Received: by skraldespand.demos.su id WAA18055; (8.8.5/D) Wed, 23 Jul 1997 22:54:57 +0400 (MSD) Message-ID: <19970723225457.31854@skraldespand.demos.su> Date: Wed, 23 Jul 1997 22:54:57 +0400 From: "Mikhail A. Sokolov" To: hackers@freebsd.org Subject: 0508-RELENG(2.2)/ahc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.75 Organization: Demos Company, Ltd., Moscow, Russian Federation. X-Point-of-View: Gravity is myth, - the earth sucks. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, forgive me, but what did this mean? The environment is 2.2-0508-RELENG, all the possible ahc options are off, Adaptec 3940UW.. ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 8 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 7 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 6 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 5 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 4 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 3 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 2 ahc0: WARNING no command for scb 1 (cmdcmplt) QOUTCNT == 1 Should be 0, but luckily, nothing happened then ;) From owner-freebsd-hackers Wed Jul 23 13:35:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12501 for hackers-outgoing; Wed, 23 Jul 1997 13:35:17 -0700 (PDT) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12496 for ; Wed, 23 Jul 1997 13:35:15 -0700 (PDT) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id NAA23159 for ; Wed, 23 Jul 1997 13:35:12 -0700 (PDT) Message-Id: <3.0.32.19970723133643.01019c80@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 23 Jul 1997 13:36:44 -0700 To: freebsd-hackers@freebsd.org From: Ian Kallen Subject: mkisofs with long file names? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I tried adding the -l in the mkisofs line of Jordans lil makecdfs.sh script to gain retention of long file names. I want to burn a bunch of html onto a CD and 8.3 just won't work. DOS compatibility be damned, mkisofs still truncates the filenames and that just won't do. Suggestions? The machine I installed the cdr to is running 2.2-970618-RELENG. thanks! -Ian -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Wed Jul 23 13:36:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12631 for hackers-outgoing; Wed, 23 Jul 1997 13:36:44 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12625; Wed, 23 Jul 1997 13:36:42 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id QAA06158; Wed, 23 Jul 1997 16:36:40 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id QAA11299; Wed, 23 Jul 1997 16:36:39 -0400 (EDT) To: Jaye Mathisen cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: -current report. :) In-reply-to: Your message of "Wed, 23 Jul 1997 11:06:30 PDT." Date: Wed, 23 Jul 1997 16:36:39 -0400 Message-ID: <11297.869690199@orion.webspan.net> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen wrote in message ID : > Well, I took the plunge, and upgraded my crash-ridden 2.2.2 INN newsserver > to 3.0-current as of 7/19, and it's been solid as the proverbial rock > for a few days now. > Operations that would crash it instantly (or within a couple minutes), now > work just yippee-skippee. (sorry if this has been asked before, but I don't remember) what operations would they be? newgroup/rmgroup? Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-hackers Wed Jul 23 14:54:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17372 for hackers-outgoing; Wed, 23 Jul 1997 14:54:51 -0700 (PDT) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA17367 for ; Wed, 23 Jul 1997 14:54:44 -0700 (PDT) Received: from milo.lodgenet.com (milo.lodgenet.com [10.0.11.51]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id QAA09913; Wed, 23 Jul 1997 16:54:05 -0500 Received: from milo.lodgenet.com (localhost [127.0.0.1]) by milo.lodgenet.com (8.8.5/8.8.5) with ESMTP id QAA08794; Wed, 23 Jul 1997 16:53:36 -0500 (CDT) Message-Id: <199707232153.QAA08794@milo.lodgenet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Ian Kallen cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mkisofs with long file names? In-reply-to: Your message of "Wed, 23 Jul 1997 13:36:44 PDT." <3.0.32.19970723133643.01019c80@mail.gamespot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 16:53:36 -0500 From: John Prince Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What options are you using with mkisofs?? Where do the source file(s) currently live? --John Ian Kallen writes: > I tried adding the -l in the mkisofs line of Jordans lil makecdfs.sh script > to gain retention of long file names. I want to burn a bunch of html onto > a CD and 8.3 just won't work. DOS compatibility be damned, mkisofs still > truncates the filenames and that just won't do. Suggestions? The machine > I installed the cdr to is running 2.2-970618-RELENG. > > thanks! > -Ian > > -- > Ian Kallen ian@gamespot.com > Director of Technology and Web Administration > SpotMedia Communications > http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Wed Jul 23 16:16:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA22006 for hackers-outgoing; Wed, 23 Jul 1997 16:16:49 -0700 (PDT) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA22000 for ; Wed, 23 Jul 1997 16:16:46 -0700 (PDT) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id QAA10162 for hackers@freebsd.org; Wed, 23 Jul 1997 16:15:03 -0700 (PDT) Date: Wed, 23 Jul 1997 16:15:03 -0700 (PDT) From: Jim Shankland Message-Id: <199707232315.QAA10162@biggusdiskus.flyingfox.com> To: hackers@freebsd.org Subject: getting physically contiguous memory in the kernel Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there an easy way to get physically contiguous memory in the FreeBSD kernel? The de driver calls malloc() to obtain a buffer, part of which must be physically contiguous; this buffer has now grown to be > 4K, causing the transmit descriptors to span a page boundary. When the 2 pages are not physically contiguous, the driver breaks. For now, I've workes around this by malloc-ing the transmit and receive descriptor arrays separately; this should work, as they're individually less than 4KB. But is there a better way? Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-hackers Wed Jul 23 16:19:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA22132 for hackers-outgoing; Wed, 23 Jul 1997 16:19:21 -0700 (PDT) Received: from grendel.IAEhv.nl (grendel.IAEhv.nl [194.151.72.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA22122 for ; Wed, 23 Jul 1997 16:19:13 -0700 (PDT) Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id XAA00586; Wed, 23 Jul 1997 23:45:17 +0200 (CEST) Message-ID: <19970723234517.04842@grendel.IAEhv.nl> Date: Wed, 23 Jul 1997 23:45:17 +0200 From: Peter Korsten To: hackers@FreeBSD.ORG Subject: Re: Database References: <199707230112.SAA17951@netroplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <199707230112.SAA17951@netroplex.com>; from Rod Ebrahimi on Tue, Jul 22, 1997 at 06:10:53PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Rod Ebrahimi shared with us: > While on the subject of NT and FreeBSD, I wanted to address another issue. > For management and ease we are looking into developing a database system > that will be web based (privately) and enable employees to > add/delete/modify users from the comfort of there own browser, which also > in turn placed them on the billing list and sent invoices and/or charged > Credit Cards on the fly. I would appreciate any information on this > matter... Are there any well known Database designers that I should look > for? At work, we've been implementing web-based databases both on Unix's and NT. For Unix, we have out own application that roughly does the same thing as w3msql (a frontend for mSQL), but has some nice extra features like sub-sub-sub-...-queries, if-then-else statements and calling other applications. For NT, we used Internet Database Connectivity, which is a part of Internet Information Server, and thus, it's for free. You can connect it to any database that speaks ODBC. It's very simple to use, be it with some limitations. Conditional code is very limited and due to the solution with two files, an .idc file and a .htx file (which does have it's avantages), I haven't figured out yet whether sub-queries (using the result of one query in the next) are possible. There's also dbWeb from Microsoft, but that's something like FrontPage and I advise against it. I don't think it's reliable, and apart from that, it's too limited. Anyway, IDC is about your browser talking to a database, so your invoices should be run from the database application. But we're implementing a very big site with IIS, IDC and MS-SQL at the moment. With some thinking, most of your problems can be solved with it. We use CGI-programs for the rest, which work exactly the same way as with Unix (to build platform-indepent code, you just need an '#ifdef' around some '#include's). Our own Unix program (which we will port to NT, of course) will develop into something far more sophisticated, though. - Peter From owner-freebsd-hackers Wed Jul 23 17:00:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24380 for hackers-outgoing; Wed, 23 Jul 1997 17:00:16 -0700 (PDT) Received: from odin.visigenic.com (odin.visigenic.com [204.179.98.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24346 for ; Wed, 23 Jul 1997 17:00:04 -0700 (PDT) Received: from VSI48 (vsi48.visigenic.com [206.64.15.185]) by odin.visigenic.com (Netscape Mail Server v2.02) with SMTP id AAA6266 for ; Wed, 23 Jul 1997 16:58:38 -0700 Message-Id: <3.0.2.32.19970723170040.00947be0@mailhost> X-Sender: toneil@mailhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 23 Jul 1997 17:00:40 -0700 To: hackers@FreeBSD.ORG From: "Tim Oneil" Subject: smp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Would some one mind directing me to a web source(s) that has specs and whatnot on SMP? I need to study the issues involving this stuff. Thanks. From owner-freebsd-hackers Wed Jul 23 18:03:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27628 for hackers-outgoing; Wed, 23 Jul 1997 18:03:11 -0700 (PDT) Received: from pop01.netaddress.usa.net ([204.68.24.132]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA27623 for ; Wed, 23 Jul 1997 18:03:07 -0700 (PDT) From: chris.moran@usa.net Received: (qmail 12362 invoked by uid 0); 24 Jul 1997 01:03:05 -0000 Received: from 131.107.3.24 by www01 via web-mailer (2.1) on Wed, 23 Jul 1997 19:02:42 Message-ID: Date: Wed, 23 Jul 1997 19:02:42 To: hackers@freebsd.org Subject: Dynamic DNS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anybody working on such a beast for FreeBSD? From owner-freebsd-hackers Wed Jul 23 18:04:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27699 for hackers-outgoing; Wed, 23 Jul 1997 18:04:34 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27694 for ; Wed, 23 Jul 1997 18:04:30 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id DAA23941 for hackers@freebsd.org; Thu, 24 Jul 1997 03:08:27 +0200 (CEST) From: Mikael Karpberg Message-Id: <199707240108.DAA23941@ocean.campus.luth.se> Subject: Missing binaries in 2.2.2? To: hackers@freebsd.org Date: Thu, 24 Jul 1997 03:08:26 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I was waiting for a compile to finish, and thought I'd try and make it beep me when done, so I though "There has to be a wait command, right?" and did "man wait" and yes, there was. Great! To the prompt! karpen> wait 222 ; echo ^G wait: Too many arguments. karpen> where wait wait is a shell built-in command karpen> locate wait [... long list or man pages, etc ...] karpen> locate bin/wait karpen> mail hackers@freebsd.org ;-) Er... Anybody seen a lost wait command?! :-) /Mikael From owner-freebsd-hackers Wed Jul 23 18:57:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA29712 for hackers-outgoing; Wed, 23 Jul 1997 18:57:34 -0700 (PDT) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA29707 for ; Wed, 23 Jul 1997 18:57:32 -0700 (PDT) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA16232; Wed, 23 Jul 1997 18:57:33 -0700 Date: Wed, 23 Jul 1997 18:57:33 -0700 (PDT) From: "Brian N. Handy" To: Mikael Karpberg Cc: hackers@FreeBSD.ORG Subject: Re: Missing binaries in 2.2.2? In-Reply-To: <199707240108.DAA23941@ocean.campus.luth.se> Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Er... Anybody seen a lost wait command?! :-) You're looking in the wrong place! Man [tc]sh. 'Built-in shell command' shoulda clued you off. Regards, Brian "I've asked this same sort of question" Handy From owner-freebsd-hackers Wed Jul 23 19:08:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00521 for hackers-outgoing; Wed, 23 Jul 1997 19:08:44 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA00507 for ; Wed, 23 Jul 1997 19:08:39 -0700 (PDT) Received: from earth.mat.net (root@[206.246.122.2]) by cais.cais.com (8.8.5/CJKv1.99-CAIS) with SMTP id WAA06875; Wed, 23 Jul 1997 22:08:33 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id WAA27984; Wed, 23 Jul 1997 22:08:22 -0400 Date: Wed, 23 Jul 1997 22:08:34 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: chris.moran@usa.net cc: hackers@FreeBSD.ORG Subject: Re: Dynamic DNS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 23 Jul 1997 chris.moran@usa.net wrote: > Anybody working on such a beast for FreeBSD? What's that? Got a web pointer on an explanation? I thought DNS was pretty dynamic to begin with. > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Wed Jul 23 19:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA02536 for hackers-outgoing; Wed, 23 Jul 1997 19:48:19 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA02531 for ; Wed, 23 Jul 1997 19:48:14 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id DAA25440; Thu, 24 Jul 1997 03:46:54 +0200 From: Luigi Rizzo Message-Id: <199707240146.DAA25440@labinfo.iet.unipi.it> Subject: Re: getting physically contiguous memory in the kernel To: jas@flyingfox.com (Jim Shankland) Date: Thu, 24 Jul 1997 03:46:54 +0200 (MET DST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199707232315.QAA10162@biggusdiskus.flyingfox.com> from "Jim Shankland" at Jul 23, 97 04:14:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is there an easy way to get physically contiguous memory in the FreeBSD > kernel? The de driver calls malloc() to obtain a buffer, part of which > must be physically contiguous; this buffer has now grown to be > 4K, > causing the transmit descriptors to span a page boundary. When the > 2 pages are not physically contiguous, the driver breaks. look at contigmalloc() or (probably better) vm_page_alloc_contig(). The latter is used in /sys/pci/brooktree848.c for the brooktree driver and /sys/pci/meteor.c for the meteor driver. The former is generally used for allocating buffers for use with the ISA DMA. Cheers Luigi From owner-freebsd-hackers Wed Jul 23 20:04:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03396 for hackers-outgoing; Wed, 23 Jul 1997 20:04:51 -0700 (PDT) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03382 for ; Wed, 23 Jul 1997 20:04:46 -0700 (PDT) Received: from localhost (ian@localhost) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id UAA15866 for ; Wed, 23 Jul 1997 20:04:44 -0700 (PDT) Date: Wed, 23 Jul 1997 20:04:44 -0700 (PDT) From: Ian Kallen To: hackers@FreeBSD.ORG Subject: Re: Dynamic DNS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Not FreeBSD specific, I've been working on compiling information and resources on distributed servers - DNS is one component of such an effort. The barebones are currently at http://www.arachna.com/webservers/distributed_servers.html but I'm open to any contributions to fill this out. I expect to develop and link in details in the weeks ahead. On Wed, 23 Jul 1997 chris.moran@usa.net wrote: > Date: Wed, 23 Jul 1997 19:02:42 > From: chris.moran@usa.net > To: hackers@FreeBSD.ORG > Subject: Dynamic DNS > > Anybody working on such a beast for FreeBSD? > > -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Wed Jul 23 20:21:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04178 for hackers-outgoing; Wed, 23 Jul 1997 20:21:52 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04170 for ; Wed, 23 Jul 1997 20:21:46 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id FAA24162; Thu, 24 Jul 1997 05:25:43 +0200 (CEST) From: Mikael Karpberg Message-Id: <199707240325.FAA24162@ocean.campus.luth.se> Subject: Re: Missing binaries in 2.2.2? In-Reply-To: from "Brian N. Handy" at "Jul 23, 97 06:57:33 pm" To: handy@sag.space.lockheed.com (Brian N. Handy) Date: Thu, 24 Jul 1997 05:25:42 +0200 (CEST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Brian N. Handy: > > >Er... Anybody seen a lost wait command?! :-) > > You're looking in the wrong place! Man [tc]sh. 'Built-in shell command' > shoulda clued you off. It did. But my problem was that there was a manpage for the command, but no command to the manpage. :-) I'm not talking about tcsh's built-in wait. That one exists, quite clearly. Try "man wait". ;-) /Mikael From owner-freebsd-hackers Wed Jul 23 21:08:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06070 for hackers-outgoing; Wed, 23 Jul 1997 21:08:34 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA06063 for ; Wed, 23 Jul 1997 21:08:28 -0700 (PDT) Received: (qmail 20702 invoked by uid 1000); 24 Jul 1997 04:08:42 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970723082419.33054@ican.net> Date: Wed, 23 Jul 1997 21:08:42 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Josh Tiefenbach Subject: Re: Is /usr/src/sys self-contained? Cc: hackers@FreeBSD.ORG, Jaye Mathisen Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Josh Tiefenbach; On 23-Jul-97 you wrote: > On Tue, Jul 22, 1997 at 06:27:22PM -0700, Jaye Mathisen wrote: > > > > > > ie, let's say I want to mess around with the DPT driver, but I CVSUP > > regularly, so I don't want cvsup to wipe out all the good stuff > > I get when I apply the DPT patches... > > > > Just watch it - the latest rev of the DPT driver (1.1.9 i think) goes off > and > sticks stuff outside of /usr/src/sys. I dont have an exact list handy. huh? You must be talking about usr.sbin/dpt. You can safely chop it off. For now. later (soon) it will hold the dptmgr stuff. Use cvs add foo to add unique files Use cvs update -P -d to checkout/merge Use cvs diff -c -N to make a new patch against the standard tree. All the above wisdom is not mine. Justin Gibbs is to blame :-) Simon From owner-freebsd-hackers Wed Jul 23 22:04:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08813 for hackers-outgoing; Wed, 23 Jul 1997 22:04:48 -0700 (PDT) Received: from aaka.3skel.com (aaka.3skel.com [207.240.134.73]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08806 for ; Wed, 23 Jul 1997 22:04:41 -0700 (PDT) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by aaka.3skel.com (8.8.5/8.8.2) with ESMTP id BAA29854 for ; Thu, 24 Jul 1997 01:04:38 -0400 (EDT) Received: from fnur.3skel.com (fnur.3skel.com [192.168.0.8]) by fnur.3skel.com (8.8.5/8.8.2) with ESMTP id BAA05666 for ; Thu, 24 Jul 1997 01:04:38 -0400 (EDT) Message-ID: <33D6E265.46DEFC7@3skel.com> Date: Thu, 24 Jul 1997 01:04:37 -0400 From: Dan Janowski Organization: Triskelion Systems, Inc. X-Mailer: Mozilla 4.0b5C (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: hackers Subject: ipfw divert, transparent proxy X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am replacing an old TIS firewall that has one very interesting feature that I am looking to provide with my FreeBSD 2.2.2 box. It is this: They use ipfs which has the capability of "transparently" doing packet re-rerouting and, thereby, proxy transparently. (This is my understanding from looking at the config for about five minutes) With the TIS firewall set as a client's default router, this "transparent" mechanism will take a packet that is destined for x.x.x.x:port, where x.x.x.x is an exterior Internet address, and essentially drop the IP address and deliver the packet to the local "port". This has some limited usefulness. Some services, like whois, that always go to the InterNIC can be automatically proxied. In this particular case, AOL (yuck) is the problem. There is no proxying for AOL's client, but this transparent mechanism works very well. How can I do this? I know that the current ipfw supports divert sockets, but I don't see any references to a general purpose proxy (like plug-gw) that supports diverts. Delegate does application proxy, but I don't see divert support there. Any hints? Thanks, Dan -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY From owner-freebsd-hackers Wed Jul 23 22:28:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA09676 for hackers-outgoing; Wed, 23 Jul 1997 22:28:48 -0700 (PDT) Received: from mail.tamu.edu (mail.tamu.edu [128.194.103.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA09667 for ; Wed, 23 Jul 1997 22:28:46 -0700 (PDT) Received: from dropzone.tamu.edu (dropzone.tamu.edu [165.91.210.99]) by mail.tamu.edu (8.8.5/8.8.5) with SMTP id AAA20790 for ; Thu, 24 Jul 1997 00:28:45 -0500 (CDT) Received: from jumprun.tamu.edu by dropzone.tamu.edu (SMI-8.6/SMI-SVR4) id AAA21496; Thu, 24 Jul 1997 00:24:23 -0500 Received: from localhost by jumprun.tamu.edu (SMI-8.6/SMI-SVR4) id AAA09709; Thu, 24 Jul 1997 00:28:53 -0500 Date: Thu, 24 Jul 1997 00:28:53 -0500 (CDT) From: "Jo, SanKu" To: freebsd-hackers@freebsd.org Subject: VIF : the bandwidth taken by multicasting packet (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy ! Because I hope to check the Bandwidth taken by the IP multicastingrouter(FreeBSD box), I tried to use iotcl(Channel_descriptor, SIOCGETVIFCNT, struct *sioc_vif_req). I heard this function retruns the input and output Bandwidth. There are two cases for testing. 1. When Host-A is source and Host-B is receiver, the Bandwidth rate value returned by the function is correct. 2. When Host-B is source and Host-A is receiver, the Bandwidth rate value(out_bytes) retruned by the function is wrong. Even the case witout any receiver in Backbone(as Host-A), the function returns the whole bandwidth rate(in_bytes) which is taken by the source, HOST-B. I think the prune function is all right. Below is my configuration with multicast routers denoted by asterisks: ======++=====BackBOne <--in || -->out || HOST-A VIF Research Subnet HOST-B ------++---------- --------------------- || ---------- |sparc* | ethernet | freebsd 2.1 * | || |sparc | | 128.194.169.93 |-----------|169.53 166.4 |---++-------| 166.5 | | 3.8 | | 3.3 | || | | ------------------ --------------------- || ---------- Its' default gateway is freebsd How can I get correct bandwidth for the second case ? Is it possible or not to get it ? And where can I get some information for hacking the multicasting function in FreeBSD ? Any comment will be very appreciated. Thank you for your kind attention ! Best regards, Jo, SanKu Texas A&M University. Http://ee.tamu.edu/~skjo From owner-freebsd-hackers Wed Jul 23 22:42:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA10279 for hackers-outgoing; Wed, 23 Jul 1997 22:42:57 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10270 for ; Wed, 23 Jul 1997 22:42:51 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id PAA01933; Thu, 24 Jul 1997 15:42:25 +1000 (EST) Date: Thu, 24 Jul 1997 15:42:24 +1000 (EST) From: "Daniel O'Callaghan" To: Dan Janowski cc: hackers Subject: Re: ipfw divert, transparent proxy In-Reply-To: <33D6E265.46DEFC7@3skel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 24 Jul 1997, Dan Janowski wrote: > I am replacing an old TIS firewall that has one very > interesting feature that I am looking to provide with my > FreeBSD 2.2.2 box. It is this: > > They use ipfs which has the capability of "transparently" doing > packet re-rerouting and, thereby, proxy transparently. It is a nice feature, and divert sockets is the way to do it in FreeBSD, but it has not been done yet. got half-way through a transparent http proxy using divert sockets, but did a tcpdump analysis of his customers' traffic and found that < 1% were not using the proxy, so he did not bother finishing the code (too busy on paying work). Danny From owner-freebsd-hackers Wed Jul 23 23:25:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA11890 for hackers-outgoing; Wed, 23 Jul 1997 23:25:06 -0700 (PDT) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA11884 for ; Wed, 23 Jul 1997 23:25:01 -0700 (PDT) From: sthaug@nethelp.no Received: (qmail 16437 invoked by uid 1001); 24 Jul 1997 06:24:55 +0000 (GMT) To: chris.moran@usa.net Cc: hackers@FreeBSD.ORG Subject: Re: Dynamic DNS In-Reply-To: Your message of "Wed, 23 Jul 1997 19:02:42" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 24 Jul 1997 08:24:55 +0200 Message-ID: <16435.869725495@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Anybody working on such a beast for FreeBSD? It's not clear what you mean. BIND-8.1.1 already includes dynamic updates, and compiles nicely on FreeBSD. If you mean the DYNDNS stuff from ml.org, they claim to have a script that already works with FreeBSD. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-hackers Wed Jul 23 23:33:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA12184 for hackers-outgoing; Wed, 23 Jul 1997 23:33:12 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA12178 for ; Wed, 23 Jul 1997 23:33:06 -0700 (PDT) Message-Id: <199707240633.XAA12178@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA105605257; Thu, 24 Jul 1997 16:20:57 +1000 From: Darren Reed Subject: Re: ipfw divert, transparent proxy To: danj@3skel.com (Dan Janowski) Date: Thu, 24 Jul 1997 16:20:56 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <33D6E265.46DEFC7@3skel.com> from "Dan Janowski" at Jul 24, 97 01:04:37 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Dan Janowski, sie said: > > I am replacing an old TIS firewall that has one very > interesting feature that I am looking to provide with my > FreeBSD 2.2.2 box. It is this: > > They use ipfs which has the capability of "transparently" doing > packet re-rerouting and, thereby, proxy transparently. > > (This is my understanding from looking at the config for > about five minutes) > > With the TIS firewall set as a client's default router, > this "transparent" mechanism will take a packet that is > destined for x.x.x.x:port, where x.x.x.x is an exterior > Internet address, and essentially drop the IP address and > deliver the packet to the local "port". IP Filter will support what you're doing, although you'd need to patch the proxy software to use IP Filter. There's some sample patches available for using ftp-gw transparently. Darren From owner-freebsd-hackers Thu Jul 24 00:09:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA14199 for hackers-outgoing; Thu, 24 Jul 1997 00:09:13 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA14194 for ; Thu, 24 Jul 1997 00:09:09 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wrHuN-0003HA-00; Thu, 24 Jul 1997 00:01:55 -0700 Date: Thu, 24 Jul 1997 00:01:54 -0700 (PDT) From: Tom Samplonius To: hackers@freebsd.org Subject: annoyed at login.conf Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk login.conf isn't that useful. Users who are trying to avoid resource limits can simply have "at", or "cron" start jobs for them, since neither "atrun" or "cron" set the users resource limits before starting the job. They should. Tom From owner-freebsd-hackers Thu Jul 24 03:06:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA20637 for hackers-outgoing; Thu, 24 Jul 1997 03:06:32 -0700 (PDT) Received: from ns.uk.peer.net ([194.117.157.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA20619 for ; Thu, 24 Jul 1997 03:05:47 -0700 (PDT) Received: (from aledm@localhost) by ns.uk.peer.net (8.6.12/8.6.12) id LAA09104; Thu, 24 Jul 1997 11:29:42 +0100 Date: Thu, 24 Jul 1997 11:29:40 +0100 (BST) From: Aled Morris X-Sender: aledm@ns.uk.peer.net To: hackers@FreeBSD.ORG Subject: DPT (was Re: Is /usr/src/sys self-contained?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 23 Jul 1997, Simon Shapiro wrote: > > Just watch it - the latest rev of the DPT driver (1.1.9 i think) goes off > > and > > sticks stuff outside of /usr/src/sys. I dont have an exact list handy. > > huh? You must be talking about usr.sbin/dpt. You can safely chop it off. > For now. later (soon) it will hold the dptmgr stuff. On the subject of DPT controllers, I have a couple of EISA ones which came out of a junked Dell server. If anyone wants them, you're welcome to take them away. I also have an EISA Adaptec SCSI controller. Email me for collection details (I am in the South East of England by the way). Aled From owner-freebsd-hackers Thu Jul 24 04:13:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA22952 for hackers-outgoing; Thu, 24 Jul 1997 04:13:56 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA22914; Thu, 24 Jul 1997 04:13:29 -0700 (PDT) Message-Id: <199707241113.EAA22914@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA176122054; Thu, 24 Jul 1997 21:00:54 +1000 From: Darren Reed Subject: Re: Compaq's Built in SCSI To: Jay.Erickson@ibm.net Date: Thu, 24 Jul 1997 21:00:54 +1000 (EST) Cc: questions@FreeBSD.ORG, hardware@FreeBSD.ORG, hackers@FreeBSD.ORG, scsi@FreeBSD.ORG, md@dcs.qmw.ac.uk, brian@ibm.net, Tao@gate.sinica.ed In-Reply-To: <33D61D15.AA791100@ibm.net> from "Jay Erickson" at Jul 23, 97 10:02:47 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Jay Erickson, sie said: > > I searched the archives and didn't find a definitive answer. > > I want to install FreeBSD on a couple of Compaq Proliant 1000's with the > built in SCSI > controller or Compaq's Smart SCSI controller. The Installer kernel > doesn't seem to > recognize either. FWIW, Solaris 2 supports some of the Compaq Proliants...check http://access1.sun.com Darren From owner-freebsd-hackers Thu Jul 24 05:42:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA25843 for hackers-outgoing; Thu, 24 Jul 1997 05:42:03 -0700 (PDT) Received: from burka.carrier.kiev.ua (root@burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA25838 for ; Thu, 24 Jul 1997 05:41:53 -0700 (PDT) Received: (from archer@localhost) by burka.carrier.kiev.ua (8.8.5/8.who.cares.1) id OAA10007; Thu, 24 Jul 1997 14:18:09 +0300 (EEST) Message-ID: <19970724141808.22497@burka.carrier.kiev.ua> Date: Thu, 24 Jul 1997 14:18:08 +0300 From: Alexander Litvin To: hackers@freebsd.org Subject: inetd hanging Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, all! We have a problem here with FBSD2.2.2. May be, a wrong place to ask for clarification, but nevertheless... Well, sometimes -- it seems under some heavy load -- our access server ceases to accept telnets, rlogins, etc -- all stuff listed in inetd.conf. It happens not very often, but it happens. After, say, telnet, box answers "Connected to ..." -- and that's all. Sometimes kill -1 helps, sometimes not -- then it is necessary to restart inetd. It seems that kernel rather then inetd is responsible for that -- inetd -d in such a case shows nothing, that is connection is not handed to inetd (though may be I'm wrong here). netstat -rn showns a lot of sockets in FIN_WAIT state. To get more information: the box is access server, and it handles not only calls local to it, but also calls to other access servers, which hand their calls via rlogin to the central box (which I'm talking about). Other access servers are remote, and sometimes may go offline due to problems with links. I ask only for the proper direction to start searching the reason of the problem. -- Alexander Litvin Duty Postmaster, Lucky Net Ltd. From owner-freebsd-hackers Thu Jul 24 12:30:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA19294 for hackers-outgoing; Thu, 24 Jul 1997 12:30:24 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19288 for ; Thu, 24 Jul 1997 12:30:22 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA26942 for ; Thu, 24 Jul 1997 12:17:13 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd026938; Thu Jul 24 19:17:10 1997 Message-ID: <33D7A9C2.7DE14518@whistle.com> Date: Thu, 24 Jul 1997 12:15:14 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: PPP kit and info? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I rememebr there is a ppp kit someone has, and also a separate ppp 'howto' doc who has these? thanks julian From owner-freebsd-hackers Thu Jul 24 14:16:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24557 for hackers-outgoing; Thu, 24 Jul 1997 14:16:13 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA24552 for ; Thu, 24 Jul 1997 14:16:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18139; Thu, 24 Jul 1997 14:11:48 -0700 From: Terry Lambert Message-Id: <199707242111.OAA18139@phaeton.artisoft.com> Subject: Re: Database To: info@pagecreators.com (Rod Ebrahimi) Date: Thu, 24 Jul 1997 14:11:48 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199707230112.SAA17951@netroplex.com> from "Rod Ebrahimi" at Jul 22, 97 06:10:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > While on the subject of NT and FreeBSD, I wanted to address another issue. > For management and ease we are looking into developing a database system > that will be web based (privately) and enable employees to > add/delete/modify users from the comfort of there own browser, which also > in turn placed them on the billing list and sent invoices and/or charged > Credit Cards on the fly. I would appreciate any information on this > matter... Are there any well known Database designers that I should look > for? Get on Yahoo and lookg for "LDAP", "POSIX" and "draft". There is a draft MIB for POSIX account information for use in LDAP. There is also a LINUX implementation of a pluggable LDAP module using this MIB (the pluggable secruity module interface has an RFC out there fore it already; the IMAP4v1 RFC references it. The draft standard discusses all of the POSIX environment values necessary to run a UNIX credential server out of an LDAP database for non-boot-critical accounts. There is also a discussion (you may have to got to AltaVista for it, be forewarned) on one of the LDAP pages about running both NIS and Sendmail maildrop information out of an LDAP directory using the POSIX MIB. Finally, there is an NT implementation of a GIMP (the security interface for credential verification) for use by NT that uses NIS. It is available for download from the SAMBA site. This would let you keep a user database in LDAP, export it via NIS, and use the LDAP data to authenticate UNIX, NT, and Windows 95 (presuming the 95 clients were NT workgroup members) from a centrally administered database. Note that the U of Michigan LDAP code requires tweaking to operate ...it wants NDBM, which FreeBSD pretends (badly) to have. When built, the U of Michigan code fails to properly interoperate with the "LDAP browser" available for Win32 (95 and NT) from a German company (30 day eval). I was also unable to make the U of Michigan code add groups correctly. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jul 24 14:20:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24794 for hackers-outgoing; Thu, 24 Jul 1997 14:20:55 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA24785; Thu, 24 Jul 1997 14:20:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18156; Thu, 24 Jul 1997 14:16:34 -0700 From: Terry Lambert Message-Id: <199707242116.OAA18156@phaeton.artisoft.com> Subject: Re: pcireg.h lost children... ? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 24 Jul 1997 14:16:34 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199707230142.LAA04452@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 23, 97 11:12:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Right. "Nope". Because this is hardly what I was suggesting. I can > > access a locally stored dbm LDAP database using dbm. I don't have > > to use a network connection. This type of information, like the > > credentials necessary to get to the point where the network is up > > and credentials can be remotely obtained, *must*, by definition, > > be locally stored. > > ... and by extension about the only thing that's left worth having in > the remote database is information for hardware that isn't > involved in getting to that stage, ie. soundcards. Not what I'd > describe as terribly helpful, no? Wrong. You only need to store local non-default configuration settings, and boot critical account data, etc.. All other user accounts can be remote. NIS operates this way; I don't understand why you would find the idea so alien. > > Just so that you're aware, this problem was solved before outside > > the BSD camp at Novell, when providing NDS-based logons to UnixWare; > > UnixWare had to be brought up to the point where the net was up > > before the NDS calls could hope to go remote. > > Accessing user credentials is just ever so _slightly_ different to > accessing configuration information for operation-critical hardware. *Non-default* configuration information. And we both agree that it needs to be somewhere; one somewhere is topologically equivalent to any other. > > There's *some* stuff on the USU (*.usu.edu) FTP servers, where they > > keep all the NetWare stuff. > > Ta. > > > Alternately, there is a driver developement kit you can get from > > Microsoft; they sendit to all the board vendors who want it. > > As a non-board vendor, how does one qualify for this? Ask. Don't make it obvious that you aren't a board vendor. They will assume you are by default, since that is the target audience. > ... or can't. This is exactly the reason for doing it. In addition, > the reading I've done does actually imply that the architecture is > reasonably sane, even if it does offload too much work (IMHO) onto the > card. Yes; duplicate support routines is a hazard of running more than one brand of network card in the machine. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Jul 24 14:58:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA26824 for hackers-outgoing; Thu, 24 Jul 1997 14:58:10 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26818 for ; Thu, 24 Jul 1997 14:58:08 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id OAA20589 for ; Thu, 24 Jul 1997 14:58:07 -0700 (PDT) Date: Thu, 24 Jul 1997 14:58:06 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Need BSD/OS or Linux compatibility expert. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a need to find somebody that can figure out why the ArcServe Agent for either Linux or BSD/OS fails under Linux. If you're interested, let me know, we can talk $$$'s, and methods. From owner-freebsd-hackers Thu Jul 24 16:28:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA01414 for hackers-outgoing; Thu, 24 Jul 1997 16:28:33 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA01408 for ; Thu, 24 Jul 1997 16:28:29 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id QAA05767 for ; Thu, 24 Jul 1997 16:28:27 -0700 (PDT) Date: Thu, 24 Jul 1997 16:28:27 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Library compile warning. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Don't recall seeing too many errors in libc, and this one happened to jump out at me during a current make world on 2.2-stable: cc -fpic -DPIC -O2 -m486 -pipe -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DYP -c /usr/src/lib/libc/../libc/stdlib/strtoq.c -o strtoq.so /usr/src/lib/libc/../libc/stdlib/strtoq.c: In function `strtoq': /usr/src/lib/libc/../libc/stdlib/strtoq.c:108: warning: integer overflow in expression cc -fpic -DPIC -O2 -m486 -pipe -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DYP -c /usr/src/lib/libc/../libc/stdlib/strtoul.c -o strtoul.so cc -fpic -DPIC -O2 -m486 -pipe -DLIBC_RCS -DSYSLIBC_RCS -D__DBINTERFACE_PRIVATE Just seems like libc shouldn't have any warnings. From owner-freebsd-hackers Thu Jul 24 16:28:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA01433 for hackers-outgoing; Thu, 24 Jul 1997 16:28:43 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA01428 for ; Thu, 24 Jul 1997 16:28:39 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id QAA14676; Thu, 24 Jul 1997 16:26:54 -0700 (PDT) To: Jaye Mathisen cc: hackers@FreeBSD.ORG Subject: Re: Need BSD/OS or Linux compatibility expert. In-reply-to: Your message of "Thu, 24 Jul 1997 14:58:06 PDT." Date: Thu, 24 Jul 1997 16:26:54 -0700 Message-ID: <14673.869786814@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have a need to find somebody that can figure out why the ArcServe Agent > for either Linux or BSD/OS fails under Linux. ^^^^^^^^^^^ Linux or Linux compatibility mode in FreeBSD? That's going to make a strong difference to the potential respondent. :) Jordan From owner-freebsd-hackers Thu Jul 24 16:44:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA02351 for hackers-outgoing; Thu, 24 Jul 1997 16:44:34 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA02346 for ; Thu, 24 Jul 1997 16:44:30 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id QAA08476; Thu, 24 Jul 1997 16:44:25 -0700 (PDT) Date: Thu, 24 Jul 1997 16:44:25 -0700 (PDT) From: Jaye Mathisen To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: Need BSD/OS or Linux compatibility expert. In-Reply-To: <14673.869786814@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Argh, sorry, the ArcServe agent comes in Linux and BSD/OS flavors. Neither of which run under FreeBSD properly. I would like to see if whatever dies under BSD/OS emulation is fixable or not. On Thu, 24 Jul 1997, Jordan K. Hubbard wrote: > > I have a need to find somebody that can figure out why the ArcServe Agent > > for either Linux or BSD/OS fails under Linux. > ^^^^^^^^^^^ > > Linux or Linux compatibility mode in FreeBSD? That's going to make a > strong difference to the potential respondent. :) > > Jordan > From owner-freebsd-hackers Thu Jul 24 16:59:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA03240 for hackers-outgoing; Thu, 24 Jul 1997 16:59:47 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA03221; Thu, 24 Jul 1997 16:59:39 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id QAA11169; Thu, 24 Jul 1997 16:59:36 -0700 (PDT) Date: Thu, 24 Jul 1997 16:59:34 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org, scsi@freebsd.org Subject: Ugh, DPT killing my performance... :( Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk P6-200, 64MB RAM, DPT 2 channel Ultra Wide, plugged in to Seagate Barracuda's. (4GB). DPT has 64MB RAM, version 1.10 DPT patch, 2.2.2-RELEASE disk. All disks are on the same channel (0) of the DPT. The following script renders the system essentially unusable: while (1) (cd t1 && iozone 600) (cd t2 && iozone 600) bonnie -s 200 & wait end ls -l of /root takes > 20 seconds. TOP is showing > 99% idle time. systat 2 only shows 28 interrups/sec on IRQ 15, which is the DPT controller, according to the BIOS. Transfers shows about 20-30 tps. There are these occasional burps of > 20% system time, not sure where it's going. No other processes actively running. This concerns me a bit. I tried the same thing on a 3 disk ccd array, and it runs much smoother, w/o the long delays. Of course, no parity. The DPT is configured as RAID-5, 128k stripes. Other than the grief of installing it, not sure how much benefit there would be to changing this. From owner-freebsd-hackers Thu Jul 24 18:50:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA07583 for hackers-outgoing; Thu, 24 Jul 1997 18:50:43 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA07578 for ; Thu, 24 Jul 1997 18:50:40 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14246; Thu, 24 Jul 1997 21:50:04 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 24 Jul 1997 21:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id VAA00234; Thu, 24 Jul 1997 21:11:26 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id VAA00269; Thu, 24 Jul 1997 21:20:21 -0400 (EDT) Date: Thu, 24 Jul 1997 21:20:21 -0400 (EDT) From: Thomas David Rivers Message-Id: <199707250120.VAA00269@lakes.water.net> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!cdsnet.net!mrcpu, ponds!lakes.water.net!rivers, ponds!dyson.iquest.net!toor, ponds!idi.ntnu.no!Tor.Egge Subject: A "data point" on my daily panics... Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - Just to let everyone know I haven't forgotten this point... If you recall, a few weeks ago; I posted a note about the seeming increase in news expiration times with 2.2.2. It's since come out that 2.2.2 may not have been the culprit; but just a series of several bad days in the control group creating *many* files. Anyway - to work around the problem; David G. had suggested increasing the number of NBUFs - to allow for more buffers, which should reduce the I/O. I did so - and got my news system under control... However - it had another surprising side-effect. I've had fewer panics. They now seem to come about every 5 to 6 days (i.e. a little over once a week instead of every day...) The panic continues to be "panic: ffs_valloc: dup alloc" I've also gotten the "bar dir" panic; which I believe is explained by the same scenario... (things not quite making it to disk...) One of the panic's is one I haven't yet seen: panic: ufs_ihashget: recursive lock not expected -- pid %d which, again, could be explained by the same phenomena... Details for those of you who haven't been through all of this: 386dx-33, w/Intel 387 - 8meg memory; 1+GIG IDE hard drive (although, I can duplicate it with an aha1542B and a SCSI drive), running a news feed... the panics seem to occur during the expire. I've duplicated this on two 386dx-33 machines.... the second has 12 meg of memory.... I can demonstrate the problem doing a newfs when the system isn't multiuser; so I don't believe it's "stress" related. So - increasing the number of buffers does seem to decrease the probability of hitting the problem - which could help to explain why those of you with large physical memory (on which the NBUF calculation is made, if you don't override it) can potentially mask the problem... - Dave Rivers - From owner-freebsd-hackers Thu Jul 24 19:20:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA08664 for hackers-outgoing; Thu, 24 Jul 1997 19:20:40 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA08658 for ; Thu, 24 Jul 1997 19:20:36 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA14831; Thu, 24 Jul 1997 22:20:05 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Thu, 24 Jul 1997 22:20 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id VAA00689; Thu, 24 Jul 1997 21:38:46 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id VAA01028; Thu, 24 Jul 1997 21:47:43 -0400 (EDT) Date: Thu, 24 Jul 1997 21:47:43 -0400 (EDT) From: Thomas David Rivers Message-Id: <199707250147.VAA01028@lakes.water.net> To: andreas@klemm.gtn.com, ponds!cdsnet.net!mrcpu Subject: ownership - root or bin? (was Re: sendmail complains about being unable to write his pid file) Cc: ponds!FreeBSD.ORG!hackers, ponds!nethelp.no!sthaug, ponds!lambert.org!terry Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is likely an old thread - but I wanted to add a point no one else has mentioned... I recall working on some boxes in the early, heady, days of UNIX (early 80s) where root did own everything in /bin and /usr/bin. The reason we found for changing this was that an errant program could accidently get permissions to do all sorts of nasty things (mostly kernel issues...) making it easy for someone to become root, etc... creating "bin" and having that uid own the programs was a nice way to avoid these catastrophes. Personally, I'd rather have root ownership restricted to as few files as possible... - Dave Rivers - From owner-freebsd-hackers Thu Jul 24 20:11:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA10108 for hackers-outgoing; Thu, 24 Jul 1997 20:11:36 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA10102 for ; Thu, 24 Jul 1997 20:11:33 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id MAA16906 for ; Fri, 25 Jul 1997 12:11:17 +0900 (JST) To: hackers@freebsd.org Subject: odd xxget() in some network drivers X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 25 Jul 1997 12:11:17 +0900 Message-ID: <16903.869800277@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If my memory is correct, it is assumed that network packets received by NICs should be placed into either: - single internal mbuf - two internal mbufs - multiple external mbufs (for ground information, see m_devget() in /sys/kern/uipc_mbuf.c or "TCP/IP illustrated vol.2" p42) # second case (two internal mbufs) can be omitted for simplicity # in current memory-rich environment, IMHO. However, there seems to be several drivers that does not meet this practice. For example, /sys/dev/vx/if_vx.c will return the packet received in one of the following condition: - single internal mbuf (only if len % 4 == 0) - two internal mbufs (if len % 4 != 0) mbuf 1: m_len = len - (len % 4) mbuf 2: m_len = len % 4 - three internal mbufs mbuf 1: m_len = MLEN mbuf 2: m_len = len - mlen - (len % 4) mbuf 3: m_len = len % 4 - one external mbuf (only if len % 4 == 0) - two external mbufs mbuf 1: m_len = len - (len % 4) mbuf 2: m_len = len % 4 - more than two external mbuf mbuf 1: m_len = MCLBYTES ... mbuf n: m_len = len % 4 I sent PR kernel/4020 but nobody seem to reply to this one. Questions: - could I apply the patch in kernel/4020 to the current source? (who is the boss in /sys/dev/vx?) - could I make some check for other drivers, and apply patches if necessery? Thanks. Jun-ichiro Itoh From owner-freebsd-hackers Thu Jul 24 20:12:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA10164 for hackers-outgoing; Thu, 24 Jul 1997 20:12:43 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA10157 for ; Thu, 24 Jul 1997 20:12:27 -0700 (PDT) Received: from awfulhak.org (dev.lan.awfulhak.org [10.0.1.5]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id DAA29573; Fri, 25 Jul 1997 03:36:08 +0100 (BST) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.6/8.8.6) with ESMTP id DAA02930; Fri, 25 Jul 1997 03:36:07 +0100 (BST) Message-Id: <199707250236.DAA02930@awfulhak.org> X-Mailer: exmh version 2.0delta 6/3/97 To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: PPP kit and info? In-reply-to: Your message of "Thu, 24 Jul 1997 12:15:14 PDT." <33D7A9C2.7DE14518@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 1997 03:36:07 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I rememebr there is a ppp kit someone has, > and > also a separate ppp 'howto' doc > > who has these? http://www.awfulhak.org/ppp.html refers to all the current ppp docs. > thanks > julian -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Thu Jul 24 21:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA12982 for hackers-outgoing; Thu, 24 Jul 1997 21:23:14 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA12975 for ; Thu, 24 Jul 1997 21:23:08 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id VAA16538; Thu, 24 Jul 1997 21:24:55 -0700 (PDT) Message-Id: <199707250424.VAA16538@implode.root.com> To: itojun@itojun.org cc: hackers@FreeBSD.ORG Subject: Re: odd xxget() in some network drivers In-reply-to: Your message of "Fri, 25 Jul 1997 12:11:17 +0900." <16903.869800277@itojun.csl.sony.co.jp> From: David Greenman Reply-To: dg@root.com Date: Thu, 24 Jul 1997 21:24:54 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > If my memory is correct, it is assumed that network packets received > by NICs should be placed into either: > - single internal mbuf > - two internal mbufs > - multiple external mbufs > (for ground information, see m_devget() in /sys/kern/uipc_mbuf.c > or "TCP/IP illustrated vol.2" p42) ># second case (two internal mbufs) can be omitted for simplicity ># in current memory-rich environment, IMHO. I assume that by "external" mbuf you really mean an mbuf cluster. "external" mbufs usually implies non-cluster memory is attached. Those network interfaces in FreeBSD which do DMA normally do it into a single mbuf cluster (attached to an mbuf header). > However, there seems to be several drivers that does not meet this > practice. For example, /sys/dev/vx/if_vx.c will return the packet > received in one of the following condition: > - single internal mbuf (only if len % 4 == 0) > - two internal mbufs (if len % 4 != 0) > mbuf 1: m_len = len - (len % 4) > mbuf 2: m_len = len % 4 > - three internal mbufs > mbuf 1: m_len = MLEN > mbuf 2: m_len = len - mlen - (len % 4) > mbuf 3: m_len = len % 4 > - one external mbuf (only if len % 4 == 0) > - two external mbufs > mbuf 1: m_len = len - (len % 4) > mbuf 2: m_len = len % 4 > - more than two external mbuf > mbuf 1: m_len = MCLBYTES > ... > mbuf n: m_len = len % 4 > I sent PR kernel/4020 but nobody seem to reply to this one. I don't see how the last case can ever happen since an mbuf cluster is 2K bytes - larger than the MTU/MRU. > Questions: > - could I apply the patch in kernel/4020 to the current source? > (who is the boss in /sys/dev/vx?) The new logic in that PR is: ! if (MHLEN < len) { ! /* assumes ETHERMTU < MCLBYTES */ ! MCLGET(m, M_DONTWAIT); ! if (! (m->m_flags & M_EXT)) { ! m_freem(m); ! goto fail; ! } ! } The only problem with the above is that the first if () expression is wrong. The test should be if (len > MHLEN). Not only is this correct for style, but it is logically different: MHLEN < len will allocate an mbuf cluster when len == MHLEN, and this is not desired. > - could I make some check for other drivers, and apply patches if > necessery? I would prefer that you had your proposed changes reviewed first. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Jul 24 21:31:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA13319 for hackers-outgoing; Thu, 24 Jul 1997 21:31:38 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA13309 for ; Thu, 24 Jul 1997 21:31:28 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id NAA18565; Fri, 25 Jul 1997 13:30:53 +0900 (JST) To: dg@root.com Cc: hackers@freebsd.org Subject: Re: odd xxget() in some network drivers X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <199707250424.VAA16538@implode.root.com> In-reply-to: David Greenman 's message of Thu, 24 Jul 1997 21:24:54 -0700. <199707250424.VAA16538@implode.root.com> X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 25 Jul 1997 13:30:53 +0900 Message-ID: <18562.869805053@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The new logic in that PR is: > ! if (MHLEN < len) { > The only problem with the above is that the first if () expression is wrong. >The test should be if (len > MHLEN). Not only is this correct for style, but >it is logically different: MHLEN < len will allocate an mbuf cluster when >len == MHLEN, and this is not desired. ???? I did not write MHLEN <= len. Why len>MHLEN and MHLEN> - could I make some check for other drivers, and apply patches if >> necessery? > I would prefer that you had your proposed changes reviewed first. I prefer that too, however only very few people seems to check problem reports in a regular basis... I do need to wait almost forever. itojun From owner-freebsd-hackers Thu Jul 24 21:37:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA13642 for hackers-outgoing; Thu, 24 Jul 1997 21:37:18 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA13637 for ; Thu, 24 Jul 1997 21:37:14 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id VAA16721; Thu, 24 Jul 1997 21:39:05 -0700 (PDT) Message-Id: <199707250439.VAA16721@implode.root.com> To: itojun@itojun.org cc: hackers@freebsd.org Subject: Re: odd xxget() in some network drivers In-reply-to: Your message of "Fri, 25 Jul 1997 13:30:53 +0900." <18562.869805053@itojun.csl.sony.co.jp> From: David Greenman Reply-To: dg@root.com Date: Thu, 24 Jul 1997 21:39:05 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> The new logic in that PR is: >> ! if (MHLEN < len) { >> The only problem with the above is that the first if () expression is wrong. >>The test should be if (len > MHLEN). Not only is this correct for style, but >>it is logically different: MHLEN < len will allocate an mbuf cluster when >>len == MHLEN, and this is not desired. > > ???? I did not write MHLEN <= len. Why len>MHLEN and MHLEN should result in different situation? Sorry, brain fart. You're correct...there's a reason why we write it the other way: so people like me don't get confused. :-) >> I would prefer that you had your proposed changes reviewed first. > > I prefer that too, however only very few people seems to check > problem reports in a regular basis... I do need to wait almost > forever. In this case it's better to contact the author of the driver(s) directly. Non-bug reports are easily ignored otherwise. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Thu Jul 24 22:04:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14587 for hackers-outgoing; Thu, 24 Jul 1997 22:04:49 -0700 (PDT) Received: from itojun.csl.sony.co.jp (root@itojun.csl.sony.co.jp [133.138.1.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14578 for ; Thu, 24 Jul 1997 22:04:43 -0700 (PDT) From: itojun@itojun.org Received: from localhost (itojun@localhost [127.0.0.1]) by itojun.csl.sony.co.jp (8.8.5/3.3W3) with ESMTP id OAA19053; Fri, 25 Jul 1997 14:04:09 +0900 (JST) To: dg@root.com Cc: hackers@freebsd.org Subject: Re: odd xxget() in some network drivers X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 References: <199707250439.VAA16721@implode.root.com> In-reply-to: David Greenman 's message of Thu, 24 Jul 1997 21:39:05 -0700. <199707250439.VAA16721@implode.root.com> X-Mailer: comp (MHng project) version 1997/04/30 02:23:09, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 25 Jul 1997 14:04:04 +0900 Message-ID: <19050.869807044@itojun.csl.sony.co.jp> Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> ???? I did not write MHLEN <= len. Why len>MHLEN and MHLEN> should result in different situation? > Sorry, brain fart. You're correct...there's a reason why we write it the >other way: so people like me don't get confused. :-) hmm, I see. >> I prefer that too, however only very few people seems to check >> problem reports in a regular basis... I do need to wait almost >> forever. > In this case it's better to contact the author of the driver(s) directly. >Non-bug reports are easily ignored otherwise. The problem makes it very hard to implement ipsec protocol handling routine, so I raised this question. itojun From owner-freebsd-hackers Thu Jul 24 23:03:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16219 for hackers-outgoing; Thu, 24 Jul 1997 23:03:37 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16214 for ; Thu, 24 Jul 1997 23:03:33 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA20443; Fri, 25 Jul 1997 15:33:20 +0930 (CST) From: Michael Smith Message-Id: <199707250603.PAA20443@genesis.atrad.adelaide.edu.au> Subject: Re: Library compile warning. In-Reply-To: from Jaye Mathisen at "Jul 24, 97 04:28:27 pm" To: mrcpu@cdsnet.net (Jaye Mathisen) Date: Fri, 25 Jul 1997 15:33:20 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen stands accused of saying: > > > Don't recall seeing too many errors in libc, and this one happened to > jump out at me during a current make world on 2.2-stable: > > cc -fpic -DPIC -O2 -m486 -pipe -DLIBC_RCS -DSYSLIBC_RCS > -D__DBINTERFACE_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale > -DYP -c /usr/src/lib/libc/../libc/stdlib/strtoq.c -o strtoq.so > /usr/src/lib/libc/../libc/stdlib/strtoq.c: In function `strtoq': > /usr/src/lib/libc/../libc/stdlib/strtoq.c:108: warning: integer overflow > in expression 108 if (any < 0) { 109 acc = UQUAD_MAX; 110 errno = ERANGE; 111 } else if (neg) Then in : /* GCC requires that quad constants be written as expressions. */ #define UQUAD_MAX ((u_quad_t)0-1) /* max value for a uquad_t */ Hmm, looks interesting 8) > Just seems like libc shouldn't have any warnings. Probably aren't enough compiler options turned on yet 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Jul 24 23:19:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16752 for hackers-outgoing; Thu, 24 Jul 1997 23:19:25 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16747 for ; Thu, 24 Jul 1997 23:19:22 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id IAA00426 for ; Fri, 25 Jul 1997 08:20:00 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id IAA17233 for freebsd-hackers@freefall.cdrom.com; Fri, 25 Jul 1997 08:19:59 +0200 (MEST) Date: Fri, 25 Jul 1997 08:19:59 +0200 (MEST) From: Christoph Kukulies Message-Id: <199707250619.IAA17233@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: make mk - ? Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I don't see a mk target any longer (off hand) Why is it gone? -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Jul 25 00:06:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18481 for hackers-outgoing; Fri, 25 Jul 1997 00:06:40 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA18469 for ; Fri, 25 Jul 1997 00:06:30 -0700 (PDT) Received: (qmail 17502 invoked by uid 1000); 25 Jul 1997 07:06:44 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 25 Jul 1997 00:06:44 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Jaye Mathisen Subject: RE: Ugh, DPT killing my performance... :( Cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Jaye Mathisen; On 24-Jul-97 you wrote: > > > P6-200, 64MB RAM, DPT 2 channel Ultra Wide, plugged in to Seagate > Barracuda's. (4GB). DPT has 64MB RAM, version 1.10 DPT patch, > 2.2.2-RELEASE disk. All disks are on the same channel (0) of the DPT. > > The following script renders the system essentially unusable: > > while (1) > > (cd t1 && iozone 600) > (cd t2 && iozone 600) > bonnie -s 200 & > > wait > end > > > ls -l of /root takes > 20 seconds. > > TOP is showing > 99% idle time. > > systat 2 only shows 28 interrups/sec on IRQ 15, which is the DPT > controller, according to the BIOS. Transfers shows about 20-30 tps. Ah, This is it! Take the DPT off that IRQ15. On a P6-200 I am peaking at 1,200 tps, kernel make is about 400, make world 300 or so. On many motherboards IRQ 15 is a garbage can for all sorts of stray signals. If you compiled with DPT_MEASURE_PERFORMANCE; mknod /dev/dpt0 c 130 0 echo -n "dump softc" > /dev/dpt0 get_dpt /dev/dpt0 > /tmp/foo Now look at the output. The second line, tells you the count of aborted interrupts, spurious interrupts, minimum interrupt latelncy and maximum interrupt latency. The third line lists each SCSI command number, name [section in the spec], minimum time to executre, maximum time to execute. The fourth line tells you maximim/minimum waiting time, submitted time, completed time. The next line tells you the number of times commands collided in the driver, # of times the DPT was too busy to accept a command, worst # of retries, best # of retries. These will tell us where the DPT + driver are spending their time. Corrective action can then be suggested. > There are these occasional burps of > 20% system time, not sure where > it's > going. > > No other processes actively running. > > > This concerns me a bit. concerns me A LOT :-) > I tried the same thing on a 3 disk ccd array, and it runs much smoother, > w/o the long delays. Of course, no parity. > The DPT is configured as RAID-5, 128k stripes. Other than the grief of > installing it, not sure how much benefit there would be to changing this. Why grief? I am planning on a new dptmgr for FreeBSD, so your comments are valuable to me. Simon From owner-freebsd-hackers Fri Jul 25 01:45:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA22573 for hackers-outgoing; Fri, 25 Jul 1997 01:45:04 -0700 (PDT) Received: from relay1.cit.ru (relay1.cit.ru [193.125.82.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA22557 for ; Fri, 25 Jul 1997 01:44:58 -0700 (PDT) Received: from free.tula.su by relay1.cit.ru with UUCP id MAA24843; (8.8.2-MVC-141196/vak/1.9) Fri, 25 Jul 1997 12:35:23 +0400 (MSD) Received: from blik.UUCP by free.tula.su with UUCP id MAA07089; (8.8.5-MVC-230497/vak/1.9) 9b Received: by blik.samara.su id AA03836 (5.65/IDA-simtel for hackers@freebsd.org); Fri, 25 Jul 1997 14:09:48 +0500 To: hackers@freebsd.org Message-Id: Organization: Center of Information Technology From: "Igor" Date: Fri, 25 Jul 97 14:09:48 +0500 X-Mailer: BML [UNIX Beauty Mail v.1.39] Subject: RE: kernel debugging Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was just changing rt_xaddrs() > what error did you have here? > what version of the OS? > (what date) > etc. etc. > maybe I made a mistake. > julian I'm loading kernel dump (during route delete xxx.xxx.xxx.) in kgdb and attempt to read parameters of rt_xaddrs() kgdb> p *rtinfo->rti_info[0] Cannot access memory at addres 0xXXXXX I'm loading kernel dump (during route delete xxx.xxx.xxx.1) in kgdb and attempt to read parameters of rt_xaddrs() kgdb> p *rtinfo->rti_info[0] It's OK Version of the OS FreeBSD 2.1.0 --- igor@blik.samara.su (Igor) From owner-freebsd-hackers Fri Jul 25 02:15:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA23947 for hackers-outgoing; Fri, 25 Jul 1997 02:15:00 -0700 (PDT) Received: from netroplex.com (ns1.netroplex.com [206.171.95.130]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA23933 for ; Fri, 25 Jul 1997 02:14:54 -0700 (PDT) Received: from default (hahaha@max008-1.netroplex.com [207.212.27.1]) by netroplex.com (8.8.5/8.8.2) with ESMTP id CAA16119 for ; Fri, 25 Jul 1997 02:15:21 -0700 (PDT) Message-Id: <199707250915.CAA16119@netroplex.com> From: "Rod Ebrahimi" To: Subject: Servers and Network Date: Fri, 25 Jul 1997 02:13:58 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well I am glad to say that I am pretty set on FreeBSD, now since I am not really familiar with the performance and reqs of the OS I am wondering what I should be looking for on our network, main focus is WWW,FTP,TELNET. This is what I was looking at: Main Server: Dual PPro200, 256MB, Raid5 4.0gig scsi drives, 9" mono VGA monitor Second Server: P200,128MB,1.0gig+4.0gig scsi Xwindows workstation: P200MMX, 64MB,1.0gig scsi Win95-NT workstation: P133, 32MB, 2.0gig I would appreciate any suggestion and details about how to setup our network with FreeBSD... is the main server overkill for WWW,FTP,TELNET? Will we be able to do all that is needed with these systems running together? Thank you for your time... Rod From owner-freebsd-hackers Fri Jul 25 02:19:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA24094 for hackers-outgoing; Fri, 25 Jul 1997 02:19:19 -0700 (PDT) Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA24089 for ; Fri, 25 Jul 1997 02:19:14 -0700 (PDT) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.6/8.8.5) with SMTP id LAA24267 for ; Fri, 25 Jul 1997 11:21:10 +0200 (CEST) Date: Fri, 25 Jul 1997 11:21:09 +0200 (CEST) From: Andrzej Bialecki To: freebsd-hackers@FreeBSD.ORG Subject: Nvi and locale Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! I can't get vi to properly display my national characters. As I read in nvi docs, I should set my locale, so I did: setenv LANG C setenv LC_CTYPE lt_LN.ISO-8859-1 <- from nvi docs (why ???) and it still prints all the special characters as \xf3 \xb6 and so on. What am I doing wrong? Sincerely yours, --- Andrzej Bialecki FreeBSD: Turning PCs Into Workstations http://www.freebsd.org Research and Academic Network in Poland From owner-freebsd-hackers Fri Jul 25 05:28:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA00480 for hackers-outgoing; Fri, 25 Jul 1997 05:28:02 -0700 (PDT) Received: from beta.mcit.com (beta.mcit.com [199.249.19.143]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA00461 for ; Fri, 25 Jul 1997 05:27:59 -0700 (PDT) Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49]) by beta.mcit.com (8.8.6/) with ESMTP id HAA20143 for ; Fri, 25 Jul 1997 07:27:28 -0500 (CDT) Received: from pop3a.mail.mci.com (pop3a.mail.mci.com [166.37.172.2]) by ndcrelay.mcit.com (8.8.5/) with ESMTP id IAA21359 for ; Fri, 25 Jul 1997 08:27:27 -0400 (EDT) Received: from rip01643 ([166.35.248.180]) by pop3a.mail.mci.com (Post.Office MTA Undefined release Undefined ID# 1-123U25000L1S10) with ESMTP id AAA7299 for ; Fri, 25 Jul 1997 08:27:27 -0400 Message-ID: <33D89B59.9325CFF9@mci.com> Date: Fri, 25 Jul 1997 07:26:02 -0500 From: "Jeff Kreska" Organization: MCI X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Adaptec 2940UW X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is anybody working on resolving the problems with the Adapatec 2940. It appears that the problems exist in all tree's. I have personaly used the 2.1, latest 2.2snap, and 3.0snap with none of them working 100%. I have entered a PR and noticed that there has been no progress noted. Is there anything I can do to facilitate this? -- Regards, Jeff mailto:jeff.kreska@mci.com From owner-freebsd-hackers Fri Jul 25 05:40:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA01048 for hackers-outgoing; Fri, 25 Jul 1997 05:40:32 -0700 (PDT) Received: from weenix.guru.org (weenix.guru.org [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA01042 for ; Fri, 25 Jul 1997 05:40:29 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.6/8.8.5) id IAA08578 for hackers@freebsd.org; Fri, 25 Jul 1997 08:40:28 -0400 (EDT) From: Keith Mitchell Message-Id: <199707251240.IAA08578@weenix.guru.org> Subject: Bug in pw? (account/pasword exp dates) To: hackers@freebsd.org Date: Fri, 25 Jul 1997 08:40:27 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If I give pw the following command: pw useradd tuser -P -c "Test User" -e 901944000 -p 869834290 -m -h 0 everything seems to work except that the account expiration date and the password expiration date are set to the same thing (to the -e param). the results from pw usershow are: Login Name: tuser #1006 Group: users #200 Full Name: Test User Home: /home/tuser Class: Shell: /usr/local/bin/tcsh Office: [None] Work Phone: [None] Home Phone: [None] Acc Expire: Sat Aug 1 00:00:00 1998 Pwd Expire: Sat Aug 1 00:00:00 1998 This happens under 2.2.2 and -current. Am I doing something wrong?? Thanks. -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited From owner-freebsd-hackers Fri Jul 25 06:12:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA02211 for hackers-outgoing; Fri, 25 Jul 1997 06:12:37 -0700 (PDT) Received: from mail.wup.de (ns.wup.de [149.237.200.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA02205 for ; Fri, 25 Jul 1997 06:12:24 -0700 (PDT) Received: (from root@localhost) by mail.wup.de (8.8.6/8.8.6) id PAA06111; Fri, 25 Jul 1997 15:12:15 +0200 (CEST) Message-ID: <19970725151214.38024@wup.de> Date: Fri, 25 Jul 1997 15:12:14 +0200 From: Andreas Klemm To: hackers@FreeBSD.org Subject: make world fails on 2.2-STABLE ... Reply-To: akl@wup.de, andreas@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 X-phone: Wiechers & Partner +49 2173 3964 161 X-fax: Wiechers & Partner +49 2173 3964 222 Sender: owner-freebsd-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Someone similar experiences ? I'm using FreeBSD-2.2-STABLE Cleaning up the source tree -------------------------------------------------------------- cd /usr/src && make cleandir ===> include rm -f a.out Errs errs mklog osreldate.h version vers.c ===> include/rpcsvc rm -f a.out Errs errs mklog klm_prot.h mount.h nfs_prot.h nlm_prot.h rex.h rnusers.h rquota.h rstat.h rwall.h sm_inter.h spray.h yppasswd.h yp.h ypxfrd.h ===> include/rpcsvc rm -f a.out Errs errs mklog klm_prot.h mount.h nfs_prot.h nlm_prot.h rex.h rnusers.h rquota.h rstat.h rwall.h sm_inter.h spray.h yppasswd.h yp.h ypxfrd.h ===> lib ===> lib/csu/i386 "/usr/share/mk/bsd.man.mk", line 10: Malformed conditional (!empty(MANBUILDCAT)) "/usr/share/mk/bsd.man.mk", line 21: Malformed conditional (!empty(MANBUILDCAT)) "/usr/share/mk/bsd.man.mk", line 27: if-less endif "/usr/share/mk/bsd.man.mk", line 27: Need an operator "/usr/share/mk/bsd.man.mk", line 229: Malformed conditional (!empty(MANBUILDCAT)) "/usr/share/mk/bsd.man.mk", line 245: if-less endif "/usr/share/mk/bsd.man.mk", line 245: Need an operator "/usr/share/mk/bsd.prog.mk", line 162: if-less elif "/usr/share/mk/bsd.prog.mk", line 163: Inconsistent operator for maninstall "/usr/share/mk/bsd.prog.mk", line 165: if-less endif "/usr/share/mk/bsd.prog.mk", line 165: Need an operator Fatal errors encountered -- cannot continue *** Error code 1 From owner-freebsd-hackers Fri Jul 25 09:46:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12093 for hackers-outgoing; Fri, 25 Jul 1997 09:46:33 -0700 (PDT) Received: from bitbox.follo.net (eivind@bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA12088 for ; Fri, 25 Jul 1997 09:46:28 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.5/8.7.3) id SAA04680; Fri, 25 Jul 1997 18:45:21 +0200 (CEST) Date: Fri, 25 Jul 1997 18:45:21 +0200 (CEST) Message-Id: <199707251645.SAA04680@bitbox.follo.net> From: Eivind Eklund To: Archie Cobbs CC: chad@anasazi.com, freebsd-hackers@FreeBSD.ORG In-reply-to: Archie Cobbs's message of Tue, 22 Jul 1997 19:04:24 -0700 (PDT) Subject: Re: cvs commit: src/sys/net rtsock.c References: <9707170044.AA06065@chad.anasazi.com> <199707230204.TAA23468@bubba.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > [ this was on -current and -stable mailing lists; moved to -hackers ] > > > Can you spell lint? I knew that you could... > > > > If FreBSD's not gonna have a Lint, folks in development mode should turn > > on all the compiler warning flags. Make world in the field can be much > > less verbose. > > I agree. The kernel should be compiled with -Wall from now on. > Then maybe the warnings will get annoying enough for people to > start fixing them (I volunteer to help). Personally, I couldn't > function without gcc -Wall... I am somewhat tempted to attempt to make FreeBSD lint cleanly under flexelint - I'm guessing we could get a free license for FreeBSD use from Gimpel. However, after having attempted this on IIJ-PPP, I'm getting a feeling for how much work it is going to be if done properly - and that is a lot of work. The only way I can think of to actually get that done is to do it as a part of the review project, and I don't know if everybody else would feel it was worth their time. Other things that would be worth running against the tree are efence and gcc w/boundschecking - neither of which I've had time to do yet, either. Eivind. From owner-freebsd-hackers Fri Jul 25 09:48:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12199 for hackers-outgoing; Fri, 25 Jul 1997 09:48:04 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12194 for ; Fri, 25 Jul 1997 09:48:02 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wrnQ8-0004G5-00; Fri, 25 Jul 1997 09:40:48 -0700 Date: Fri, 25 Jul 1997 09:40:47 -0700 (PDT) From: Tom Samplonius To: Rod Ebrahimi cc: hackers@freebsd.org Subject: Re: Servers and Network In-Reply-To: <199707250915.CAA16119@netroplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Jul 1997, Rod Ebrahimi wrote: > I would appreciate any suggestion and details about how to setup our > network with FreeBSD... is the main server overkill for WWW,FTP,TELNET? > Will we be able to do all that is needed with these systems running > together? "... do all that is needed...?" You haven't really described what is needed. A 386 with 8MB RAM, and 120MB IDE hard drive can run http, ftp, and telnet, but won't be able to handle a lot of connections. > Thank you for your time... > > Rod > > Tom From owner-freebsd-hackers Fri Jul 25 09:49:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12268 for hackers-outgoing; Fri, 25 Jul 1997 09:49:13 -0700 (PDT) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA12258 for ; Fri, 25 Jul 1997 09:49:10 -0700 (PDT) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id JAA06951 for ; Fri, 25 Jul 1997 09:49:06 -0700 (PDT) Message-Id: <3.0.3.32.19970725095037.00af3d40@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 25 Jul 1997 09:50:37 -0700 To: freebsd-hackers@FreeBSD.ORG From: Ian Kallen Subject: Re: Adaptec 2940UW In-Reply-To: <33D89B59.9325CFF9@mci.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Problems I'd had with the "U" flavor of 2940's were remedied by turning _on_ "Plug and Play Scam Support" - counterintuitive but effective. At 07:26 AM 7/25/97 -0500, Jeff Kreska wrote: >Is anybody working on resolving the problems with the Adapatec 2940. It >appears that the problems exist in all tree's. I have personaly used >the 2.1, latest 2.2snap, and 3.0snap with none of them working 100%. > >I have entered a PR and noticed that there has been no progress noted. > >Is there anything I can do to facilitate this? > >-- >Regards, >Jeff >mailto:jeff.kreska@mci.com > > > > -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Fri Jul 25 09:53:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12537 for hackers-outgoing; Fri, 25 Jul 1997 09:53:05 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA12531 for ; Fri, 25 Jul 1997 09:53:03 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wrnUv-0004Gb-00; Fri, 25 Jul 1997 09:45:45 -0700 Date: Fri, 25 Jul 1997 09:45:44 -0700 (PDT) From: Tom Samplonius To: Jeff Kreska cc: freebsd-hackers@freebsd.org Subject: Re: Adaptec 2940UW In-Reply-To: <33D89B59.9325CFF9@mci.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Jul 1997, Jeff Kreska wrote: > Is anybody working on resolving the problems with the Adapatec 2940. It > appears that the problems exist in all tree's. I have personaly used > the 2.1, latest 2.2snap, and 3.0snap with none of them working 100%. > > I have entered a PR and noticed that there has been no progress noted. > > Is there anything I can do to facilitate this? The Adaptec 2940UW works well. Exactly what snapshots did you use? > -- > Regards, > Jeff > mailto:jeff.kreska@mci.com > > > > Tom From owner-freebsd-hackers Fri Jul 25 10:17:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA13818 for hackers-outgoing; Fri, 25 Jul 1997 10:17:39 -0700 (PDT) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13811 for ; Fri, 25 Jul 1997 10:17:35 -0700 (PDT) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id KAA19296; Fri, 25 Jul 1997 10:17:16 -0700 (PDT) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Fri, 25 Jul 1997 10:17:16 -0700 (PDT) From: Curt Sampson To: Rod Ebrahimi cc: hackers@FreeBSD.ORG Subject: Re: Servers and Network In-Reply-To: <199707250915.CAA16119@netroplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Jul 1997, Rod Ebrahimi wrote: > ...main focus is WWW,FTP,TELNET. This is what I was looking at: > > Main Server: Dual PPro200, 256MB, Raid5 4.0gig scsi drives, 9" mono VGA > monitor > > ... is the main server overkill for WWW,FTP,TELNET? How many hundreds of users were you going to have using it simultaneously? I ran a 1500 user ISP on basically one 486/66 with 64 MB of RAM for quite some time. A little while after we exceeded 2000 users, 1.5 GB of mail per week, and 9 GB of web traffic per week, we upgraded to a P133 with 96 MB of RAM. This is quite comfortable, and fast. (We do have our news server on a separate machine, a P90.) I don't know how important money is to you, but if it is moderately important, you can probably think of better ways of spending the difference between a 128 MB P166 and a 256 MB dual PPro200. cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. From owner-freebsd-hackers Fri Jul 25 11:32:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA17222 for hackers-outgoing; Fri, 25 Jul 1997 11:32:42 -0700 (PDT) Received: from agni.nuko.com ([206.79.130.80]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA17217 for ; Fri, 25 Jul 1997 11:32:40 -0700 (PDT) Received: (from vinay@localhost) by agni.nuko.com (8.8.5/8.7.3) id LAA19660 for freebsd-hackers@freebsd.org; Fri, 25 Jul 1997 11:29:52 -0700 (PDT) From: Vinay Bannai Message-Id: <199707251829.LAA19660@agni.nuko.com> Subject: Where is cdevsw_add ?? To: freebsd-hackers@freebsd.org Date: Fri, 25 Jul 1997 11:29:52 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks I am trying to attach the upper half of my device driver to the cdevsw struct and most of the device drivers make a call to cdevsw_add() or bdevsw_add() to be included in the struct. Despite my etags and searches, I could not locate where cdevsw_add() or bdevsw_add() is defined? Is it a macro or a function?? Thanks Vinay -- Vinay Bannai E-mail: vinay@agni.nuko.com (408)-526-0280 x 275 (Work) http://agni.nuko.com/~vinay From owner-freebsd-hackers Fri Jul 25 12:06:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA18791 for hackers-outgoing; Fri, 25 Jul 1997 12:06:41 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA18785 for ; Fri, 25 Jul 1997 12:06:37 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id MAA18550; Fri, 25 Jul 1997 12:06:30 -0700 (PDT) To: "Jeff Kreska" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Adaptec 2940UW In-reply-to: Your message of "Fri, 25 Jul 1997 07:26:02 CDT." <33D89B59.9325CFF9@mci.com> Date: Fri, 25 Jul 1997 12:06:30 -0700 Message-ID: <18546.869857590@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is anybody working on resolving the problems with the Adapatec 2940. It > appears that the problems exist in all tree's. I have personaly used > the 2.1, latest 2.2snap, and 3.0snap with none of them working 100%. Odd - I'm having no problems with my 2940UWs at all. What was the PR#? Jordan From owner-freebsd-hackers Fri Jul 25 12:33:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA20004 for hackers-outgoing; Fri, 25 Jul 1997 12:33:12 -0700 (PDT) Received: from pegas.carrier.kiev.ua (root@pegas.carrier.kiev.ua [193.193.193.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19996 for ; Fri, 25 Jul 1997 12:32:59 -0700 (PDT) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101]) by pegas.carrier.kiev.ua (8.8.5/8.Who.Cares/Open) with ESMTP id WAA05571; Fri, 25 Jul 1997 22:43:55 +0300 (EEST) Received: (from uucp@localhost) by sivka.carrier.kiev.ua (8.8.6/8.8.6) with UUCP id WAA01437; Fri, 25 Jul 1997 22:31:48 +0300 (EEST) Received: from localhost (archer@localhost [127.0.0.1]) by grape.carrier.kiev.ua (8.8.6/8.8.6) with SMTP id VAA09448; Fri, 25 Jul 1997 21:42:06 +0300 (EEST) Date: Fri, 25 Jul 1997 21:42:03 +0300 (EEST) From: Alexander Litvin Reply-To: Alexander Litvin To: Andrzej Bialecki cc: freebsd-hackers@freebsd.org Subject: Re: Nvi and locale In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Jul 1997, Andrzej Bialecki wrote: > Hi! > > I can't get vi to properly display my national characters. As I read in > nvi docs, I should set my locale, so I did: > > setenv LANG C > setenv LC_CTYPE lt_LN.ISO-8859-1 <- from nvi docs (why ???) > > and it still prints all the special characters as \xf3 \xb6 and so on. > > What am I doing wrong? What I found is that setlocale in 2.2.x is not setting "partial" locale information when called as setlocale(LC_ALL,"") -- as it is called at the beginning of the most progs. E.g., I have "export LANG=ru_SU.KOI8-R", but I don't like to have dates displayed in Russian, so I setted also LC_TIME=ascii. But in such a case after setlocale(LC_ALL,"") I have all LC_xxxx set to C :-(, and nvi treats all that russian chars as non-printable. In 2.1.x that seems to work differently. > > > Sincerely yours, > > --- > Andrzej Bialecki FreeBSD: Turning PCs Into Workstations > http://www.freebsd.org > Research and Academic Network in Poland > -- Litvin Alexander No SIGNATURE available at this run-level From owner-freebsd-hackers Fri Jul 25 13:10:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA21989 for hackers-outgoing; Fri, 25 Jul 1997 13:10:37 -0700 (PDT) Received: from ns2.gamespot.com (ns2.gamespot.com [206.169.18.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA21984 for ; Fri, 25 Jul 1997 13:10:33 -0700 (PDT) Received: from tiramisu.gamespot.com (tiramisu.gamespot.com [206.169.18.119]) by ns2.gamespot.com (8.8.5/8.8.5) with SMTP id NAA13802 for ; Fri, 25 Jul 1997 13:10:29 -0700 (PDT) Message-Id: <3.0.3.32.19970725131201.00af1bf0@mail.gamespot.com> X-Sender: ian@mail.gamespot.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 25 Jul 1997 13:12:01 -0700 To: freebsd-hackers@FreeBSD.ORG From: Ian Kallen Subject: Re: mkisofs with long file names? In-Reply-To: <199707232153.QAA08794@milo.lodgenet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It turns out that the problem is that some of the recipients of this CD are using Wintel, which apparently does not read the translation table. When this burner is running on a wintel CPU, we burn iso9660 CD's with Corel's CD Creator and can select long file names... they are readable on wintel machines and mounted under Unix as iso9660 platters both displaying the long file names properly. Any idea what the difference between the flavors of iso9660 are and how to get mkisofs to use the flavor that the Corel software uses? thanks -Ian At 04:53 PM 7/23/97 -0500, John Prince wrote: >What options are you using with mkisofs?? >Where do the source file(s) currently live? >--John > >Ian Kallen writes: >> I tried adding the -l in the mkisofs line of Jordans lil makecdfs.sh script >> to gain retention of long file names. I want to burn a bunch of html onto >> a CD and 8.3 just won't work. DOS compatibility be damned, mkisofs still >> truncates the filenames and that just won't do. Suggestions? The machine >> I installed the cdr to is running 2.2-970618-RELENG. >> >> thanks! >> -Ian >> >> -- >> Ian Kallen ian@gamespot.com > >> Director of Technology and Web Administration >> SpotMedia Communications >> http://www.gamespot.com/ http://www.videogamespot.com/ > > > > > -- Ian Kallen ian@gamespot.com Director of Technology and Web Administration SpotMedia Communications http://www.gamespot.com/ http://www.videogamespot.com/ From owner-freebsd-hackers Fri Jul 25 13:11:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA22064 for hackers-outgoing; Fri, 25 Jul 1997 13:11:30 -0700 (PDT) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22055 for ; Fri, 25 Jul 1997 13:11:24 -0700 (PDT) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by trifork.gu.net (8.8.5/8.8.5) with SMTP id XAA01314 for ; Fri, 25 Jul 1997 23:03:25 +0300 (EEST) Date: Fri, 25 Jul 1997 23:03:25 +0300 (EEST) From: Andrew Stesin Reply-To: stesin@gu.net To: hackers@freebsd.org Subject: SVR4.2MP source code has become available recently? Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear FreeBSD hackers, I've hear rumors that the source code for SCO UnixWare 2.1.x is now available from SCO for $500 for educational institutions. Isn't this interesting as a reference? How do you think? Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Fri Jul 25 13:13:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA22129 for hackers-outgoing; Fri, 25 Jul 1997 13:13:07 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22124 for ; Fri, 25 Jul 1997 13:13:02 -0700 (PDT) Received: (from deischen@localhost) by iworks.InterWorks.org (8.7.5/) id PAA03765; Fri, 25 Jul 1997 15:17:17 -0500 (CDT) Message-Id: <199707252017.PAA03765@iworks.InterWorks.org> Date: Fri, 25 Jul 1997 15:17:17 -0500 (CDT) From: "Daniel M. Eischen" To: Jeff.Kreska@MCI.Com, hackers@FreeBSD.ORG Subject: Re: Adaptec 2940UW Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is anybody working on resolving the problems with the Adapatec 2940. It > appears that the problems exist in all tree's. I have personaly used > the 2.1, latest 2.2snap, and 3.0snap with none of them working 100%. And it's working perfectly with 2.2 (some version of stable) and 3.0-current for me. How about a more detailed description of your problem? I'm betting it's a cabling or termination problem. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-hackers Fri Jul 25 14:06:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24868 for hackers-outgoing; Fri, 25 Jul 1997 14:06:18 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA24863 for ; Fri, 25 Jul 1997 14:06:14 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id QAA00944; Fri, 25 Jul 1997 16:05:53 -0500 (EST) From: "John S. Dyson" Message-Id: <199707252105.QAA00944@dyson.iquest.net> Subject: Re: SVR4.2MP source code has become available recently? In-Reply-To: from Andrew Stesin at "Jul 25, 97 11:03:25 pm" To: stesin@gu.net Date: Fri, 25 Jul 1997 16:05:53 -0500 (EST) Cc: hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Dear FreeBSD hackers, > > I've hear rumors that the source code for SCO UnixWare 2.1.x > is now available from SCO for $500 for educational > institutions. > > Isn't this interesting as a reference? How do you think? > I have worked on the SVR4 codebase, and there isn't much to be learned there. The Solaris stuff would be a little bit more interesting. :-). John From owner-freebsd-hackers Fri Jul 25 14:20:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA25462 for hackers-outgoing; Fri, 25 Jul 1997 14:20:12 -0700 (PDT) Received: from trifork.gu.net (trifork.gu.net [194.93.190.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA25457; Fri, 25 Jul 1997 14:20:02 -0700 (PDT) Received: from localhost (localhost.gu.kiev.ua [127.0.0.1]) by trifork.gu.net (8.8.5/8.8.5) with SMTP id AAA01460; Sat, 26 Jul 1997 00:20:07 +0300 (EEST) Date: Sat, 26 Jul 1997 00:20:07 +0300 (EEST) From: Andrew Stesin Reply-To: stesin@gu.net To: dyson@FreeBSD.ORG cc: hackers@FreeBSD.ORG Subject: Re: SVR4.2MP source code has become available recently? In-Reply-To: <199707252105.QAA00944@dyson.iquest.net> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 25 Jul 1997, John S. Dyson wrote: > I have worked on the SVR4 codebase, and there isn't much > to be learned there. The Solaris stuff would be a little > bit more interesting. :-). Solaris source is also available for interested, isn't it? On UW. Solaris is SVR4.0 heavily modified by Sun, with SMP added by them independently; UW is SVR4.2 with SMP added by USL, am I right? So they might have some (in theory, at least) interesting differences with regard to SMP implementation? Then VXFS; binary compatibility stuff; drivers. SCO is dropping old SCO OpenServer aka SVR3, in favor of SVR4.2MP-based system, I think; for now it's UW. And they have some kind of "unified driver interface" spec for UW. How nice would it be -- to have an ability to use hardware vendor's own drivers for UW, compatible with that spec, just out of the box. Aaghh, dreams, dreams... :( > John > Best regards, Andrew Stesin nic-hdl: ST73-RIPE From owner-freebsd-hackers Fri Jul 25 14:38:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA26095 for hackers-outgoing; Fri, 25 Jul 1997 14:38:50 -0700 (PDT) Received: from gatekeeper.filoli.com (filoli.filoli.com [206.79.61.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA26088 for ; Fri, 25 Jul 1997 14:38:46 -0700 (PDT) Received: from sunspot.filoli.com (mailhost.filoli.com [204.162.1.17]) by gatekeeper.filoli.com (8.8.6/8.8.6) with ESMTP id OAA25869; Fri, 25 Jul 1997 14:38:42 -0700 (PDT) Received: from diamond.filoli.com (diamond [204.162.1.183]) by sunspot.filoli.com (8.8.5/8.8.6) with SMTP id OAA19753; Fri, 25 Jul 1997 14:38:41 -0700 (PDT) Message-Id: <199707252138.OAA19753@sunspot.filoli.com> Received: by diamond.filoli.com (NX5.67e/NX3.0X) id AA09690; Fri, 25 Jul 97 14:38:41 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <3.0.3.32.19970725131201.00af1bf0@mail.gamespot.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.118.2) From: Kevet Duncombe Date: Fri, 25 Jul 97 14:38:39 -0700 To: Ian Kallen Subject: Re: mkisofs with long file names? Cc: freebsd-hackers@FreeBSD.ORG References: <3.0.3.32.19970725131201.00af1bf0@mail.gamespot.com> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You wrote: > It turns out that the problem is that some of the recipients of > this CD are using Wintel, which apparently does not read the > translation table. When this burner is running on a wintel CPU, we > burn iso9660 CD's with Corel's CD Creator and can select long file > names... they are readable on wintel machines and mounted under > Unix as iso9660 platters both displaying the long file names > properly. Any idea what the difference between the flavors of > iso9660 are and how to get mkisofs to use the flavor that the Corel > software uses? thanks Wintel wants the Joliet extension, which consists of secondary volume descriptors using unicode characters. The last time I looked, along about 1.11, mkisofs didn't do Joliet. It should be pretty easy to add; I was toying with idea, but free time's been pretty scarce. Here is a URL for the Joliet spec in case your motivation is greater than mine... http://www.ms4music.com/devl/dvjoliet.htm From owner-freebsd-hackers Fri Jul 25 14:53:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA26719 for hackers-outgoing; Fri, 25 Jul 1997 14:53:33 -0700 (PDT) Received: from kaiwan.kaiwan.com (4@kaiwan.kaiwan.com [198.178.203.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA26689; Fri, 25 Jul 1997 14:53:18 -0700 (PDT) Received: from exit.com (uucp@localhost) by kaiwan.kaiwan.com (8.6.12/8.6.12) with UUCP id OAA04741; Fri, 25 Jul 1997 14:52:38 -0700 *** KAIWAN Internet Access *** Received: (from frank@localhost) by exit.com (8.8.5/8.7.3) id OAA02176; Fri, 25 Jul 1997 14:50:21 -0700 (PDT) From: Frank Mayhar Message-Id: <199707252150.OAA02176@exit.com> Subject: Re: SVR4.2MP source code has become available recently? To: stesin@gu.net Date: Fri, 25 Jul 1997 14:50:20 -0700 (PDT) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from Andrew Stesin at "Jul 26, 97 00:20:07 am" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew Stesin wrote: > On UW. Solaris is SVR4.0 heavily modified by Sun, > with SMP added by them independently; UW is SVR4.2 with > SMP added by USL, am I right? So they might have > some (in theory, at least) interesting differences with regard to > SMP implementation? Uh huh. Lots of good stuff there, even if only for an example of another way to do things. I personally prefer its SMP locking, but then I'm biased, having used it for a few years. > Then VXFS; binary compatibility stuff; drivers. I doubt that it includes vxfs, that's Veritas' baby, and a separate thing. I could be wrong, though. > SCO is dropping old SCO OpenServer aka SVR3, > in favor of SVR4.2MP-based system, I think; for now it's UW. > And they have some kind of "unified driver interface" spec for UW. > How nice would it be -- to have an ability to use hardware > vendor's own drivers for UW, compatible with that spec, > just out of the box. Aaghh, dreams, dreams... :( Unixware is basically heavily bug-fixed and enhanced SVR4.2ES/MP. -- Frank Mayhar frank@exit.com From owner-freebsd-hackers Fri Jul 25 22:20:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14787 for hackers-outgoing; Fri, 25 Jul 1997 22:20:15 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14782 for ; Fri, 25 Jul 1997 22:20:11 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA27326 for ; Fri, 25 Jul 1997 22:18:25 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd027323; Sat Jul 26 05:18:19 1997 Message-ID: <33D98827.28D95ABC@whistle.com> Date: Fri, 25 Jul 1997 22:16:23 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Off to the the UK for 1 week Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If there are any urgent problems due to stuff I've done in teh next 10 days, then I'll be back in circulation after the 5th I'm off th the UK for my brother's wedding. any brits liekly to be on my path? (London->Wales->Chester->London) I'll probably check mail again before mid-day GMT Saturday so get your bids in quickly :) julian From owner-freebsd-hackers Fri Jul 25 22:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14804 for hackers-outgoing; Fri, 25 Jul 1997 22:20:20 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14794 for ; Fri, 25 Jul 1997 22:20:16 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA27231; Fri, 25 Jul 1997 22:12:14 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd027227; Sat Jul 26 05:12:10 1997 Message-ID: <33D986B7.7A5F06AF@whistle.com> Date: Fri, 25 Jul 1997 22:10:15 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: "Jordan K. Hubbard" CC: hackers@freebsd.org Subject: Re: pccard and -current; a long way to go. :-( References: <20225.869879961@time.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard wrote: > > Well, I've been poking at this on and off for the last 2 days now and > I can say without too much fear of contradiction that getting pccard > support up in -current is no easy job. At least my pccardd no longer > bitches on startup, but it also fails to do anything. :-) > > I also have to seriously question Nate & Mike's assertions that all is > hunky-dory in 2.2.2 land. First off, my LINKSYS and AT&T modem cards > are _not_ supported with the stock 2.2.2 stuff, I've tried that nine > ways to Sunday, and even though upgrading to the latest and greatest > 2.2.2 bits gets me past the card recognition phase, there is still the > pccardd/ifconfig startup race which Nate claimed was not an issue. > Trust me - it's an issue! :-) > > So now I'm left somewhat befuddled as to the best approach to take > here. Normally, this stuff would be developed in -current and all the > new stuff tested there, but we don't _have_ working versions (at least > not that I could test with my available hardware) in -current, so > that's kind of a washout from my perspective. The state of the art > appears to have advanced to relative usability for me in 2.2.2+PAO, on > the other hand, but we don't check new stuff directly into RELENG_2_2 > so that route's kind of out too - I can get a working 2.2+ system out > of this, but it won't be much good from the perspective of advancing > development. > > I'm not sure how closely the Nomads want to work with the FreeBSD > Project on this, but if the answer is "not closely enough to support > -current" then I can see no other alternative but to pursue another, > totally new effort for solving the pccard issues in FreeBSD. > > Any answers? make a branch.. call it RELENG_LAPTOP_2_2 merge it there.. periodically do merges from 2.2 do the same for -current? > > Jordan From owner-freebsd-hackers Fri Jul 25 22:23:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14937 for hackers-outgoing; Fri, 25 Jul 1997 22:23:08 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14927 for ; Fri, 25 Jul 1997 22:23:03 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id WAA20865; Fri, 25 Jul 1997 22:22:39 -0700 (PDT) To: Julian Elischer cc: hackers@freebsd.org Subject: Re: pccard and -current; a long way to go. :-( In-reply-to: Your message of "Fri, 25 Jul 1997 22:10:15 PDT." <33D986B7.7A5F06AF@whistle.com> Date: Fri, 25 Jul 1997 22:22:39 -0700 Message-ID: <20861.869894559@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > make a branch.. > call it RELENG_LAPTOP_2_2 Eek! A branch-branch! I think that would be a first. :-) Hmmm. It's really not a bad idea though. Jordan From owner-freebsd-hackers Fri Jul 25 22:37:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA15532 for hackers-outgoing; Fri, 25 Jul 1997 22:37:46 -0700 (PDT) Received: from argus.tfs.net (pm3-p5.tfs.net [206.154.183.197]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA15526 for ; Fri, 25 Jul 1997 22:37:37 -0700 (PDT) Received: (from jbryant@localhost) by argus.tfs.net (8.8.5/8.8.5) id AAA00366; Sat, 26 Jul 1997 00:36:55 -0500 (CDT) From: Jim Bryant Message-Id: <199707260536.AAA00366@argus.tfs.net> Subject: Re: SVR4.2MP source code has become available recently? In-Reply-To: from Andrew Stesin at "Jul 25, 97 11:03:25 pm" To: stesin@gu.net Date: Sat, 26 Jul 1997 00:36:54 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-to: jbryant@tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > Dear FreeBSD hackers, > > I've hear rumors that the source code for SCO UnixWare 2.1.x > is now available from SCO for $500 for educational > institutions. > > Isn't this interesting as a reference? How do you think? well, it's nice to know how they are doing things, but we do have to keep things legal... i'm sure if this is the case, then the license will not allow the sources to be used in any other operating system, and can cause severe legal headaches for those who do. no more net-[12]... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" --------------------------------------------------------------------------- Internet: jbryant@tfs.net AX.25 Packet: kc5vdj@wv0t.#neks.ks.usa.noam voice: KC5VDJ - 6 Meters AM/FM/SSB, 2 Meters AM/FM/SSB, and 70cm FM. EM-29 From owner-freebsd-hackers Sat Jul 26 01:18:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA20269 for hackers-outgoing; Sat, 26 Jul 1997 01:18:10 -0700 (PDT) Received: from ns.cs.msu.su (root@redsun.cs.msu.su [158.250.10.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA20264 for ; Sat, 26 Jul 1997 01:18:06 -0700 (PDT) Received: from janus.msu.su (janus [158.250.17.20]) by ns.cs.msu.su (8.8.6/8.6.12) with SMTP id MAA14364 for ; Sat, 26 Jul 1997 12:18:20 +0400 (DST) Received: by janus.msu.su (SMI-8.6/SMI-SVR4) id MAA05176; Sat, 26 Jul 1997 12:18:17 +0400 Date: Sat, 26 Jul 1997 12:18:17 +0400 Message-Id: <199707260818.MAA05176@janus.msu.su> From: "Sergei S. Laskavy" To: freebsd-hackers@freebsd.org Subject: /bin/chio: why in /bin ? Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear FreeBSD hackers! I wonder why "mt", "tar" are in "/usr/bin" while chio is in "/bin". Sergei S. Laskavy From owner-freebsd-hackers Sat Jul 26 01:21:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA20407 for hackers-outgoing; Sat, 26 Jul 1997 01:21:41 -0700 (PDT) Received: from helbig.informatik.ba-stuttgart.de (rvc1.informatik.ba-stuttgart.de [141.31.112.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA20394 for ; Sat, 26 Jul 1997 01:21:34 -0700 (PDT) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.6/8.8.5) id KAA10500; Sat, 26 Jul 1997 10:11:46 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199707260811.KAA10500@helbig.informatik.ba-stuttgart.de> Subject: Re: Hello boys its me again. In-Reply-To: from Robin Carey at "Jul 25, 97 04:20:21 pm" To: r.carey@dcs.napier.ac.uk (Robin Carey) Date: Sat, 26 Jul 1997 10:11:43 +0200 (MET DST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Robin Carey writes: > Sorry for not send-pr'ing this ... I noticed this the other day: > > Basically you've got bzero(3) and bcopy(3) being used in > /usr/include/sys/types.h for the FD_ZERO() and FD_SET() macros, and you've > not included - or is it - never can tell with these > dodgy non-ANSI calls :) This results in a warning with gcc -Wall if you The FD_???? macros support the select(2) call. Both the bzero(3) and select(2) calls belong to the same compatibility class: Neither ANSI nor POSIX but BSD (and supported by other Unices that emulate (part of) BSD). There is no harm if one depends on the other and its desirable to provoke a warning if compiled with -ansi and -Wall. This warning would not be given if memset(3) is used instead. > don't accidentally include the right header before .... I'd > suggest changing them to memset(3) and memcpy(3) respectively, which are > ANSI and need . BTW Are those FD_*() macros meant to be in > ? I'd have thought would be a better place, but > thats just my warped sense of direction :) Your suggested change is gratituos and would break BSD compatibility. Instead we should add the ``#include '' clause to all man pages that have the ``#include '' line or make sys/types.h self sufficient to satisfy -Wall. Wolfgang PS cc changed from -bugs to -hackers. > > L8r. > From owner-freebsd-hackers Sat Jul 26 01:21:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA20448 for hackers-outgoing; Sat, 26 Jul 1997 01:21:59 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA20441 for ; Sat, 26 Jul 1997 01:21:53 -0700 (PDT) Received: (qmail 4625 invoked by uid 1000); 26 Jul 1997 08:22:07 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 26 Jul 1997 01:22:07 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: stesin@gu.net Subject: RE: SVR4.2MP source code has become available recently? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Andrew Stesin; On 25-Jul-97 you wrote: > > Dear FreeBSD hackers, > > I've hear rumors that the source code for SCO UnixWare 2.1.x > is now available from SCO for $500 for educational > institutions. > > Isn't this interesting as a reference? How do you think? It has a descent SMP implementation (Better than Solaris). The SCSI layer may be interesting. Used to have a nice desktop for X11 Simon From owner-freebsd-hackers Sat Jul 26 01:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA21391 for hackers-outgoing; Sat, 26 Jul 1997 01:57:06 -0700 (PDT) Received: from bugs.us.dell.com (bugs.us.dell.com [143.166.169.147]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA21386 for ; Sat, 26 Jul 1997 01:57:03 -0700 (PDT) Received: from ant.us.dell.com (ant.us.dell.com [198.64.66.34]) by bugs.us.dell.com (8.6.12/8.6.12) with SMTP id DAA04061; Sat, 26 Jul 1997 03:54:10 -0500 Message-Id: <3.0.2.32.19970726030630.00770428@bugs.us.dell.com> X-Sender: tony@bugs.us.dell.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Sat, 26 Jul 1997 03:06:30 -0500 To: Kazutaka YOKOTA From: Tony Overfield Subject: Re: psm and kbdio driver (was Re: Stuck! 2.2 Gamma won't go.) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199702150856.RAA23399@zodiac.mech.utsunomiya-u.ac.jp> References: <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970210022848.00691d20@bugs.us.dell.com> <3.0.1.32.19970210051554.006a2350@bugs.us.dell.com> <3.0.1.32.19970211001523.006a17b8@bugs.us.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [Long ago, Tony once volunteered to answer some questions. I had lost this message and only recently rediscovered it while cleaning up the entrails of a hard disk crash I recently suffered.] At 05:56 PM 2/15/97 +0900, Kazutaka YOKOTA wrote: >Thank you. Let's move to the freebsd-hackers list, as we are not quite >discussing a bug anymore. Sorry about quoting so much of the prior message, but I thought the context would be helpful. >Here are first bunch of questions. > >Before I beg you answers to my questions, I had better tell you my >source of information first, so that you can know how I learned the >basics of the keyboard, the PS/2 mouse and the keyboard controller. > >[1] Van Gilluwe, F.: "The Undocumented PC", Addison Wesley, 1994. >[2] Hogan, T.: "The Programmer's PC Sourcebook, 2nd Ed.", Microsoft > Press, 1991. >[3] Brown, R.: "Interrupt List". >[4] Phoenix Technologies Ltd.: "System BIOS for IBM PC/XT/AT Computers > and Compatibles", Addison Wesley, 1987. >[5] Logitech Inc.: "Logitech Mouse Technical Reference and Programmer's > Guide", 1992. > >I also use various magazine articles, English or Japanese. I don't have most of these references, so let me know if something I say doesn't agree with them, since one or both of us might be wrong. >No, I don't have a copy of "Technical Reference - Personal Computer AT" >from IBM. I know I should have one. It's a good reference for some things, but it's poor for this topic, since it doesn't cover the PS/2 mouse (auxiliary device) support. >But, is it still available? Good question. I don't know. >1. Internal buffer size >I understand that the AT keyboard (84/101) has an internal 16 byte >buffer. Yes, it is 16 bytes, though it's probably possible for this to vary. If the buffer is full and more data bytes need to be placed in the buffer, an overrun code (0x00) will be placed in the buffer instead (in the 17th byte position, if necessary) and it will be sent to the system after all the bytes already in the buffer are sent. >Does the PS/2 mouse have an internal buffer too? If so, how >large is it? I doubt it has one. But the mouse is not allowed to send partial packets, so you can be sure that you won't lose anything important. The mouse will accumulate X/Y data and button events even if it can't send data. This data will come out in the next packet as soon as the mouse can send again, though it's possible that repetitive mouse clicks might be lost if the mouse interface is disabled while you're clicking on the buttons. The last (current) state of the buttons will always be sent, so this doesn't really cause any problems. >Also, does the keyboard controller buffer data from the >keyboard and the mouse (I guess this is unlikely though)? It normally buffers exactly one byte. Some systems may buffer more, but you shouldn't be able to tell that. It should act like there is only a one-byte buffer. That byte can be either from the keyboard, from the mouse, or from the keyboard controller itself. >2. Response to the command >For most keyboard commands, the keyboard responds with ACK (0xfa). >When exactly is it sent back? Suppose a data byte is waiting in the >keyboard internal buffer to be transmitted to the system, then a >command arrives. Will ACK be sent back before or after the data byte? The ACK will come out first, followed later by the data byte(s). >The keyboard often sends two or more bytes for a single key make/break >event. What if a command arrives after the first byte has been sent >but before the second byte. Will ACK be sent before the second byte? Yes, the ACK will be sent first, but there is a race condition such that it's possible for the second byte to arrive just as you place the command into the keyboard controller. It will look like you got a quick response from the keyboard, but it's just a data byte. You have to accept this data byte (or let the interrupt handler take it). The ACK will then be the next byte. However, this confusion should never happen, since the the normal way to issue commands to the keyboard is to first send a disable keyboard command (0xAD), and then send the command. The command/response will automatically reenable the interface and the ACK (or the response) will arrive first. Then the keyboard data will start arriving again. Some systems may require the (0xAE) command to start receiving data from the keyboard again. This method eliminates the possibility of confusing the command response data bytes with ordinary key press data bytes. >What should I do to the first byte already received? Should I discard >it (because the first byte will be sent again?), or save it so that I >can use it together with the second byte which will be later received? You must save it since it won't be sent again. You should discard the ACK bytes instead. The typical interrupt handler just swallows ACK bytes after setting a global status bit. The status bit can be checked by code that wishes to know if an ACK byte has come back. >The system can interrupt data transmission from the keyboard in the >midst of a byte, by bringing the CLOCK line down. In such case, will >the keyboard try to re-send the interrupted byte later? Yes, but only if you catch it in time. It will either appear in the output buffer (which means you didn't turn it off soon enough), or it will appear later, after you've enabled the interface again. You can't lose a byte, though. >As for the PS/2 mouse, the Logitech Mouse Technical Reference is >explicit about such circumstances; ACK will be sent immediately. If a >command from the system interrupt a data packet from the mouse in the >middle, the transmission of the data packet is aborted, and the system >should discard data already received. The mouse will send the complete >data packet again after the ACK. Yes, the ACK is always sent immediately. I don't know if the whole packet is discarded (it sounds wrong to me), but it is strange to send commands in the middle of a packet anyway, so I haven't seen this situation occur. >3. Reset >For the reset command (0xff), the keyboard responds with ACK and a >result code (0xaa). The mouse responds with ACK, a result code and an >device ID. I learned that the reset action takes a long, long time, >and the keyboard/mouse driver has to exercise a long delay before >attempting to read response from the device. The duration of necessary >delay varies from one system to another (though, I have the impression >the keyboard reset takes longer than the mouse reset...). So, we need >go give sufficient margin to the delay. Is there standard or >semi-standard or practical value for this duration? The ACK is sent quickly (about 20 ms) but the reset itself is specified to take between 300 ms and 500 ms for the 101 key keyboard, and up to 900 ms for the 84 key keyboard. I'd extend the wait up to about two or three seconds just to be sure. There's probably no need to wait for this; a simple state machine will work. In fact, there's normally no need to send a reset command at all. >And when exactly should I wait? I have found many keyboard and mice >return ACK immediately and takes their own sweet time to reset itself, That's because the device responds to the reset command with an ACK before it starts the reset operation. The ACK means it accepted the command, not that it finished it. >so I do "send RESET - receive ACK - wait (up to a few hundred msec) - >receive a result code". But, I recently learned that I need to wait >before ACK for the built-in mouse device in some laptops. Well, it *should* return the ACK quickly. You should probably just poll for (or wait for interrupts from) the data bytes as they come in, and time out in a couple seconds if you don't get them all. This way, it doesn't matter where the delay is in relation to the individual return bytes. >I would be grateful if you could shed some light on these questions. > >Kazu Let me know if you want more detailed information. Tony From owner-freebsd-hackers Sat Jul 26 02:45:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA22758 for hackers-outgoing; Sat, 26 Jul 1997 02:45:09 -0700 (PDT) Received: from mexico.brainstorm.eu.org (mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA22736 for ; Sat, 26 Jul 1997 02:45:00 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id LAA05449 for ; Sat, 26 Jul 1997 11:44:39 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id LAA24633 for freebsd-hackers@FreeBSD.ORG; Sat, 26 Jul 1997 11:44:09 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.6/keltia-uucp-2.9) id LAA24351; Sat, 26 Jul 1997 11:37:34 +0200 (CEST) Message-ID: <19970726113734.28396@keltia.freenix.fr> Date: Sat, 26 Jul 1997 11:37:34 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: Nvi and locale References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Andrzej Bialecki on Fri, Jul 25, 1997 at 11:21:09AM +0200 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3481 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Andrzej Bialecki: > setenv LANG C > setenv LC_CTYPE lt_LN.ISO-8859-1 <- from nvi docs (why ???) Try using setenv LANG lt_LN.ISO_8859-1 instead. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #23: Sun Jul 20 18:10:34 CEST 1997 From owner-freebsd-hackers Sat Jul 26 05:59:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA29243 for hackers-outgoing; Sat, 26 Jul 1997 05:59:03 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA29238 for ; Sat, 26 Jul 1997 05:59:00 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id GAA23892; Sat, 26 Jul 1997 06:58:07 -0600 (MDT) Message-Id: <199707261258.GAA23892@pluto.plutotech.com> To: "Sergei S. Laskavy" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-reply-to: Your message of "Sat, 26 Jul 1997 12:18:17 +0400." <199707260818.MAA05176@janus.msu.su> Date: Sat, 26 Jul 1997 06:58:07 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Dear FreeBSD hackers! > >I wonder why "mt", "tar" are in "/usr/bin" while chio is in "/bin". > >Sergei S. Laskavy Because you may need it in order to do a restore. Restore is in /sbin. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Jul 26 06:09:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA29668 for hackers-outgoing; Sat, 26 Jul 1997 06:09:55 -0700 (PDT) Received: from ns.cs.msu.su (root@redsun.cs.msu.su [158.250.10.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA29662 for ; Sat, 26 Jul 1997 06:09:48 -0700 (PDT) Received: from janus.msu.su (janus [158.250.17.20]) by ns.cs.msu.su (8.8.6/8.6.12) with SMTP id RAA16671; Sat, 26 Jul 1997 17:10:06 +0400 (DST) Received: by janus.msu.su (SMI-8.6/SMI-SVR4) id RAA05708; Sat, 26 Jul 1997 17:10:03 +0400 Date: Sat, 26 Jul 1997 17:10:03 +0400 From: laskavy@cs.msu.su (Sergei S. Laskavy) Message-Id: <199707261310.RAA05708@janus.msu.su> To: gibbs@plutotech.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? [/usr/bin/mt] Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk L> I wonder why "mt", "tar" are in "/usr/bin" while chio is in "/bin". G> Because you may need it in order to do a restore. But... I think, usually on one tape there are many dumps. Why "mt" is not in "/bin" then? Sergei S. Laskavy From owner-freebsd-hackers Sat Jul 26 06:21:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA29996 for hackers-outgoing; Sat, 26 Jul 1997 06:21:25 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA29990 for ; Sat, 26 Jul 1997 06:21:17 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id HAA24249; Sat, 26 Jul 1997 07:20:36 -0600 (MDT) Message-Id: <199707261320.HAA24249@pluto.plutotech.com> To: laskavy@cs.msu.su (Sergei S. Laskavy) cc: gibbs@plutotech.com, freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? [/usr/bin/mt] In-reply-to: Your message of "Sat, 26 Jul 1997 17:10:03 +0400." <199707261310.RAA05708@janus.msu.su> Date: Sat, 26 Jul 1997 07:20:36 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >L> I wonder why "mt", "tar" are in "/usr/bin" while chio is in "/bin". > >G> Because you may need it in order to do a restore. > >But... I think, usually on one tape there are many dumps. >Why "mt" is not in "/bin" then? Because restore allows you to read from any file on the tape. Look at the -s option in the restore man page. >Sergei S. Laskavy -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Jul 26 08:00:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA02862 for hackers-outgoing; Sat, 26 Jul 1997 08:00:50 -0700 (PDT) Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA02857 for ; Sat, 26 Jul 1997 08:00:48 -0700 (PDT) Received: from castor.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA14047; Sat, 26 Jul 97 11:00:46 EDT Received: by castor.gel.usherb.ca (SMI-8.6/SMI-SVR4) id LAA13984; Sat, 26 Jul 1997 11:00:45 -0400 Date: Sat, 26 Jul 1997 11:00:44 -0400 (EDT) From: "Alex.Boisvert" To: freebsd-hackers@freebsd.org Subject: gdb and shared libraries Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all hackers - I'm trying to port the JDK 1.1.2 to FreeBSD and I am having a few difficulties with shared libraries. The VM gets a segmentation faults when going through the _GLOBAL_OFFSET_TABLE_ to execute a function in a dynamic library (in this case, libawt_g.so). The libawt_g.so library is loaded via a dlopen() call. In gdb, I get the following output after the library is loaded and the VM crashed: ---- cut here ----- Program received signal SIGSEGV, Segmentation fault. 0x0 in ?? () (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0x0807a000 0x0808a000 Yes /usr/libexec/ld.so 0x08091000 0x080ab000 Yes /usr/lib/libm.so.2.0 0x080aa000 0x081a5434 Yes /usr/X11R6/lib/libXm.so.1.2 0x081a5000 0x081e7000 Yes /usr/X11R6/lib/libXt.so.6.0 0x081e6000 0x081f0000 Yes /usr/X11R6/lib/libXext.so.6.1 0x081ef000 0x082851a0 Yes /usr/X11R6/lib/libX11.so.6.1 0x08285000 0x082ef710 Yes /usr/lib/libc.so.3.0 0x09403000 0x0946552c No /home/alex/jdk/javasrc/build/lib/i386/green_threads/libawt_g.so (gdb) ------ cut here ------ Notice the "No" for libawt_g.so in the column "Syms Read". What does this mean??? Have I forgotten to do something after dlopen()? Regards, Alex. PS: I am using dlsym() to get the address of the function. From owner-freebsd-hackers Sat Jul 26 08:32:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04113 for hackers-outgoing; Sat, 26 Jul 1997 08:32:29 -0700 (PDT) Received: from caesar.elte.hu (caesar.elte.hu [157.181.42.42]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA04092 for ; Sat, 26 Jul 1997 08:32:07 -0700 (PDT) Received: from localhost by caesar.elte.hu (AIX 3.2/UCB 5.64/4.03) id AA22760; Sat, 26 Jul 1997 17:29:51 +0200 Date: Sat, 26 Jul 1997 17:29:51 +0200 (METDST) From: MEMPHISTO To: freebsd-hackers@freebsd.org Subject: CD-ROM data tracks Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'd just like to know how can I check if a track on a CD is data or audio track?(via ioctl, of course). I'm not subscribed on this mailing list, so please mail me privately. Thanks in advance -------------------------------------------------------------------------------- Sebestyen Zoltan It all seems so stupid, it makes me want to give up. szoli@caesar.elte.hu But why should I give up, when it all seems so stupid? From owner-freebsd-hackers Sat Jul 26 09:37:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA06609 for hackers-outgoing; Sat, 26 Jul 1997 09:37:01 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA06604 for ; Sat, 26 Jul 1997 09:36:57 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.6/8.8.5) id UAA01104; Sat, 26 Jul 1997 20:36:10 +0400 (MSD) Date: Sat, 26 Jul 1997 20:35:46 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: "Justin T. Gibbs" cc: "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-Reply-To: <199707261258.GAA23892@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, Justin T. Gibbs wrote: > >Dear FreeBSD hackers! > > > >I wonder why "mt", "tar" are in "/usr/bin" while chio is in "/bin". > > > >Sergei S. Laskavy > > Because you may need it in order to do a restore. > > Restore is in /sbin. I ask to move chio to /sbin already long time ago, but in vain... -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Jul 26 11:21:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA11354 for hackers-outgoing; Sat, 26 Jul 1997 11:21:04 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [194.151.74.97]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA11349 for ; Sat, 26 Jul 1997 11:21:00 -0700 (PDT) Received: (from guido@localhost) by gvr.win.tue.nl (8.8.6/8.8.2) id UAA01836; Sat, 26 Jul 1997 20:20:19 +0200 (MET DST) From: Guido van Rooij Message-Id: <199707261820.UAA01836@gvr.win.tue.nl> Subject: Re: Iomega Zip In-Reply-To: <199707190450.VAA06500@hub.freebsd.org> from Darren Reed at "Jul 19, 97 02:38:54 pm" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Sat, 26 Jul 1997 20:20:19 +0200 (MET DST) Cc: hlew@www2.shoppersnet.com, rb@gid.co.uk, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Darren Reed wrote: > > Well, 2.2.1 detects neither ZIP or JAZ with recognised SCSI cards. > Jul 19 14:33:20 freebsd /kernel: ahc0 > rev 0 int a irq 9 on pci0:12 > Jul 19 14:33:20 freebsd /kernel: ahc0: Using left over BIOS settings > Jul 19 14:33:20 freebsd /kernel: ahc0: aic7880 sxfrctl1 == 0x1 > Jul 19 14:33:20 freebsd /kernel: Wide Channel, SCSI Id=7, 16 SCBs > Jul 19 14:33:20 freebsd /kernel: ahc0 waiting for scsi devices to settle > Jul 19 14:33:20 freebsd /kernel: (ahc0:4:0): "iomega jaz 1GB J^77" type 0 remova > ble SCSI 2 > Jul 19 14:33:20 freebsd /kernel: sd0(ahc0:4:0): Direct-Access > Jul 19 14:33:20 freebsd /kernel: sd0(ahc0:4:0): ILLEGAL REQUEST asc:24,0 Invalid > field in CDB > Jul 19 14:33:20 freebsd /kernel: sd0 could not mode sense (4). Using ficticious > geometry This is harmless. If you don;t want these, use the od driver. -Guido From owner-freebsd-hackers Sat Jul 26 12:26:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA14776 for hackers-outgoing; Sat, 26 Jul 1997 12:26:20 -0700 (PDT) Received: from acromail.ml.org (acroal.vip.best.com [206.86.222.181]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA14769 for ; Sat, 26 Jul 1997 12:26:16 -0700 (PDT) Received: from localhost (kernel@localhost) by acromail.ml.org (8.8.6/8.8.5) with SMTP id MAA09834; Sat, 26 Jul 1997 12:26:27 -0700 (PDT) Date: Sat, 26 Jul 1997 12:26:27 -0700 (PDT) From: FreeBSD Technical Reader To: Dan Janowski cc: hackers Subject: Re: ipfw divert, transparent proxy In-Reply-To: <33D6E265.46DEFC7@3skel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk natd is the tool you are looking for -- unfortunately I was running it on my machine and it would cause a reboot every 10 to 15 minutes. On Thu, 24 Jul 1997, Dan Janowski wrote: > I am replacing an old TIS firewall that has one very > interesting feature that I am looking to provide with my > FreeBSD 2.2.2 box. It is this: > > They use ipfs which has the capability of "transparently" doing > packet re-rerouting and, thereby, proxy transparently. > > (This is my understanding from looking at the config for > about five minutes) > > With the TIS firewall set as a client's default router, > this "transparent" mechanism will take a packet that is > destined for x.x.x.x:port, where x.x.x.x is an exterior > Internet address, and essentially drop the IP address and > deliver the packet to the local "port". > > This has some limited usefulness. Some services, like whois, > that always go to the InterNIC can be automatically proxied. > In this particular case, AOL (yuck) is the problem. There is no > proxying for AOL's client, but this transparent mechanism works > very well. > > How can I do this? I know that the current ipfw supports divert > sockets, but I don't see any references to a general purpose > proxy (like plug-gw) that supports diverts. Delegate does application > proxy, but I don't see divert support there. > > Any hints? > > Thanks, > > Dan > > -- > danj@3skel.com > Dan Janowski > Triskelion Systems, Inc. > Bronx, NY > From owner-freebsd-hackers Sat Jul 26 12:32:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA15457 for hackers-outgoing; Sat, 26 Jul 1997 12:32:31 -0700 (PDT) Received: from acromail.ml.org (acroal.vip.best.com [206.86.222.181]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA15452 for ; Sat, 26 Jul 1997 12:32:28 -0700 (PDT) Received: from localhost (kernel@localhost) by acromail.ml.org (8.8.6/8.8.5) with SMTP id MAA09871; Sat, 26 Jul 1997 12:32:31 -0700 (PDT) Date: Sat, 26 Jul 1997 12:32:31 -0700 (PDT) From: FreeBSD Technical Reader To: "Daniel O'Callaghan" cc: Dan Janowski , hackers Subject: Re: ipfw divert, transparent proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I know I could be banned for life for saying this --- but you could also use a linux machine and the ipmasquerading built into the kernel for doing this, there are no equivalent features in FreeBSD and it works much better than natd (Ipmasquerading is one of the things i miss from linux). Please forgive me for this sin. On Thu, 24 Jul 1997, Daniel O'Callaghan wrote: > On Thu, 24 Jul 1997, Dan Janowski wrote: > > > I am replacing an old TIS firewall that has one very > > interesting feature that I am looking to provide with my > > FreeBSD 2.2.2 box. It is this: > > > > They use ipfs which has the capability of "transparently" doing > > packet re-rerouting and, thereby, proxy transparently. > > It is a nice feature, and divert sockets is the way to do it in FreeBSD, > but it has not been done yet. got half-way through > a transparent http proxy using divert sockets, but did a tcpdump analysis > of his customers' traffic and found that < 1% were not using the proxy, > so he did not bother finishing the code (too busy on paying work). > > Danny > From owner-freebsd-hackers Sat Jul 26 12:33:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA15492 for hackers-outgoing; Sat, 26 Jul 1997 12:33:14 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA15485; Sat, 26 Jul 1997 12:33:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02880; Sat, 26 Jul 1997 12:32:29 -0700 From: Terry Lambert Message-Id: <199707261932.MAA02880@phaeton.artisoft.com> Subject: Re: SVR4.2MP source code has become available recently? To: dyson@FreeBSD.ORG Date: Sat, 26 Jul 1997 12:32:29 -0700 (MST) Cc: stesin@gu.net, hackers@FreeBSD.ORG In-Reply-To: <199707252105.QAA00944@dyson.iquest.net> from "John S. Dyson" at Jul 25, 97 04:05:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've hear rumors that the source code for SCO UnixWare 2.1.x > > is now available from SCO for $500 for educational > > institutions. > > > > Isn't this interesting as a reference? How do you think? > > I have worked on the SVR4 codebase, and there isn't much > to be learned there. The Solaris stuff would be a little > bit more interesting. :-). The VM code is nearly identical, for what it's worth. It was part of the technology trade between Sun and USL. I believe the FS SMP locking in Solaris is actually done at the wrong level. The SVR4 ES/MP 4.0.2 based SMP code from Unisys did it the right way. The SVR4 code in UnixWare 2.x used the Sun model (with a bit fewer macro encapsulations; the Sun implementation is more aesthetically pleasing), which makes it hard to use SMP unsafe FS's on Solaris (making it a bugger to incrementally transition code). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Jul 26 12:35:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA15657 for hackers-outgoing; Sat, 26 Jul 1997 12:35:26 -0700 (PDT) Received: from acromail.ml.org (acroal.vip.best.com [206.86.222.181]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA15630 for ; Sat, 26 Jul 1997 12:35:21 -0700 (PDT) Received: from localhost (kernel@localhost) by acromail.ml.org (8.8.6/8.8.5) with SMTP id MAA09891; Sat, 26 Jul 1997 12:35:24 -0700 (PDT) Date: Sat, 26 Jul 1997 12:35:24 -0700 (PDT) From: FreeBSD Technical Reader To: Tom Samplonius cc: hackers@FreeBSD.ORG Subject: Re: annoyed at login.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk login.conf is actually a very big annoyance since you have to configure it with default entries just so that login doesn't complain to syslog. On Thu, 24 Jul 1997, Tom Samplonius wrote: > > login.conf isn't that useful. Users who are trying to avoid resource > limits can simply have "at", or "cron" start jobs for them, since neither > "atrun" or "cron" set the users resource limits before starting the job. > They should. > > Tom > > From owner-freebsd-hackers Sat Jul 26 12:45:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16234 for hackers-outgoing; Sat, 26 Jul 1997 12:45:41 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA16224; Sat, 26 Jul 1997 12:45:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02911; Sat, 26 Jul 1997 12:44:29 -0700 From: Terry Lambert Message-Id: <199707261944.MAA02911@phaeton.artisoft.com> Subject: Re: SVR4.2MP source code has become available recently? To: stesin@gu.net Date: Sat, 26 Jul 1997 12:44:29 -0700 (MST) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Andrew Stesin" at Jul 26, 97 00:20:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On UW. Solaris is SVR4.0 heavily modified by Sun, > with SMP added by them independently; UW is SVR4.2 with > SMP added by USL, am I right? So they might have > some (in theory, at least) interesting differences with regard to > SMP implementation? Not as much as you'd imagine. It's basically differences in wrapping, more than anything else (ie: cosmetic). > Then VXFS; binary compatibility stuff; drivers. The VXFS belongs to Veritas, and is not relicensed. For what that's worth, all of the VXFS directory code is USL UFS derived (and it has USL copyright notices all over it). The binary compatability stuff is... "different". With the exception of enabling alrentate processor instruction sets in Solaris implementation (it uses an external program to do the deed for SunOS compatability), they are nearly identical. The x86 stuff is about the same (both have SCO and Microsoft copyrights all over the place). All in all, I would say it is inferior to either BSD approach that is out there; the instruction set stuff can be handled rather easily on BSD by trapping at the system call level (at least for BSD's that didn't follow Linux's lead on register paramter passing to system calls, making the ABI dependent on wordsize). Basically, it's no different than deciding to load an "interpreter". The program mmap's the executable into it's address space as data, and then "executes" the code via simulation. For system calls, the conversion from the emulated to the local is rather trivial (there are a number of issues regarding non-native x86 binaries being run on non-x86 architectures; they require either duping the system call conversion glue for the execution class in the user space simulator, or seperate simulators to invoke seperate system call lists still in the kernel). > SCO is dropping old SCO OpenServer aka SVR3, > in favor of SVR4.2MP-based system, I think; for now it's UW. > And they have some kind of "unified driver interface" spec for UW. > How nice would it be -- to have an ability to use hardware > vendor's own drivers for UW, compatible with that spec, > just out of the box. Aaghh, dreams, dreams... :( The net drivers are ODI. The ODI spec is available from Novell (if they think you are a card vendor) or from USU via anonymous FTP off their NetWare archive. Personally, I would not recommend using ODI; the ODI drivers lost 8-15% (depending on the card) over the native UNIX drivers they replaced. In addition, they added a streams stack transition (not an issue for BSD, I know) for inbound packet puts, which added an additional 7% latency. This was determined using formal testing methods, in Novell labs. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Jul 26 12:48:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16464 for hackers-outgoing; Sat, 26 Jul 1997 12:48:59 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA16455 for ; Sat, 26 Jul 1997 12:48:56 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id MAA27138; Sat, 26 Jul 1997 12:48:39 -0700 (PDT) Date: Sat, 26 Jul 1997 12:48:39 -0700 (PDT) From: "J. Utz" To: FreeBSD Technical Reader cc: Dan Janowski , hackers Subject: Re: ipfw divert, transparent proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hi And the reason u cant use ppp -alias is that this is not a phone line connection... right? john On Sat, 26 Jul 1997, FreeBSD Technical Reader wrote: > > natd is the tool you are looking for -- unfortunately I was running it on > my machine and it would cause a reboot every 10 to 15 minutes. > > On Thu, 24 Jul 1997, Dan Janowski wrote: > > > I am replacing an old TIS firewall that has one very > > interesting feature that I am looking to provide with my > > FreeBSD 2.2.2 box. It is this: > > > > They use ipfs which has the capability of "transparently" doing > > packet re-rerouting and, thereby, proxy transparently. > > > > (This is my understanding from looking at the config for > > about five minutes) > > > > With the TIS firewall set as a client's default router, > > this "transparent" mechanism will take a packet that is > > destined for x.x.x.x:port, where x.x.x.x is an exterior > > Internet address, and essentially drop the IP address and > > deliver the packet to the local "port". > > > > This has some limited usefulness. Some services, like whois, > > that always go to the InterNIC can be automatically proxied. > > In this particular case, AOL (yuck) is the problem. There is no > > proxying for AOL's client, but this transparent mechanism works > > very well. > > > > How can I do this? I know that the current ipfw supports divert > > sockets, but I don't see any references to a general purpose > > proxy (like plug-gw) that supports diverts. Delegate does application > > proxy, but I don't see divert support there. > > > > Any hints? > > > > Thanks, > > > > Dan > > > > -- > > danj@3skel.com > > Dan Janowski > > Triskelion Systems, Inc. > > Bronx, NY > > > > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-hackers Sat Jul 26 12:51:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16629 for hackers-outgoing; Sat, 26 Jul 1997 12:51:04 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA16623 for ; Sat, 26 Jul 1997 12:51:02 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id PAA00848; Sat, 26 Jul 1997 15:50:48 -0400 (EDT) Message-Id: <199707261950.PAA00848@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: /bin/chio: why in /bin ? References: In-reply-to: Your message of "Sat, 26 Jul 1997 20:35:46 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 15:50:48 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I ask to move chio to /sbin already long time ago, but in vain... Why move it? mt is in /usr/bin/mt and is used by other than just system admin people to do tape stuff. chio is in /bin/chio, and is used by those same people. From owner-freebsd-hackers Sat Jul 26 12:59:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA17075 for hackers-outgoing; Sat, 26 Jul 1997 12:59:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA17070 for ; Sat, 26 Jul 1997 12:59:30 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02939; Sat, 26 Jul 1997 12:58:22 -0700 From: Terry Lambert Message-Id: <199707261958.MAA02939@phaeton.artisoft.com> Subject: Re: SVR4.2MP source code has become available recently? To: Shimon@i-Connect.Net (Simon Shapiro) Date: Sat, 26 Jul 1997 12:58:22 -0700 (MST) Cc: stesin@gu.net, hackers@FreeBSD.ORG In-Reply-To: from "Simon Shapiro" at Jul 26, 97 01:22:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [ ... UnixWare ... ] > It has a descent SMP implementation (Better than Solaris). > The SCSI layer may be interesting. > Used to have a nice desktop for X11 Ugh. The SMP implementation *is* "better"... quoted because it is more x86 dependent tha the Solaris stuff. Personally, I'd use the Solaris model, if only for hardware compatability, if I had the choice to make, and if doing so would not infringe trade secrets and copyrights, and risk contamination. Remember that both these source bases are *licensed*, not freely usable. The UnixWare SCSI layer probably excludes the HIM-derived code for the Adaptec controllers, which is about the only thing that I found interesting about the code. Honestly, Julian's code was better than UnixWare's at the time. The X11 desktop was only nice in that it was an OpenLook with hacks to let it have a Motif "look and feel", and let you switch between them. Like all compromise soloutions, it was vastly disliked. The major reason the desktop was shipped was "Not Invented Here" for CDE and Visix Looking Glass. This type of crap is why UnixWare never succeeded in the desktop market. Most of the driving forces behind the UnixWare developement, which mainly occurred at Univel, a partnership between AT&T and Novell, before Novell bought USL and owned it all themselves, were people like Gary Tomlinson and Brian Sparks. If that second name is familiar, it should be: Brian Sparks was the person behind the original NetWare for UNIX product, and through it, the genesis of the Platform Independent NetWare code (a derivitive of his idea, not something he personally did; it was, IMO, inferior to the NetWare for UNIX code in many ways, and ended up being pulled into the mainline NetWare -- an unfortunate occurance). Brian Sparks is also the guy behind the Novell project to build a desktop OS based on Linux (internally, they were called "Linivel"), and eventually went on to be the principle founder of Caldera when the internal project was killed for fear of it damaging UnixWare sales (UnixWare has a rather large footprint). The shitty UnixWare desktop that could not be replaced because it was USL technology was IMO, one of the straws that broke the camels back; I would not recommend getting the code... let it die in peace. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Jul 26 13:19:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA18406 for hackers-outgoing; Sat, 26 Jul 1997 13:19:24 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18381 for ; Sat, 26 Jul 1997 13:19:15 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.6/8.8.5) id AAA01406; Sun, 27 Jul 1997 00:19:09 +0400 (MSD) Date: Sun, 27 Jul 1997 00:19:08 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "Louis A. Mamakos" cc: "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-Reply-To: <199707261950.PAA00848@whizzo.TransSys.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, Louis A. Mamakos wrote: > > I ask to move chio to /sbin already long time ago, but in vain... > > Why move it? mt is in /usr/bin/mt and is used by other than just > system admin people to do tape stuff. chio is in /bin/chio, and is > used by those same people. /bin not supposed to have machine-dependent stuff, /sbin exists for this purpose. chio is clearly machine-dependent. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Jul 26 13:25:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA18850 for hackers-outgoing; Sat, 26 Jul 1997 13:25:58 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18844 for ; Sat, 26 Jul 1997 13:25:52 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id QAA06505; Sat, 26 Jul 1997 16:25:38 -0400 (EDT) Message-Id: <199707262025.QAA06505@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: /bin/chio: why in /bin ? References: In-reply-to: Your message of "Sun, 27 Jul 1997 00:19:08 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 16:25:37 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk chio is not clearly machine dependent. It talks to any SCSI media changer device, just like mt works with any SCSI tape device. louie > /bin not supposed to have machine-dependent stuff, /sbin exists for this > purpose. chio is clearly machine-dependent. > > -- > Andrey A. Chernov > > http://www.nagual.pp.ru/~ache/ > From owner-freebsd-hackers Sat Jul 26 13:30:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA19221 for hackers-outgoing; Sat, 26 Jul 1997 13:30:12 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA19216 for ; Sat, 26 Jul 1997 13:30:09 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.6/8.8.5) id AAA01641; Sun, 27 Jul 1997 00:29:58 +0400 (MSD) Date: Sun, 27 Jul 1997 00:29:58 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "Louis A. Mamakos" cc: "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-Reply-To: <199707262025.QAA06505@whizzo.TransSys.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, Louis A. Mamakos wrote: > chio is not clearly machine dependent. It talks to any SCSI media > changer device, just like mt works with any SCSI tape device. Your words are in conflict: you talk about "not machine dependent" and "SCSI device". Any phisical device which not exist for all machines (like memory f.e.) IS machine dependance. SCSI not exist for all machines. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Jul 26 14:04:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20323 for hackers-outgoing; Sat, 26 Jul 1997 14:04:19 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20318 for ; Sat, 26 Jul 1997 14:04:15 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wsDtX-0005P5-00; Sat, 26 Jul 1997 13:56:55 -0700 Date: Sat, 26 Jul 1997 13:56:54 -0700 (PDT) From: Tom Samplonius To: FreeBSD Technical Reader cc: hackers@freebsd.org Subject: Re: annoyed at login.conf In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, FreeBSD Technical Reader wrote: > login.conf is actually a very big annoyance since you have to configure it > with default entries just so that login doesn't complain to syslog. No, just use the default login.conf Tom From owner-freebsd-hackers Sat Jul 26 14:23:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20909 for hackers-outgoing; Sat, 26 Jul 1997 14:23:42 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20904 for ; Sat, 26 Jul 1997 14:23:38 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id RAA18551; Sat, 26 Jul 1997 17:23:30 -0400 (EDT) Message-Id: <199707262123.RAA18551@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: /bin/chio: why in /bin ? References: In-reply-to: Your message of "Sun, 27 Jul 1997 00:29:58 +0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 17:23:29 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sat, 26 Jul 1997, Louis A. Mamakos wrote: > > > chio is not clearly machine dependent. It talks to any SCSI media > > changer device, just like mt works with any SCSI tape device. > > Your words are in conflict: you talk about "not machine dependent" > and "SCSI device". Any phisical device which not exist for all machines > (like memory f.e.) IS machine dependance. SCSI not exist for all machines. So what other types of tape drives are likely to be installed on a FreeBSD system? Or media changes? Ones hung off the floppy controller? There are machines with no tape drives at all, and machines with no network interfaces. Yet /bin/rcp exists which isn't useful if you don't have a network interface and /bin/domainname which is isn't useful unless you happen to be using NIS. By machine dependent, I take this to mean "PC architecture" or CPU-type dependent, not based on what selection of peripherals happen to be installed on any particular system. I suppose you could make the system architecturally "pure" this way, yet the result isn't likely to be either useful or practical. louie From owner-freebsd-hackers Sat Jul 26 14:27:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21061 for hackers-outgoing; Sat, 26 Jul 1997 14:27:37 -0700 (PDT) Received: from garbo.lodgenet.com (garbo.lodgenet.com [204.124.122.252]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA21053 for ; Sat, 26 Jul 1997 14:27:34 -0700 (PDT) Received: from schmeggie.knight-trosoft.com (jprince-home.lodgenet.com [10.0.9.53]) by garbo.lodgenet.com (8.6.12/8.6.9) with ESMTP id QAA26283; Sat, 26 Jul 1997 16:24:40 -0500 Received: from knight.knight-trosoft.com (knight.knight-trosoft.com [192.168.200.1]) by schmeggie.knight-trosoft.com (8.8.5/8.8.5) with ESMTP id QAA00577; Sat, 26 Jul 1997 16:24:17 -0500 (CDT) Received: from knight.knight-trosoft.com (localhost.knight-trosoft.com. [127.0.0.1]) by knight.knight-trosoft.com (8.8.5/8.8.5) with ESMTP id QAA12726; Sat, 26 Jul 1997 16:24:16 -0500 (CDT) Message-Id: <199707262124.QAA12726@knight.knight-trosoft.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: FreeBSD Technical Reader cc: "Daniel O'Callaghan" , Dan Janowski , hackers Subject: Re: ipfw divert, transparent proxy In-reply-to: Your message of "Sat, 26 Jul 1997 12:32:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 16:24:15 -0500 From: John Prince Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Who is ``FreeBSD Technical Reader'' --John FreeBSD Technical Reader writes: > > I know I could be banned for life for saying this --- but you could also > use a linux machine and the ipmasquerading built into the kernel for doing > this, there are no equivalent features in FreeBSD and it works much better > than natd (Ipmasquerading is one of the things i miss from linux). Please > forgive me for this sin. > > On Thu, 24 Jul 1997, Daniel O'Callaghan wrote: > > > On Thu, 24 Jul 1997, Dan Janowski wrote: > > > > > I am replacing an old TIS firewall that has one very > > > interesting feature that I am looking to provide with my > > > FreeBSD 2.2.2 box. It is this: > > > > > > They use ipfs which has the capability of "transparently" doing > > > packet re-rerouting and, thereby, proxy transparently. > > > > It is a nice feature, and divert sockets is the way to do it in FreeBSD, > > but it has not been done yet. got half-way through > > a transparent http proxy using divert sockets, but did a tcpdump analysis > > of his customers' traffic and found that < 1% were not using the proxy, > > so he did not bother finishing the code (too busy on paying work). > > > > Danny > > > > From owner-freebsd-hackers Sat Jul 26 14:29:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21146 for hackers-outgoing; Sat, 26 Jul 1997 14:29:06 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA21141 for ; Sat, 26 Jul 1997 14:29:04 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA08019; Sat, 26 Jul 1997 15:28:15 -0600 (MDT) Message-Id: <199707262128.PAA08019@pluto.plutotech.com> To: "Louis A. Mamakos" cc: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= , "Justin T. Gibbs" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-reply-to: Your message of "Sat, 26 Jul 1997 17:23:29 EDT." <199707262123.RAA18551@whizzo.TransSys.COM> Date: Sat, 26 Jul 1997 15:28:15 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The hier(7) man page mentions nothing about sbin being a repository for machine dependant utilities: /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments Not that I buy your argument about chio being machine dependent one bit. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Jul 26 15:14:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA22825 for hackers-outgoing; Sat, 26 Jul 1997 15:14:55 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA22819 for ; Sat, 26 Jul 1997 15:14:50 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.6/8.8.5) id CAA02858; Sun, 27 Jul 1997 02:14:44 +0400 (MSD) Date: Sun, 27 Jul 1997 02:14:44 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "Justin T. Gibbs" cc: "Louis A. Mamakos" , "Sergei S. Laskavy" , freebsd-hackers@FreeBSD.ORG Subject: Re: /bin/chio: why in /bin ? In-Reply-To: <199707262128.PAA08019@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, Justin T. Gibbs wrote: > The hier(7) man page mentions nothing about sbin being a repository > for machine dependant utilities: > > /sbin/ system programs and administration utilities fundamental to both > single-user and multi-user environments > > Not that I buy your argument about chio being machine dependent one bit. hier(7) manpage says nothing about machine-dependance here so it could not be treated as authority in this issue, try to dig out other sources and consider traditional practic. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Sat Jul 26 16:50:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25865 for hackers-outgoing; Sat, 26 Jul 1997 16:50:57 -0700 (PDT) Received: from m5.boston.juno.com (m5.boston.juno.com [205.231.100.197]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25860 for ; Sat, 26 Jul 1997 16:50:55 -0700 (PDT) Received: (from lwatkins1@juno.com) by m5.boston.juno.com (queuemail) id ToW19909; Sat, 26 Jul 1997 19:49:06 EDT To: hackers@freebsd.org Date: Sat, 26 Jul 1997 16:47:52 -0700 Subject: Looking for help Message-ID: <19970726.164753.12062.0.lwatkins1@juno.com> X-Mailer: Juno 1.38 X-Juno-Line-Breaks: 0-1,3-4,9-10,18-19,27-28,32-33,36-37,40-44 From: lwatkins1@juno.com (Larry E. Watkins) Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi -- I've been stimulated to write because I just received the "FreeBSD News" and have been reminded that I'm missing out on too much. I have a dual boot IBM compatible PC with FreeBSD installed on it's own hard drive. I'm a long-time computer user, ex-programmer, quite familiar with DOS and Windows and although I've had FreeBSD for nearly 2 years I'm pretty much a novice at it and Unix in general -- just the kind of calls for help you probably like to get I'll bet :-). I've learned enough about my BSD system to complete a Perl course and have done some extensive Perl development using vi. I've also learned how to get files onto diskette so that I can transfer them between my Win95 machine and my BSD machine. My Windows machine is my Internet connection -- I've not gotten BSD to operate with my modem, and frankly wouldn't know what to do with it once I did get connected. So, basically, I've been using my nice BSD machine to simulate a big dumb DOS box and little else. I need to get out of the rut. I'd started to install XWindows so that I could have a windows-like environment but apparently when I initially installed FreeBSD I neglected to install everything -- XWindows wouldn't install because it said some of the required directories are missing. I started to reinstall FreeBSD but the warning message says it's possible I could lose everything in the process and although I don't have a heck of a lot to lose, there is enough working that I chose not to risk the reinstall. What I'd like help with to begin with is to in getting my machine connected to the Internet and learning what I can do with it once I'm there -- on my Windows machine I use ftp, telnet, Netscape and MS Internet Explorer, and e-mail. So, I need some direction and someone to give me a shove. If I could get connected properly perhaps someone there could connect to me and take a look at my system and let me know what I can do to make it hum. I can see the handwriting on the wall and it's spelling FreeBSD -- as time goes by the less I can use Microsoft the happier I'll be. Looking forward to hearing from someone whenever you have the time. Larry Watkins Sacramento From owner-freebsd-hackers Sat Jul 26 17:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA26969 for hackers-outgoing; Sat, 26 Jul 1997 17:21:57 -0700 (PDT) Received: from goof.com (qmailr@goof.com [128.173.247.211]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA26964 for ; Sat, 26 Jul 1997 17:21:53 -0700 (PDT) Received: (qmail 22174 invoked by uid 10000); 27 Jul 1997 00:18:41 -0000 Message-ID: <19970726201841.20682@goof.com> Date: Sat, 26 Jul 1997 20:18:41 -0400 From: "matthew c. mead" To: hackers@freebsd.org Subject: Modem problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I'm having some problems with a no-name internal modem that are baffling me, and I'm hoping to find some help. I recently started to need two serial ports in addition to my modem, so I moved it to sio3 and irq 2/9, whereas it used to be setup as sio1 irq 3. Once I changed the modem over, FreeBSD would no longer get decent transfer rates. Pinging the remote slip server would yield 300ms RTT's whereas I used to get 150ms RTT's. Ftp transfers dropped from around 2.3K/s to 800bps. My suspicion is that this is some sort of driver problem. Now, as some further datapoints - when I use win95, winNT 4.0, or (cringe) Linux, I get the expect transfer rates and RTT's - this is what leads me to believe the problem is in the serial driver. I hope I'm not coming off as touting Linux or threatening to switch - I'm very satisfied with FreeBSD and would prefer to continue using it, but I need to figure out how to get the modem working correctly again. Anyone have any ideas? Thanks in advance! -matt -- Matthew C. Mead mmead@goof.com http://www.goof.com/~mmead/ From owner-freebsd-hackers Sat Jul 26 18:48:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA29327 for hackers-outgoing; Sat, 26 Jul 1997 18:48:26 -0700 (PDT) Received: from earth.mat.net (root@[206.246.122.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA29317 for ; Sat, 26 Jul 1997 18:48:21 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id VAA01730; Sat, 26 Jul 1997 21:47:59 -0400 Date: Sat, 26 Jul 1997 21:48:12 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: "Larry E. Watkins" cc: hackers@FreeBSD.ORG Subject: Re: Looking for help In-Reply-To: <19970726.164753.12062.0.lwatkins1@juno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Jul 1997, Larry E. Watkins wrote: Your request is too broad, and sent to the wrong list. Unix is huge, with many, many possible avenues to explore. Your request was analogous to "teach me about life", because a ten word answer is as true as an answer that comes in a five book set. Narrow your focus, pick one thing you want to learn about, and someone will point your towards something you can read, and when you do it, send it to the FreeBSD-Questions list, not FreeBSD-Hackers. A first thing, tho, would be to visit your bookstore and get an introductory Unix book. There are many of them, pick one you find readable. Once you have the general idea, you will have an easier time generating a reasonable question. > Hi -- > > I've been stimulated to write because I just received the "FreeBSD News" > and have been reminded that I'm missing out on too much. > > I have a dual boot IBM compatible PC with FreeBSD installed on it's own > hard drive. I'm a long-time computer user, ex-programmer, quite familiar > with DOS and Windows and although I've had FreeBSD for nearly 2 years I'm > pretty much a novice at it and Unix in general -- just the kind of calls > for help you probably like to get I'll bet :-). > > I've learned enough about my BSD system to complete a Perl course and > have done some extensive Perl development using vi. I've also learned how > to get files onto diskette so that I can transfer them between my Win95 > machine and my BSD machine. My Windows machine is my Internet connection > -- I've not gotten BSD to operate with my modem, and frankly wouldn't > know what to do with it once I did get connected. So, basically, I've > been using my nice BSD machine to simulate a big dumb DOS box and little > else. > > I need to get out of the rut. I'd started to install XWindows so that I > could have a windows-like environment but apparently when I initially > installed FreeBSD I neglected to install everything -- XWindows wouldn't > install because it said some of the required directories are missing. I > started to reinstall FreeBSD but the warning message says it's possible I > could lose everything in the process and although I don't have a heck of > a lot to lose, there is enough working that I chose not to risk the > reinstall. > > What I'd like help with to begin with is to in getting my machine > connected to the Internet and learning what I can do with it once I'm > there -- on my Windows machine I use ftp, telnet, Netscape and MS > Internet Explorer, and e-mail. > > So, I need some direction and someone to give me a shove. If I could get > connected properly perhaps someone there could connect to me and take a > look at my system and let me know what I can do to make it hum. > > I can see the handwriting on the wall and it's spelling FreeBSD -- as > time goes by the less I can use Microsoft the happier I'll be. Looking > forward to hearing from someone whenever you have the time. > > > Larry Watkins > Sacramento > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sat Jul 26 22:09:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA17660 for hackers-outgoing; Sat, 26 Jul 1997 22:09:21 -0700 (PDT) Received: from hq.icb.chel.su (hq.icb.chel.su [193.125.10.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA17617; Sat, 26 Jul 1997 22:07:58 -0700 (PDT) Received: (babkin@localhost) by hq.icb.chel.su (8.8.3/8.6.5) id LAA25603; Sun, 27 Jul 1997 11:09:08 +0600 (ESD) From: "Serge A. Babkin" Message-Id: <199707270509.LAA25603@hq.icb.chel.su> Subject: Re: SVR4.2MP source code has become available recently? To: stesin@gu.net Date: Sun, 27 Jul 1997 11:09:08 +0600 (ESD) Cc: dyson@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Andrew Stesin" at Jul 26, 97 00:20:07 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > And they have some kind of "unified driver interface" spec for UW. > How nice would it be -- to have an ability to use hardware > vendor's own drivers for UW, compatible with that spec, > just out of the box. Aaghh, dreams, dreams... :( About the driver interface. They have the document named "Device Driver Interface", the current version (that will be implemented in SCO Gemini) is DDI 8. A good thing is this documents descripts not only the calls that driver must support but the functions it can use too. It is made to allow to link the drivers with compliance to different levels of DDI simultaneously. The linking is dynamic, the function names are substituted to reflect the DDI level. This has one important consequence: all you need to link in the SVR4 drivers is to have the DDI-compliant in-kernel library and a SVR4->BSD object file format converter. Of course, you'll need STREAMS to use the SVR4 network drivers. -SB