From owner-freebsd-hackers Sun Sep 24 00:45:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA09718 for hackers-outgoing; Sun, 24 Sep 1995 00:45:41 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA09687 ; Sun, 24 Sep 1995 00:45:03 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA21994; Sun, 24 Sep 1995 17:41:15 +1000 Date: Sun, 24 Sep 1995 17:41:15 +1000 From: Bruce Evans Message-Id: <199509240741.RAA21994@godzilla.zeta.org.au> To: jkh@freefall.freebsd.org, julian@ref.tfs.com Subject: Re: Whither wait_t? Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >/* > * Use of this union is deprecated > */ >union wait >{ >but no definition of wait_t >> >> Shouldn't it be defined in sys/wait.h? Not in 2.1! :-( >> >> What's our evil friend POSIX say? >I don't think POSIX has ever heard of wait_t >(BTW what IS it?. it's not in 2.0.5 either..) It doesn't exist. Old BSD applications may want to call the wait*() functions with a bogus `union wait *' arg instead of the Standard, Portable, `int *' arg.. Linux supports these applications using gcc extensions. BSD (4.4lite) doesn't support these applications. Bruce From owner-freebsd-hackers Sun Sep 24 01:22:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA11218 for hackers-outgoing; Sun, 24 Sep 1995 01:22:02 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA11204 ; Sun, 24 Sep 1995 01:21:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA04883; Sun, 24 Sep 1995 09:21:54 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA22165; Sun, 24 Sep 1995 09:21:54 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA29753; Sun, 24 Sep 1995 08:39:21 +0100 From: J Wunsch Message-Id: <199509240739.IAA29753@uriah.heep.sax.de> Subject: Re: Whither wait_t? To: jkh@freefall.freebsd.org (Jordan K. Hubbard) Date: Sun, 24 Sep 1995 08:39:20 +0100 (MET) Cc: hackers@freefall.freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509232157.OAA03165@freefall.freebsd.org> from "Jordan K. Hubbard" at Sep 23, 95 02:57:41 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 521 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > Shouldn't it be defined in sys/wait.h? Not in 2.1! :-( > > What's our evil friend POSIX say? Since the man page claims: STANDARDS The wait() and waitpid() functions are defined by POSIX; ...most likely not. What is "wait_t"? Everything in the man page mentions an int. (Sorry, 1003.1 is apparently unavailable in electronic form.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 24 01:22:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA11275 for hackers-outgoing; Sun, 24 Sep 1995 01:22:23 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA11262 for ; Sun, 24 Sep 1995 01:22:17 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA04906; Sun, 24 Sep 1995 09:22:13 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA22175; Sun, 24 Sep 1995 09:22:13 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA29850; Sun, 24 Sep 1995 08:47:56 +0100 From: J Wunsch Message-Id: <199509240747.IAA29850@uriah.heep.sax.de> Subject: Re: multiple mail messages To: nate@rocky.sri.MT.net (Nate Williams) Date: Sun, 24 Sep 1995 08:47:56 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509240419.WAA07762@rocky.sri.MT.net> from "Nate Williams" at Sep 23, 95 10:19:28 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 852 Sender: owner-hackers@freebsd.org Precedence: bulk As Nate Williams wrote: > > > People are generally too lazy to trim the Cc lists even when they know > > that all recipients are actually on the mailing list. > > Actually, I *intentionally* leave people on the Cc lists if I think the > material is going to be discussed some, since with the bulk_mailer stuff > it is difficult to discuss topics with any sort of speed, since it may > take a very long time for the person to get the reply via the mailing > list. Do you remind that many people are not within a "can get'em within 10 minutes" US Internet anyway? :-) For me with my polled UUCP link for example, i'm typically getting 50 ... 100 messages in a single batch... No speedup by duplicates. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun Sep 24 03:32:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA18519 for hackers-outgoing; Sun, 24 Sep 1995 03:32:39 -0700 Received: from toplink1.toplink.net (toplink1.toplink.net [194.163.120.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA18474 for ; Sun, 24 Sep 1995 03:32:22 -0700 Received: (from ck@localhost) by toplink1.toplink.net (8.6.9/8.6.9) id LAA01183 for hackers@freebsd.org; Sun, 24 Sep 1995 11:32:38 +0100 From: Christian Kratzer Message-Id: <199509241032.LAA01183@toplink1.toplink.net> Subject: pppd server with dynamic ip assignment To: hackers@freebsd.org Date: Sun, 24 Sep 1995 11:32:37 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3950 Sender: owner-hackers@freebsd.org Precedence: bulk Hi All, Some time ago I hacked a small Extension to pppd that has been performing quite well. I would like to contribute it to freebsd. We are a small isp using freebsd machines for everything including dial up servers. Some of our customers get the same ip number every time they connect others get assigned ip numbers dynamically. Additionally we have several pools of ip numbers for different classes of customers. To support this we give each user an account with pppd as the login shell. They additionally get a .ppprc in their home directory. pppd is NOT included in /etc/shells so they can't use ftp to upload .rhosts or .ppprc files (or do other nasty things I dare not even think about ;-) ) The .ppprc file follows one of following patterns: # .ppprc ( set user specific ppp options ) # customer is assigned ip from guests pool every time he connects ip-address-map ip-addr.guests # .ppprc ( set user specific ppp options ) # customer is assigned ip from guests pool every time he connects ip-address-map ip-addr.toplink # .ppprc ( set user specific ppp options ) # customer gets same ip everytime he/she connects :machine.customer.domain The file specified in the ip-address-map directive specifies the name of a file under /etc/ppp/options. This file maps each tty port to an ip number effectively implementing dynamic ip assignment. # # IP Address Map for Dynamic PPP # # contains IP addresses for dialin to toplink # # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine # ttyd0 :ppp-005.toplink.net ttyd1 :ppp-006.toplink.net ttyd2 :ppp-007.toplink.net ttyd3 :ppp-008.toplink.net ttyd4 :ppp-009.toplink.net ttyd5 :ppp-010.toplink.net After fighting with the broken proxyarp option in pppd for two weeks we now implement proxy arp using the following ip-up and ip-down scripts. /etc/ppp/ip-up: #!/bin/sh # $1 ifname,$2 devname,$3 strspeed,$4 strlocal,$5 strremote /usr/sbin/route delete $5 /usr/sbin/arp -d $5 /usr/sbin/arp -s $5 `cat /etc/ppp/ether_addr.ed1` pub /etc/ppp/ip-down: #!/bin/sh # $1 ifname,$2 devname,$3 strspeed,$4 strlocal,$5 strremote /usr/sbin/arp -d $5 /sbin/ifconfig $1 down /sbin/ifconfig $1 delete This scheme has been working just fine for 6-8 weeks now and I think it's ready for release. The changes to pppd are quite local. I did check with freebsd current before I did the hack in 2.0R that there had been no changes to pppd. I will gladly volunteer to report this hack onto the newest pppd together with the person currently responsible for the thing. I could also write a section for the freebsd manuals detailing use of this feature for a pppd server. I do also have a question for hackers that might be a good thing to solve once we are at it. Every time a users disconnects from pppd we get a list of error messages to the console. Is this a bug with 2.0R ? Sep 23 21:28:15 mail pppd[25600]: ioctl (PPPIOCGFLAGS): Inappropriate ioctl for device Sep 23 21:28:15 mail pppd[25600]: ioctl (PPPIOCGFLAGS): Inappropriate ioctl for device Sep 23 21:28:15 mail pppd[25600]: ioctl(PPPIOCSASYNCMAP): Inappropriate ioctl for device Sep 23 21:28:15 mail pppd[25600]: fcntl(F_SETFL, fdflags): Inappropriate ioctl for device Sep 23 21:28:15 mail pppd[25600]: ioctl(TIOCSETD): Inappropriate ioctl for device Sep 23 21:28:15 mail pppd[25600]: tcsetattr: Inappropriate ioctl for device ps: please also cc me in your replies to the list as I am not quite sure I get everything from the mailing lists. Had some trouble in the past ;-( Greetings Christian Kratzer -- TopLink GbR, Internet Services info@toplink.de Christian Kratzer http://www.toplink.de/ Phone: +49 7452 87174 Fax: +49 7452 87175 FreeBSD spoken here! From owner-freebsd-hackers Sun Sep 24 03:36:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA18788 for hackers-outgoing; Sun, 24 Sep 1995 03:36:53 -0700 Received: from jhome.DIALix.COM (root@jhome.DIALix.COM [192.203.228.69]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA18769 for ; Sun, 24 Sep 1995 03:36:46 -0700 Received: (from peter@localhost) by jhome.DIALix.COM (8.6.12/8.6.9) id SAA00738; Sun, 24 Sep 1995 18:36:35 +0800 Date: Sun, 24 Sep 1995 18:36:35 +0800 (WST) From: Peter Wemm To: hackers@freebsd.org Subject: IPFW vs IPACCT vs IPFIL2.8 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk With all the talk about swapping IPFW for IPFIL2.8 from Darren Reed, the main reason that's come up as to why not, is that IPFW can do accounting. Perhaps it might be an idea to try and split off the accounting functions from the ipfw package, or to make an entirely self-contained accounting system. Then, one could use whatever filtering/firewall system they liked, and still have accounting if they need it.. Cheers, -Peter From owner-freebsd-hackers Sun Sep 24 04:13:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA20458 for hackers-outgoing; Sun, 24 Sep 1995 04:13:47 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA20452 for ; Sun, 24 Sep 1995 04:13:44 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id VAA18836; Sun, 24 Sep 1995 21:12:07 +1000 From: michael butler Message-Id: <199509241112.VAA18836@asstdc.scgt.oz.au> Subject: Re: pppd server with dynamic ip assignment To: ck@toplink.de (Christian Kratzer) Date: Sun, 24 Sep 1995 21:12:04 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199509241032.LAA01183@toplink1.toplink.net> from "Christian Kratzer" at Sep 24, 95 11:32:37 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1591 Sender: owner-hackers@freebsd.org Precedence: bulk Christian Kratzer writes: > Some time ago I hacked a small Extension to pppd that has been performing > quite well. I would like to contribute it to freebsd. Yes, please :-) Fixing an IP address to each modem, whilst it's simple, is not the way I want to do things .. > After fighting with the broken proxyarp option in pppd for two weeks we now > implement proxy arp using the following ip-up and ip-down scripts. Why do you need proxy-arp ? I haven't found any need for it since the patch to enable a netmask of 255.255.255.255 in pppd was posted (in '-current'). I don not know if the same patch has propagated into -stable. I suspect that proxy-arp combined with using the same address for ppp interfaces as ethernet doesn't get on at all well. Actually, I prefer to have all my dial-ins allocated out of a subnet that isn't the same as my "home" subnet(s) as I can then use fewer IPFW rules to prevent access to things. > I do also have a question for hackers that might be a good thing to solve > once we are at it. Every time a users disconnects from pppd we get a list > of error messages to the console. Is this a bug with 2.0R ? > Sep 23 21:28:15 mail pppd[25600]: ioctl (PPPIOCGFLAGS): Inappropriate > ioctl for device I've used pppd with '-stable' and '-current' but I don't see this, only gated complaining about a route that was there when it last looked and that isn't any more because pppd deleted it :-) I'm using mgetty on the cuaa devices, however, because the same lines also take inbound fidonet callers .. Perhaps '-stable' is worth a peek ? michael From owner-freebsd-hackers Sun Sep 24 04:28:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA21034 for hackers-outgoing; Sun, 24 Sep 1995 04:28:25 -0700 Received: from toplink1.toplink.net (toplink1.toplink.net [194.163.120.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA21027 for ; Sun, 24 Sep 1995 04:28:16 -0700 Received: (from ck@localhost) by toplink1.toplink.net (8.6.9/8.6.9) id MAA01651; Sun, 24 Sep 1995 12:25:50 +0100 From: Christian Kratzer Message-Id: <199509241125.MAA01651@toplink1.toplink.net> Subject: Re: pppd server with dynamic ip assignment To: imb@scgt.oz.au (michael butler) Date: Sun, 24 Sep 1995 12:25:49 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509241112.VAA18836@asstdc.scgt.oz.au> from "michael butler" at Sep 24, 95 09:12:04 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1932 Sender: owner-hackers@freebsd.org Precedence: bulk Hi > > Some time ago I hacked a small Extension to pppd that has been performing > > quite well. I would like to contribute it to freebsd. > > Yes, please :-) Fixing an IP address to each modem, whilst it's simple, is > not the way I want to do things .. ok! What do I have to do to get this thing into freebsd ? Should I post it to this list or should I contact the keeper of the pppd port ????? Would the person responsible for this please get in touch with me ? > Why do you need proxy-arp ? I haven't found any need for it since the patch > to enable a netmask of 255.255.255.255 in pppd was posted (in '-current'). I > don not know if the same patch has propagated into -stable. > I suspect that proxy-arp combined with using the same address for ppp > interfaces as ethernet doesn't get on at all well. > > Actually, I prefer to have all my dial-ins allocated out of a subnet that > isn't the same as my "home" subnet(s) as I can then use fewer IPFW rules to > prevent access to things. > > I do also have a question for hackers that might be a good thing to solve We do not yet run gated or anything similar so proxy arp was the quickest way to get started as we also have dial ins divided over two machines currently. ;-( > > Sep 23 21:28:15 mail pppd[25600]: ioctl (PPPIOCGFLAGS): Inappropriate > > ioctl for device > > I've used pppd with '-stable' and '-current' but I don't see this, only gated > complaining about a route that was there when it last looked and that isn't > any more because pppd deleted it :-) I'm using mgetty on the cuaa devices, > however, because the same lines also take inbound fidonet callers .. > I now have 2.0.5 running and will check that as soon as I get around to it. Thanks for the comments Christian -- TopLink GbR, Internet Services info@toplink.de Christian Kratzer http://www.toplink.de/ Phone: +49 7452 87174 Fax: +49 7452 87175 FreeBSD spoken here! From owner-freebsd-hackers Sun Sep 24 05:01:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA22189 for hackers-outgoing; Sun, 24 Sep 1995 05:01:33 -0700 Received: from toplink1.toplink.net (toplink1.toplink.net [194.163.120.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA22163 for ; Sun, 24 Sep 1995 05:01:02 -0700 Received: (from ck@localhost) by toplink1.toplink.net (8.6.9/8.6.9) id MAA02014; Sun, 24 Sep 1995 12:58:48 +0100 From: Christian Kratzer Message-Id: <199509241158.MAA02014@toplink1.toplink.net> Subject: Re: dynamic pppd... To: peter@jhome.DIALix.COM (Peter Wemm) Date: Sun, 24 Sep 1995 12:58:48 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: from "Peter Wemm" at Sep 24, 95 07:42:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 25152 Sender: owner-hackers@freebsd.org Precedence: bulk Hi Peter here are the changes I made to pppd back in 2.0R. They should be quite easy to port. I have provided example ip-addr-map files in the archive. I have only modified the options.c and pathnames.h files and added the ip-addr-map directive. I have also included the original files from 2.0R that I based my hack on. Greetings Christian ----------------------- cut here ---------------------------- begin 664 changes.tar.gz M'XL(",!&93```V-H86YG97,N=&%R`.P\:W/;1I+Y2OZ*"5.Q28D4)<6.-Y:M M+<6F;=[)$H^DDLW9+BX$#$E$((#%@Y(VZ_OMU]WSQ(,BO9O-ESM5Q1(&W3T] MW3W]PDS-K_ZM_XPYX?!'\'0'_OC2OW'3K8,G15/ M#Y8'GI]FO^<<1X>'WW__9+/^GSW]7NG_^,G14P#[[LG39U^QP]^3B4T__\?U MW]]KLCWF\;D?6>C ML^F[V6CX^LWP?,`:K3[/W'X]U+N)CQ+6R7P5^^JX+`_-L)/?IE;UY<\712@ON@W+<-/I+S!OHS+G01GP:C(8$^0!0"5NJUG5O]K_BH3[ MN^_^;?O_V9-C]/G%_7]\_/W_[_\_XD?L?ZU]UF-@$%[`4SG&XB1R>9KZX8+- MHX2-1J,#Z1Q>1?%]XB^6&6N['7`,?_J!O7*2D"]\SM[S(`#DJ]!?\R3ULWM$ M8F=!P`@C90E/>;+FGB(VYFAWB7^=TZS``\M3SOR0I5&>N)Q&KOW02>Z1CU7* MG`0<%D]6?I9QCYQ5$JU]CWLL6SH9_`,XU]&:,U?S&4:9+TEE2S\%]Y8XB\2) METB,_&`>![[K`$&9ZU;ON#=A=!MP;\'-HM)HGMWBXF^=%#SJ MF@=1+`1P??^0`AB;`C9ZO!:_;7OYY-8.#Q8W9V\9K]/)R^N[R:PM^_ ML,%?1N/!9,(NQTAA^'YT/@1X(#`^NY@.!Y,N&UZ\.K]Z/;QXV]6(Y\/WP^D9 MNNPN3#I0:$C!8+++-^S]8`S1`!Y_')X/I[_0[&^&TPN<\AR,CC0P2\$+\P"/\R:*1J(R\#+)BQQ4]_[\(F]9"V]WS9%U<,_ MV5&U=6("G!^Z0>YQ]B+-/#\Z6)Y:0SQ)PM)0'H)A><6QP(=-D]*8#!=@1F08 MD^GK\^&/,_E8G"SPKPDEI]5503+4:906ITKOTR!:E,;`T,/26,@S[[HX%-]Z M%5K][#[FU2GZ*.8*05A8UO=#'##QJ%^GHZO!HTCLB]4@,BAFF19>R!2 M<%UL-CL;OYVTVV*PT['-1ACEV^'KR6`ZF_XR&FC"UEACX7NS3&.)X#!*HBPB MP9.!2Y,&ZV8I:(U?YPL]\3KR/9RV"'-3!!+<[57A8@=<`CCLAZFE?@!^]R&@ M,(+]M85*&*U_W0'$=:-5O`5N_2O8.'C$A]>7\+^!SA]F>PL`S(5V,PAEDY"]\-\]4U M?Q`0F*_,N='P>.HZ\3:9`MPJR7<`RK8!P2(L0O66L(/=N5$8+DNT\07;Q M)=`@9$A_ML*!?UTYZU`""7>\'?P$.?"Y@[$$LK5M MGA=RO[M[)]EFES$FE.DV!^Q%D!A85K;!WZ5\&:5%$6^R"S_VYL&V:2$V9_Z* M8VZZ530("TG-3H"PO>8[`868M#.K M``NA9P>B&)UVIHK`\%^P&R3\N=Y-`!#:MCD(";8M&('FN;N,=IM:`F\4?R%6 M4"B^M5YH. M'?P,=DKN)Q9_^$9YX>*@\+F%,9B+7&R95["N&9K7#(!XLG:"C0!D@$5FHSR9 ME:0CBEL*7/J5G%_Y;C$`:D!#FDE1^K$VM9^

8DRRHIY(>V(4&U#:Y"V:P M\MAO36P82EVOO)D@C6-R)\R`1&I&V@0UST.WTP:[_HQ$4JK`!:7?6CTG"%I= M=M@51F5E6<0!R&+KB&E(M]O,!N%M6\-AX9MD96F_%SEP&^1[*; M1\F-A>'':I4BQ2^N<3ABCI#4AE6N0H5N9?]%&O1".L--5))(M M3#DZ&Y$3H1XA>8XH\40'CO(]0P90!1NB\A0DQL*C$!G*(0D3?&!B\^]H=0E$ MLR?$7KA2Z+!9L5V*`L..7XG0/@9;S0,^%)G`[RUE,G7\&#*BKI4"M1BJHU3# M4&_]JV6UZU\%(>F6V$__H;51M`#9!BB@RMW.RO@490"]-WQ=3VW]:V_EW/6H M9:#U+%L(@AY:%H#XJWR%-)<0J&$1HL>@R:C=7K/]V6[;7Q2]&E\\&N>!7C:E M)K`HCF$-6>*$J>S;&CIRS9J0CK2"DS.T^$7BK*C;#83SF#F6H`PA$Z4U+3MP M"]8L8N8E@&)C'2/W@<682!RTVN2S6>*R?\OF:#ZN],\:59:B&E4^&]1T(VJO M/*W&16DXH?@60`4-?D]11:^1`KK=?\XQWRA<(;P;"WD0DHG>0+SF04_@&3IF M_'5Y!.!KE8>JV[ M764617VG0"/^36SJ:NA,:D)]OAY3O@W]CH4B#GV,@P^P2_@[7)15*' M`V-'QQ(MZ-/(%1[,:D731-MOR>EJ"ABC3!A+5;A&"OBD\74@JG'75@*I%V2- M"8KO\U0(1?<)%%N6*Q#9:6%58LAX7-EYV;HP'-?&ZPR3\)Q22+=;-9:',(/2X\).E:-,M'7,!I"U@]D!8@^Q?+PSASJ!.8&4 MIQG8N,YP/"=SKM'[H6XH_S#&BIT?L5XK1(MND%B7V3E:O4I`E'LF]O9QXQX6 M/STL?O+$&(Q=E`NRL,24NWF&'@-?,8E21TW56F5RV!`0U+#90:S!&T$.O'28 ME8@!]CY@U*:"?&]<&<*75D:'KG8H^2_2(&$OH3;@X8(7*.'H9F$KE!*Y MRN95741#28$0G8374"*U.:[+XZQ7C/&JTRB=,(%0T'B9E(Y#41.@J MDTNVD?,S3>[BZOR#R[$N0G]U;@XS%KF#)Y]YF$O M3YT%GXE/_GCRX6,3O[%;/(0#XI2I[+?>M^G'\&/S"K&>X]L/IBO$ M/G79+23/W!IR$OX<$1HO1$YSVG@5K59Y2(=X6`334!F$;M^3:8\`I[[?::,Q MD872M9-[+$$D2&GE6P$)NCI]_@)D?*J!10X$%7@_4ITO80!SQ\5V!B$V&E+8 M/#U@;.!3WA^%G`[:7`-SXN32`0'K-L^+T$Q3+=XPW>9W""2P8`LU&MM2#P1E M\D<53"_B4WH>ANL(THYTR0-J3ZVPK8`O3;%&9XY$WHB9)DTL:YQ&`T,UZ-FC M0S_CZ:3_:CHI%$8$;NE#J-=]48@(_"$F+N)N1VS08LXXV?I%BSPZ:9@Q="MZ16 M>8``?5`^K+*-DP(E;-J>X+]Q[U1W?>EY?[\#\,C4G+6_!G[=5=RF512A.P#6 MN(9T^P:Y0.#B>_;U2_)\Q+ZB1VMZ(2FIWC)!-.8Q*"R;MU/(OI.DRUK3")(_ M?DL'"E<<3$4%;[&AT*FU2"$=D$<#Q)A;DQ8[52QB MK_>RQ)]YN6;[U9?-QF>&)ZK5.DDA^`-UE'-_C<:89??D+KM,'/Z@C$'%C3\K M\+[AN0V,@9:H%*$/)\ARI\->OF2'P/:C1\Q`$,D'WHONL`6P0=[?IL]9'D*8 MC1:A_W?N*4D7Q$RAI[U%XCCU"Y@'ZPZ@'5&A5D#XW!0H^*\%H!EX5=_82_"'X"RQ`<$?+'I;8NI)+N1'+*[7#9Y?]-!A/ MZ.SBZ&SZZMWYX*U"V.E[!`]44H.)T M:^@))Q@G(CJMC.>I$&[C/\*(5E">S_@=%(JP*9?1T%:]R+P3%C M!E?Y+#JIOSQV3%CP#"OW]IR\<9<]TLK1U(B%/R0H$`?_8E"@Z7V8^_"$^97( M<,+V]WWAKFAB:_ED3_ZGS2)HU&Q]3"!QN#4,1;Z#FLEVB3,*TU@?<$IND$8M M]=GVA:X.?%VC0;O"QX^DDN\O"%/"6]LS5#SO'Q."<,4/A:#-[V4(,@`;0I"M MEKI09"FCJHB'1?3[!:>"9Z;/ACTV$5L,`Q&U31W<:?_3%U>$2@Y_SM*H:_G] M0G3PLPTA`"?2$4V5@1R$MHR2^;PLA$6DS[F1RO-5OU0W3U"?*#H#1:E`6@%#D'TG`><+%J$%$ M49`^JB84)3/F245PNQ+*[^\]:E)BW9$]`4YI3754" M;W$S9TGB+I.V]`E=]KC_V%(,`6F]"!0)*H#HZF%C?Q\ :,)S1_"_AJ=2J& M1%^LQ#&(((IN2"*5JWHH2ME]J;4L^Z:?96$P+SX=;3,P)+^#D15FJ;$JG&Y' MHSK\$J/2A\]Z(K$C>Q*\^JEY>WU/I@3/`>V'@](%A*9):SQ3Z)L! M_[4."2V2*(^AOO8+/@=ILO0ZE^FD=26""80/%V_'EU>CR0R2/I7M`6'AF,@? M&8W0>)UWP9=SG`KXA6P`Y^M@FF%!'EJF!J\/(#^4Y."7`5/OZ*/C(S:9#<=7 MDW$5=R%P@<<%^*!NTOPB@1 M=QV%<[.20_RM"Y?8R@RK18YP?8A@['E/8=H@IJ3ZS11070:#7V-P^4;72RY:S^./'Q]W:K+'6I&?@);F$9X1$LIVPOMLB:6N<.X2E3XX MI-)N#NH2S`)7Q$3X&.L'[#7Z83G3D[LFG68 MBFNON.L<%S]R*U<`IO:1_5G6K%%H,-HZ;_1ZP`ZD#JAJJ2?+H)6*2HIN M/<:$U@@3G\P>`:K*'GM':(\N&5*LKN5"4"5WX8?"K@J3J#H6M_\+9CH=O:.. MK!L5;4$9!O?W<0F%(L;V%[8!*/:U/+0C^5KYHX*]R-=8J-6M%@Q>4\I#LEUP M=_-.>:\5"L_-JRNO#*'MQ15=$2`4=K??"$'Q=VE+#@FL-+R+$&M M`\#F1IL?KNG@NV#[N?I.8$2+V!N:?`4A2BG"#$:$@7_#BW(%'F'OTP(P0F+V M0*6^^/Z94NX-M7>^$K?_(;,Y%%7;GL+!_S^`^#^&T/AF;;56OZ[1[Z,UUAZ5!%KI":^U=-CZ9*/,\'^*(#($3`OH M_W;AT1D>?H=G>_3W-WDIP2I@9`L]P\^3"JCZ::Y4K5#19+[,U7R+DTQ62RV" MHA,(1W9;7YT2I,1B[[D;E%9',C[GKWS'V)(-#?7BO>`6'U2G_\[\'X4E]J M9H_PULNM$V82^\/A)]A__M]Y)*I^K!(11+Y6[:N[WKV-5UR*MQK0$UF?UFLT(@AJI525<`#X,P&E*)K:I+JXA\!+ M:S*+4HL5K-ZQT[Z:.?8FZ=0%JBNV\5R`WL2UOR_>VW*.IX5KVN!7/-<8F M6$'RFHTZ4ZH!V\2M?6^_M_7:3@W3%H%MTK;GVBKP6N"-JTARF_OBI:$ZII-\ M*[-`9#N3-E`]<^*TO73*>,BE=*ZESB,C>P^Z8PK!`+4Y""OW#$"U@;AFU6(Q M1'6K7(YV7C(=S`)F>)K1/8'_;>_:_]I&DOS^:O\5"ID)-MA@$R`S$-AC$Y+A M-@^.Q^[MS>3#&%L$+4;66#:/W9W]VZ_KT=W54DLR"+/9R9(ZD?UJ[JZ MNNI;U^'\$-6&WH9/9FKX9):&3_P-ARR`!:'.%WOO8#S4<06>MT%45\]^L1!2 MC+3C+1@I*3[][0`$+!#%64"$*I4([A3_^V`N!17RW$8PA]TPURP2'7V3C,=D M,BV?_TF&_>_[O=FJ^7XR"]M/[L3U_:D+9X[V]6CG/3\:I+T'=Q>P@%,C>1V2 M?39B6H&=8_P1B@'+8V/4VV:'T=0K9G$%94W6-%3/>G8Y:>?\3YAR5!%I0@NH M1.,55`6IQGV$JQ@E*1JK,S`<]+:#:BMK!M.3;44W,Y.<_;;,H=`W>S([KF\Z M@.]DU31@4)YVSB_29T?ID>=_R1+BF<1,!W>&X]=-KYV1-0`_;8V=IHXB:'`= MQ6>CG&>*&MWB?A+%E3,[TC('4_=>=LB\KZ*#NT;U&X#1"WFG$K'">P55(E.^ M7B7K&&:@>=.8'%.:.I/:&@@]!-Q"M+("62,66F88DS.%0:+N9@Y36@E9 MWE`F*MQFT!WU4;I!B1XZ4Q_2!EV6JUWBW<[;W3>[[]1<4(<^HE-W5+VFMA-* M3O?EF.%P]\7![E%!EJ:O@<>F:Z%?BKIVJ;K9;-(PY8MHV=)QA`IQ M07MX%:2O/).H4JI/)#)1*7GZ-#N+"W[YU4=V'W06%52+-`Z1&ENNC=;X MVBN<3RMJ30DO.TH(&X3KR.ZAFTLMWQ1@"T`15(K`'KT,IO&+OR3!/@]60/:E MA^V@N^YGM6!"OQ%(]WC.`D:2H(P\#2?7H6+_*ZB3[*XKGE3(Z#/#$*"(V[N! M8J-X$-X$6W1U5#0>;EHFI%TFT4C/=Q;,>M);77M>J#][TI_",SRFG/(!LM4A M]QM,DX;FT'H`1)*,@8C]0K:_9!Y2JO5S0.0\+13^^$:,+&^H++&\K4[=AAAL(A3V:#">$]'QB- M6/7Q6B>M/F/KE"W@'K.H&$P3_K$EJBG9ZH3:S5GD^4[CRS[J,H.209,=.\L/ MF.'K*TI9S89C8=#.%U)J@JBII[LNT0XWTEB+V\'7^@L)LMW8WEVI,IY`&=BI MFW1KF<"R@9?6ZKGLX@JW`,YI&PU_.=FV]OD,I8T.9< M3]-;<`D%$?Y238\?58W;P=H'F$K=X/ES(/F)*JG["LHPO8LR90LOY/DAT,8< MBXN)Y^9.6\2)4SU:.UMM%CY[S^#&C49,"?7HN;344RA-M(V/^LO.`726HOO+ MCF"D?'D)GES8'O4(9FKP@-F])FN$I09E)X/2?5*C3=N6,B`%O+5&4M*";5KK/?4_8\!'"2>3VQ;^'PMIBD^J8."68/ZH'3M,XY$7*YEN;EFE6E:3 MI:^6R!H;ZL&L8Q-*L@&E1#`5-`_']Y#'5J":NH97^$ZU]E*^GY#Q:8$%S`MM M(VEO6W67H8DDW,Q2UV'Z9=$410^0\H1[IXGVY-HXIM3A!.@B^.[&F_>O3W8/ M#J!50N)J=^VLQC\(^I#V,NH?MGIW^H*'0:/L>;J#/DNX/?4>X;"SVW5V9IDK M$3VQ[)6(G%;"SP<8*JJR%<\>\KC\:PF7Z`DJ'>EII[#QP#6ZQ4[`0 M^`UTW+7J<._]GFF;'7=QH9/T(B6UA&`'P7:+2>D79]5E3E*Z>LCY!OX!Q;T-3,_]299W[? MH!*`PG!RXKK[M;N.@53C/"$;&AB'TUO7M]!HBWSJ(@B;$./P;10X7[:U(9XU M"JIIRA8:9!72/$_:V^=(XR:;0QGX0^U`8-QW]*S7*;!&*;\9AQM3AD=<0Q<< M6E3:D.BT-SB)U`EE,$ZI[YK%6Y]*RR,DI@YW@"I#3;>>+L/=F]O"=-.;@;\QE&X)E0PYY_/K'WO']"+2PNFCD%4\@PK@9GD[,( M4\X\CT3JN\XDREHQEPR!)9-)8F86SB>1B*OV3BI9UMWG%>6NF%CZ2H+*;0&8(#.E MJRC2Z`YM@_,`O9+C2V!R-H!C$GS59U@2_T"0J&?&LWQGEMOO';?=/,O*D=H; M@G;\E@#P6NS<D5)Y"-UBCP=WI)^ M6>HA2`D1L@,,>^ZA41H(0+21RZ:DWM%8$LW74B;B:\8R,V@7)5TMO)56S,'M M!>B!W"RV7E'JI``>SW!`!M%53Q)2LDEAQL.WK>XC)]%H@\Z235R7;+K9]5P>Q%`@;0.W*<9#Q>K6R1REFJ;M7P'YUXBXD3S,%5(A[02[QDTK>; MIJZE8,>://PM'(^"R[`7@\VIJ>"\A[?6IZ`%5MVV1-HV`#DZ>'UX?+C[$@$5 ML)_JK\/)6^Q3U2=-V8$T$Z2UH>X@UO1DE+$$=6/]#SF61=']AYN;X3T]N5=F MR*V1E4UV$_QBMMH1#\=D)G0Q901!<*YHQ+[]C]&67V%*E4HS6*!#FU"Q%:W#,TF(QT0E$ M19FI2`+--"7J6"DSM90P,N7ZH)MZ?V9BN:^F<9]$($;T@LT(T24=Q#IXL!?7R$I<$_V2[0B!SWD-%JFU0DFE>06U@*78_M4%):BU7 M5?C9HVQKC'L7P]$H\=8D,$`_M3)<_[,-F\8)O8^J9ADX#21Z3_7-,G0&;O3+ MCYU%)/W4NL!8#2J:IB<5(\>XI?=0$8Q;60<*9--/K0V*F&$V:N33SZU&M>BD MLDF?LSOHBH!8=X?XK0,E_XO^^AS_6\0\O?>'D\C2WVL)L2[*8S12X#7'4:]A4+2N-]46R4M*=)/LW+]W]^YZ8: MC*[C;#K"ZZGEZES*)F0`J]H<@7O-9?MG;W_GYN>!_W^-GP/RMM0/VH&:$(-AF&HO-/2(3U/P-,%X M+?O[2[PYO!@EM^/HX_DD`#".[O???1^\Z(WC\&,4!F_#(=S;'L<1(KU/;A$5 M:60< M"L-]<)H,$3H>03#`ESR=]L]UA3$7#:$`!Z,^NM2CI3T!)@Y44R<1]M2E*@(, M7U/"3Z"83^:E:OP0ZP#U@RH?:_:UOM>'Z^=A.``L8=VH='0V0;CUZQ[_JE_ M!U/08`]46ZZH7K;V51UJ:8LFYR,--',&`![C2)5R/8;1BFG!B\/X`2``1Y3Z57!1SLO#O:VSUL!7OO7KPY?KGW[G7+9'RS]W:/ M<9)5I;LZ&Z*#F9S!^U?!V]T#)0VHQS_LO=D[^@O6_FKOZ!W4^.K]0;`3[.\< M'.V].'ZSBN2JCK?2:EJ M;M,*.%'<'TX'8?`\G0RBT=+YMGB%]ESNJVFL)M;`?8?@9RF^8W%`6^0='KU\ ML_>'$WYT*QM&IYAEBJW+)\%8*:/4K8H,R#+OT/;:?1>'D\&I^RJY'N3*6I[< M)F&^BF7HYER!<"6V',7PWGX`-X.E\SGWQ2#SQDJ]F=?]2BS0%]?+'C,ZI0"SU2'OOXPDU4$AN:_%_+2V/W MTI)$A`E2%2[\ZJ\S)"$'H?)TVD>GO'WL:EI*=D4"Z1Y:7AE[JI4&B/^E*HFQ M2,Y/*Z>J7F4G"8B-TE1LOEF:1L(UE!.?J[-PXK&=>&4Z<)*O3C2I2D0P$N4S M889Y9[U9*FER?%^J4Y-U264Z?2U?'72=;[W+VZ-#85:M2KX"+T]&E]85,=G1 M"J0RS4451;!S5O8!&CU4IF(;J\IT&#*Q='DS/E7U8(O[TXJ&ZOO0JF1\IUF> MBF\SJ_B=L`&HFA=L$%@QGN82J+IK^.IMIH1P83)30KPQJ4XI;JMF3#P3I?J: M:+:4,])J;V=F2HLQWZIYQOD=2M7W&[.EA`N*V3H`33W+)Y0QP*R<=_KF?*9I M8JZ_9R&4S?/P'.9)[FPM#M"BF[C%:(B(S^YA*&AEJ[-$B+2-Q9.8^%ZCUJ@S MKDI(PF((-Y>Q=DABU[!-_1K*0-G0>6.!WIS7R-&=-]K"R'G)>XWS3N\9FRX] M9DO,O)>[I5,.NSBYR;4CRX=,LZ3_BOG$-FB\Y=%&)G7&UR[W;,AY]W\:5@9+[X]^+2HY&V:V"(T+[V@\)1D$7PV&HLPW>TH MT:TDWN:VT0]S)[)?QCJ[."RX913ASLE2,(PY%6.BF!<@OXEL(K;R;-'%VXF9 M%$E^3B1^@"V;?7':LW&V^71(1;Q650)P$$J>H%(TP91M$$5;C,I*9-!!U8UJ M;:)T>^)9MTU./,`Z:X+6PG$9NI,@`?9F0P,\N$240IP(>FPQ=`R6T=.)H%+< M%E'2U5_%K+WZ*Q7D8(58P#&9"]>VDY57>Y#-7X`U8DN3>!AFG%GCX,2Q16`0 M5>:YVJC!O!I5$C9J.:]VS_(/9EO^=$8V^>G1,@_C"._W?A+Y\K43 MVM1FY9.KR8+G99RR3G9SM(6ITA(ELCO[XK0R<%IZ;5"IHLP0I(.G5:1:\LQV5%367#X+VA!A[^"78.]@/5C/&MR$M'#)N5 MGHGX/X9A`EO$.`1`/^`I@L/WS@"J`^'DY#3]&,6V%:0\LDLDO4TG:HX;"0?` MZQ#2/A^O'A5%U%ZQ19/RB-IE5XX97MU!*'N.Y?+I)VTX_+3A\#,=VPDCS_!4 MK&IB"I#RP#'0`I^S^$J+LA'GA?Z`2D,X4B!-?:'B%)>.)YG"5.D`!2J+8:6* MG%?[<,[.QS=38(XX^A4Q*\+>YLG2537&[Q:J6C+5E) M,;'1]..Y[4+,A!/T^=EV+2^EZ4^8#B5SHL0CI%.2\10[MN:>B&"DX^WLP0AS MZ'.,'@X[NL(]G8;Q[ZS>5W`_3.;)#(A8`74IY^)&7Z'4()P&?M!?("U8MZ+`(`RC2K+ M_5(WZ^',H//;;L@#].-RMRT%#)52*$%`@/($-"R"Z+?]A>@L6<#^L[N!]&(&QY0FXX!^V4T!*?C,32$;I#G#7#%6LXGY^4@T M'^=3]*&X"WQX82!`PNNY/1-)<@.1@BKW&9W3SCY%J0$YD\.7A:H$B+$:KHH( M;FR9[CML4\2M90TYSOMUMB!H<=D65/R=MR";H&`+DL/BVXK$8.0'HKR+2C>G MX$Z[D\.:\1(3<#U#QD$E)6X/EMH_E\F_+HDG!'H``+4U' MMB0DE@4*=;_@!DG),FNRSE")KS4T\S5A6"77$"5>!XN76+O7FK#:-R4G]$@1"/79,/+/OJ!C)\`S#=7QKR&#;@2+&E6<=/J+ MP8JD#?-E@-2C.)I07:@A;YKV`V0,=9*(YP'O>Q-^/[<\YWO-,4-X'BA"\[LR M)>Q0[$ML[#BDMS:C1%7.3*'1^`16IIE`)H)L2BW!?8PUJ, MHGHS\PD!@G$Z^8XEZBOA,X_[YV,+HCN_/"\&!A.9<:$LG)02$9;UXJ(!%69D M8]A0"+A8T377S$VDFH5I&P(0'?1(SL\4NI+5+]Z9)=U4Q0Q3]<)3MVJ"0?$S M3#*G%L^L@NIFG%2=NTPJ8PK7)LD.YQ/1&J7V*R(S`W1^#Z/0^8*P:+EF8(^Z M9P.#]P:N&/!_8;+T<3R:)NJ`'3D\A^"O#?:U\.<(*,./[UX?O#_>/SQ14I\6 M]U3!Q)B0']D1P?<^[H+QB1!0^@PDHA31I!]YDCY17T?@1>699`:\/]JD`[B-J&_W=$,UO<9?H`<_(19R; M!"*2K++44(]&'UP1MXRDXB3OCWYPX/'P0&--=*R:)/BS>DD^CX,0_;<(!%K) MJY.PC1'10=10;S!4>AHTYC`Z0_!?^-AR$@(O^TFK\G3$>KQ0_0GSB,#S$"<: MH]$/+',3TB'\:TXNB1`-\Z<<8GV0P<[G!9U3)K%GJK_;$U0K&`+P)A%K"]#! MXO&%*4T$A@I%)$`9C!Z>33\/;S@DX=&]>V+0K,#0;B?<7@SH7EM MJ$5]()")`K4MYK'L']W;BM52GW#$0M6O,-U_BDU#2T8`#I%]@I"F=F_:OL$Z M893L>"* M<0(HW(O4,,HQK[7;BAPE.L!0\SB)":V'*#/0XJ=G?6S*XUY^19W+ILRR"U;)S+ MBE0&9W7SBLZQ#%HB_LF>GZF>6:IG:"8?M&%[2S0"\V,;9,,TBKE7Y7/=&X,) MR09-A,B<;5'C@!;JC6^75CKITM)2DX^U-DB-/=]";DT@]>D"-*6H*&DZO23H`B79=.C4MJ#S`+@!P9W@ MA9033B4FSIR3T2U1=D"\0X$$T4C\W8[-57%H*^K\*V_H:#U.X&33#*XV"_L, M$!U(0@"Q`*$Z!FA1%-Z`I9&Y@&,7"7&`81TZXH3K1/F[N:&.8P>+YPQ/D+PH)*V(X>%BG63%5$K00?:E4Y$'J)%`56]+>NJ['!O MXL)6C*>2>M>%R4?T>%I)K"JDFDB9J#`8)5&GK5PRABT^C@SD50>95*FJXTNJ M1-Z-V--J:@R66MDO51&2;9/1,DL1`T$VP6OA.IP?HMK0V_#)3`V?S-+PB;_A MD`6`+-3Y8N\=C(NFN\GL[#]Y$Y0560:AP8B8)QHC$[`\M!;SNHMK)F M,#VE08X(J$?,H[M%@4]F"`(/GIPS!(%/G!CP'CI*0\!G"?%,8J:C.`*\,[(& MG:AMPKND9/X=Q6>CG)^,&MWB?A+%E3,[TC('4_=>=LB\KZ*#NT;U&X#5"_G* M$K'"QAA5(E.^7B7S&&:@>=L83PPYG"3J3&IK(.@3<%+1RHKR,#N&BV=M89"H MN]G#E%9"IC>4B0JW&71'?91.6:*'SM2'E,.6.&&KU:&/Z-0=5:^I[822TWTY M9CCU20I>EKX+'I6NB7HJY=JFXVVS1,^2):MG09O54.6V/\3[LERK MU`G:P[8@>R7?PCJJ^1:3,I-GMX]SY6CQL"XFI9AUE6Y2B`]G8PNJ![%!>V,+ M7OVU\DRB2JD^D3IT^PL#N4%%+OG5Q_9?0[A5$:U2.,0J8'Q*#Z:]E'G MT\KH3/K\44+8(%RW>@_=7&I%I*>8X\E)$=BCE\$T?O&7)-CGP0K(OO2P#9'2 MO:P6;.@W`NFLSUG`2A*4D:?AY!K"EJV@3K*[KGA2(://#$/`D1>@6`SK&VS1 MU5'1>+AIF9!V1=A&BP]'@EE/^LYKUPOU9T\Z5'B&QY13/D"V.N1^@VG2T!Q: M#X!(DC$0L5_(^)?,0TJU?@X"GJ>%`AW`B)'E#94EEK?5J;NPN6ZJ3(N=CU6- M%JTFWWM6KKJ.^!0W4KKD![Y68J;R]NG`YS8J)"\O1PK@/*R&'Y MM@G%%[B?G8)7'C1+OVY<`V+R=:B!>,\'1B-6?;S62:O/V#IE"[C' M+"H&TX1_;(EJ2K8ZH79S%GF^T_BRC[K,8';09,?.\L-W^/J*4E:SX5A8M/.% ME)H@:NKIKDNTQXTTUN)V\+7^0H)L-[9W5Q#3'LK`3N70X@DL&WA9',=87ER! M-UKAY56B[U\=>]4:T$JD8XUP`8OQ73LW*YW@^580@[`6PU^=FZ>OX$N,UE0W M:[OTH.2YFU>OR@GL]^`8S"-AK^<[-]_>()6QH,VYGJ:WX*`*(CP$5OI1U;@= MK'V`J=0-GC\'DI^HDKJOH`S3NRA3MO!"GA\";2TL]A=)$V_BHO^P<0&\INK_L"$;*EY?@RH7MF=@PO)C= M:[)&R&Y0=C(HW2>;&2Z>:65:IEB%:NELB:"/G*)I1D`TJ)8"IH M'H[O(8^M0#5U#:_PG6KMI7P_(>/3`@N8%]I&TMZVZBY#$TFXF:6NP_3+HBF* M'B#E"?=.$PW*M7%,J<<)T$78XXTW[U^?[!X<0*N$Q-7NVEF-?Q!NHPE]:>QN MW;[@8="8?Y[NH,\2_$^]1RSO[':=#YS-5R)Z8MDK$3FMA)^9?P$5A+<]OS'M"/5-'9RN$$P440#&O#>-L06?&$$>8?9\55?G**>LCY!LXQQ8T M-?,_=>:9WS=T=&D;;MGX^[6[CH&4+WBU26NT13YU$<1\B''X-@J\+]O:$,\: M!=5*XUZ3.90W]&W-2'#9^+?9V+>8LBP`+OK@T*+2AD2>R-J%6Y]*FX^\SAV@ MRE#3K:?+,56V5-\C8>=]H-+WJ M&LICC5VR\*CEEQ8".`3$?P?F(QJ$/72@G8Z='<>E0&:&\U$T+B0 M(#C351)4;@O`!)DI7461AG=H&Z`'Z)4<7P*3LP$"1#TSGN4[ ML]Q^[[CMYEE6CM3>$+3CMP3'UV+GGE,$%LQS+88#,HBN>I*0DDT*,QZ^;74?.8E& M&W26;.*Z9+O%H7NT9XL%RU7/KN?R(,8":1OP3X$.HF-`82L%/HSO/,?9RA4! M/,,)]-KV$=8G]\$%]L7%?1#](3553X)_PK_B).-Q:V6+5,Y2=:N&_^C$6TR< M8`ZN$O&`7N(ED[[=-'4M!3O6Y.%OX7@47(:]&&Q.307G/;RU/@4ML.JV)=*V M`>32P>O#X\/=EXBH@/U4?QU.WF*?JCYIR@ZDF2"M#74'L:8GHXPEK!OK?\B! M.(KN/]S<##;JR;TR0VZ-\VRRF\@=L]6.@#@F,\'C^-FWFP\G>RY?9Y9\%_9. MB:'E9ZI1@$R:`F3@BEG*T.>#$EU:D03O%=ZOT%;2E;7*9'=:$=4-K5!U:UKH M%MA/!W?/N$+CZR.`=O'92'!DSV)**F3/"H+@6M&,>?D=HR^[!):<>=B(?@8ET3^_.R*L)1F M:9\0MF':0GA"$YV]%2CV[]NO+03HYQ!WEE[.$'>><4+OH2+5-BBI-/@\`XG> M3VU0DEK+515^]BC;&N/>Q7`T2KPU"4323ZT,U_]LPZ912^^CJED&3L.:WE-] MLPR=`3_]\F-G\5$_M2XP5H.*INE)Q<@QBNH]5`3C5M:!`F?U4VN#(F:8C1J' M]7.K42TZJ6S2Y^P.NB(@-K-#Y"%3';Z<0S]E$FJ9^ND9#!*$K`(@1^;*:`M. ME?K%92_)R#60E@PF\4ZY!G6/+MAXK,8F;WSG9(+X(D@'.-BJ[WACI!(,5M3G MX1!.BO0$^VTM.C,74/H"Q5Q$K36WMI3`6J_5`-]C*WBB+U'6/A"(5>,1?(`K M.V@'I[5G-JP>32CAIEN;9YH++6YK*QO:/N#;+;C<,FFP0_&+>K5%%IWZ(YAT M;A(]ZI57MSI';MP:NQQHV7!.FT$6'.E7V[OHU(:*$#7H$QU7NS\:C]'"1G4! M>%ZCBS;$G>Y-X$BIF[QAOCTV2`1L,(U%]L"?&+_K0<3CT`9)N9_V@1S!^;:X M\>@L')U!9S%B%LP@E9.0%MC&0SUC!]CK_E]@_&ID\AD0C)B=E"UL7I.P9TP7 M(9:A&@6<[9T/6UL(#6`P"S`Q(C28?D`JY1SDFO`FE6F$21@0Y7B9CU4M\E=1 MJ.X,I(*;OI"`PD7[<"]`#R2+BYLF#T)%$%($95/CU_AE*]E4[4=5CHL0=3%7%"Y2>_L7./WE("13>G+3KM5(>0[3CVU< M8>2L+F1T06J#^F\=A_[A]]O\R"$Z73[8W7GY=O?+U-'M=-;75X/?!4'WV5H' M_E4__:]ZV>EV@V"]\[2[LOIT9?69>M-=6>O^+NA\&7+OTX!6Z'FO3;T10LGUBW>JLAM29@Q:\R&886RTVCEP6#:(SVD[<(HT3!B:(X"#D# MI`,4<>*X%`%P3S%?2LDAG/1Y>A*KQ>?ST.0Z2C_N)\'*63J!?7Z^UV M_6B4O(GBB^#UZ4$KV`/!,%9<^U#)AU$_3&OP`Y^3_YB,$L7]+Y8&86!+"/ZH M.O5OX1B3!>>32;*QO'Q]?;UD4R_7]\_5(&P$M<75[X-GJVLKP7?/NL]6ZZ]Z M-]F7:[7:*T7F'PY?JIX>7:@^@`N31P\;P+_G3_-_,YF_0!W!:N?9L[5"_H\/ MS/]7GCU=4\E6NBLKOPO6O@`MN=^_.?_/C3]SP?NSIZK.G#^/_ M-7Z%X\\[_WW4`?)?IU,\_JNKZV;\5]=A_:]UUSL/\M_7^#VNHR(AF0Y3D(Q` M3I+`N.JKEJW`_@'E'@VW7%=YN]^O+'77OUM:65M=ZF[(IY5:[;&QCE"26@/@ ME^#Z"DQ)FG5]*[ZRMK:D_^O4((_^TD#`)G.=UJR;P"V8[`<=N45&;*FS%SJG MN>Y%)JQ9G6.MX`>Z%4;'GL?ZHHR^`*JT?E-_W&Z'\4`)<+_U*'VY7^'Z5R+[ M-+F?.M3Z?U:V_M789];_JF(`#^O_:_P>/UH^C>+E]%RM]&^Z072&.M!O5K2) M>^N;IZ#50^^(UC>KJ.%#*_%OUA"CFK2$R]-TO)Q"071!/0B'H?I'I1&?X)JY M/?"]3.'ESWUUT#-0TR'8<:%-T%(XZ/X<)-/3X%]X&?YFO[+U/QA=Q_=11^7Z M[ZYD]__.TY6']?\U?O>]_LTBK]-S=$::(2@=S/I?7WV0_[_.#^3_O7V-A!B\!>VL$IA?<@#/_?W].AT1XDDO M4H<":T_-*M9!U%/S`U6R-%,P?2U*YE.XN#3A)K4'!EA%II""OJB3@89(&$1G M9^$8#./1`W\$PGE0`[4PQ1`E8%E9[M-3_>F[W*=5_>G[W*"+D ML/3\$^=8Q?V/8@#/Q/I?QV1/5Q_6_]?XV?T?=NZ?M#[<"5RQ\V[?_OO\+U[P[T9]51M?^K`T!F_:^O=![6_U?Y=3;ZG8W> M=QM/US?ZX<;*=P\K^M_KEUO_?)G]F]W_K(+\_W1M[>'^[ZO\"L>?=/SW4D>5 M_-<5^I]GJZN@_U73X('_?XW?8VW=TD!G$NG=V'=N@YKUC!%/1D'PL'$\_!Y^ C#[^'W\/OX??P>_@]_!Y^#[^'W\/OX?=_]O>_1#ORD@!``0!/ ` end ----------------------- cut here ---------------------------- -- TopLink GbR, Internet Services info@toplink.de Christian Kratzer http://www.toplink.de/ Phone: +49 7452 87174 Fax: +49 7452 87175 FreeBSD spoken here! From owner-freebsd-hackers Sun Sep 24 05:09:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA22434 for hackers-outgoing; Sun, 24 Sep 1995 05:09:06 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA22429 for ; Sun, 24 Sep 1995 05:09:03 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id HAA28366; Sun, 24 Sep 1995 07:57:12 -0400 Date: Sun, 24 Sep 1995 07:57:10 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: ports startup scripts To: Peter da Silva cc: hackers@freebsd.org In-Reply-To: <199509240313.WAA01237@bonkers.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 23 Sep 1995, Peter da Silva wrote: > In article , > Jonathan M. Bresler wrote: > > each rc?.d is a separate directory, with possibly distinct files. > > If you don't have the files with the same "service" name linked to each other, > you have a messed up installation. That's no worse than having bootleg stuff > in /etc/rc instead of /etc/rc.local. with hard links, i cant tell if they are the same or not until after running 'ls' on them. (you know this ;) ) why not a system that shows they are the same? > > with the K* and S* files in different directories, one for each > >run level, ascertaining the differences is needlessly harder. > > There are no differences unless you're using a broken editor. i dont understand this. what editor are you suggesting? > Add a check for that to /etc/daily. a check for what? for identical files? why?? i may want to start cron in exactly the same fashion in more than one run-state--say multi-user and full-network. > > consider instead a file that lists which scripts to run for each > >'run level or the term of the day we are using' and the order of > >execution. now if both level A and level B need script Sfoo, there is > >only one Sfoo. no symlinks required. no hard links required. it is > >immediately obvious what is differnct and what is the same among the run > >levels. > > And you have to trust 150 packages to edit this file without clobbering it. copy the file to /tmp. edit the version in tmp. display the diff. either prompt for accepting the change (all ports that add services become interactive) or report the new file's location and ask the user to verify and install. regardless of method, the user has to startup the new service or reboot or run ldconfig or .... > And you have to trust 100,000 system administrators to do the same. Getting > them to "mv KXXfoo .KXXfoo" is easier. how about mv /tmp/all_daemons_file //all_daemons_file > We have ... novice ... system admins at work. The number of botched systems > went way down when we copied the run-level stuff from System V to our Xenix > boxes. DEC thought the same thing... that's one of the things they picked > up from System V for Digital UNIX... and they have been gratifyingly > conservative about that. > > I'm not that averse to having a unified directory, but each component should > have its own startup and config file. okay, sounds good. one file, one service. one master file that coordinates them all. > Like I said in my original response, just having /etc/rc.d with S and K > scripts run by /etc/rc and shutdown would be a massive improvement. isnt this the one file that each port has to modify. an objection you raised above? > Run levels are *also* useful. > > Something like /etc/default to hold all the random *.conf files (/etc/conf.d?) > would tidy up /etc no end too... yes. without doubt. jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 05:14:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA22547 for hackers-outgoing; Sun, 24 Sep 1995 05:14:58 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA22540 for ; Sun, 24 Sep 1995 05:14:55 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id IAA28398; Sun, 24 Sep 1995 08:03:04 -0400 Date: Sun, 24 Sep 1995 08:03:02 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: multiple mail messages To: Nate Williams cc: hackers@freebsd.org In-Reply-To: <199509240419.WAA07762@rocky.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 23 Sep 1995, Nate Williams wrote: > [ Multiple email messages ] > > > > People are generally too lazy to trim the Cc lists even when they know > > that all recipients are actually on the mailing list. > > Actually, I *intentionally* leave people on the Cc lists if I think the > material is going to be discussed some, since with the bulk_mailer stuff > it is difficult to discuss topics with any sort of speed, since it may > take a very long time for the person to get the reply via the mailing > list. now, now, nate. with bulk_mailer mail will always reach more people faster than without. consider the case of a couple slow/bad addresses in the list. without bulk_mailer those addresses slow delivery to everyone. with bulk_mailer only some subscribers are affected. (yes there is a degenerate case in which all subscribers can be affected, given a set of bad/slow addresses where at least one bad/slow address is attached to each message generated by bulk_mailer. but it it rather unlikely and will be perterbed by the next (un)subscribe to the list) you dont really want to return to the bad old days when sending a mail messages could be a 20 hour affair, do you? (boy...am i in a cheeky mood this morning! :) > > > That's why i'm > > defending myself by dropping my name out of reply-to (ok, Nate, my > > procmail is still not set up). > > *grin* In case you didn't know, procmail has a 'feature' which allows > it to filter out duplicate email messges by using the Reference field. > It's one of many reasons to use procmail. > > > > Nate > Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 05:39:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA23304 for hackers-outgoing; Sun, 24 Sep 1995 05:39:36 -0700 Received: from toplink1.toplink.net (toplink1.toplink.net [194.163.120.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA23295 for ; Sun, 24 Sep 1995 05:39:30 -0700 Received: (from ck@localhost) by toplink1.toplink.net (8.6.9/8.6.9) id NAA02437; Sun, 24 Sep 1995 13:38:48 +0100 From: Christian Kratzer Message-Id: <199509241238.NAA02437@toplink1.toplink.net> Subject: Re: pppd server with dynamic ip assignment To: imb@scgt.oz.au (michael butler) Date: Sun, 24 Sep 1995 13:38:48 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509241222.WAA21144@asstdc.scgt.oz.au> from "michael butler" at Sep 24, 95 10:22:12 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 881 Sender: owner-hackers@freebsd.org Precedence: bulk Hi > The person to speak to is probably Rod Grimes as his "signature" appears in > the RCS identifiers. If it's a small(-ish) patch, you could probably post it > to the -hackers list anyway. Actually Peter Wemm who said he was currently incorporating a new pppd already contacted me. The patch is on it's way to him and has also been cc'ed to hackers. > > We do not yet run gated or anything similar so proxy arp was the quickest > > way to get started as we also have dial ins divided over two machines > > currently. ;-( > > Ah .. yes, that does make it difficult. I had no choice, the dial-ins that I > manage are 4km apart and the routers get very confused if I don't :-) ok! Greetings Christian -- TopLink GbR, Internet Services info@toplink.de Christian Kratzer http://www.toplink.de/ Phone: +49 7452 87174 Fax: +49 7452 87175 FreeBSD spoken here! From owner-freebsd-hackers Sun Sep 24 05:50:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA24087 for hackers-outgoing; Sun, 24 Sep 1995 05:50:08 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA24082 for ; Sun, 24 Sep 1995 05:50:05 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA04973 (5.67a/IDA-1.5 for hackers@freebsd.org); Sun, 24 Sep 1995 07:47:39 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA06911 for hackers@freebsd.org; Sun, 24 Sep 1995 07:41:54 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509241241.HAA06911@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Sun, 24 Sep 1995 07:41:53 -0500 (CDT) In-Reply-To: from "Jonathan M. Bresler" at Sep 24, 95 07:57:10 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1630 Sender: owner-hackers@freebsd.org Precedence: bulk > > > with the K* and S* files in different directories, one for each > > >run level, ascertaining the differences is needlessly harder. > > There are no differences unless you're using a broken editor. > i dont understand this. what editor are you suggesting? Some editors break links by renaming the original file to .bak. VI doesn't. > a check for what? for identical files? For non-identical files. Files with the same tail should be the same file. > copy the file to /tmp. edit the version in tmp. display the > diff. either prompt for accepting the change (all ports that add > services become interactive) or report the new file's location and ask > the user to verify and install. And you expect everyone to do that consistently? See, the problem is you have lots of people with varying levels of competance writing install scripts, often trying to make the same script work on BSD and System V and OSF/1 and NextStep and... > > I'm not that averse to having a unified directory, but each component should > > have its own startup and config file. > okay, sounds good. one file, one service. one master file that > coordinates them all. NO. No master file. There is *no* justification for one. (If I had my druthers I'd have an /etc/inetd.d as well) > > Like I said in my original response, just having /etc/rc.d with S and K > > scripts run by /etc/rc and shutdown would be a massive improvement. > isnt this the one file that each port has to modify. an > objection you raised above? Nope. You only move files into and out of the directory. I even ported this scheme to my Amiga. From owner-freebsd-hackers Sun Sep 24 06:27:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA25881 for hackers-outgoing; Sun, 24 Sep 1995 06:27:04 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA25876 for ; Sun, 24 Sep 1995 06:27:00 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id JAA00245; Sun, 24 Sep 1995 09:14:02 -0400 Date: Sun, 24 Sep 1995 09:13:56 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: ports startup scripts To: Peter da Silva cc: hackers@freebsd.org In-Reply-To: <199509241241.HAA06911@bonkers.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Peter da Silva wrote: > > > > with the K* and S* files in different directories, one for each > > > >run level, ascertaining the differences is needlessly harder. > > > > There are no differences unless you're using a broken editor. > > > i dont understand this. what editor are you suggesting? > > Some editors break links by renaming the original file to .bak. VI doesn't. solves the rename problem. not the 'is it the same of is it not, i have to did deeper' problem. startup and shutdown are inherently complicated with strict order dependencies (eg mount, nfs, ifconfig, routing, ......) a single file (that may well invoke others to do the work) serves as a clear outline of the startup/shutdown process. > > a check for what? for identical files? > > For non-identical files. Files with the same tail should be the same file. should, but you question consistency and ability of those writing install scripts. same question applies to files, contents, and filenames. with all of them in one directory, one can NOT have a single filename performing two non-identical sets of commands. removes a source of possible error > > copy the file to /tmp. edit the version in tmp. display the > > diff. either prompt for accepting the change (all ports that add > > services become interactive) or report the new file's location and ask > > the user to verify and install. > > And you expect everyone to do that consistently? > > See, the problem is you have lots of people with varying levels of > competance writing install scripts, often trying to make the same script > work on BSD and System V and OSF/1 and NextStep and... i expect the ports-meister and packages-master to enforce that level of consistency. the newbie sysadmin expects/wants clear unequivocal directions. the experienced one will do what he knows is 'the right thing' ;) > > > I'm not that averse to having a unified directory, but each component should > > > have its own startup and config file. > > > okay, sounds good. one file, one service. one master file that > > coordinates them all. > > NO. No master file. There is *no* justification for one. > > (If I had my druthers I'd have an /etc/inetd.d as well) no master file?? what executes the individual files and determines the order of execution....ascii sort order in a shell script? thats a master file which is generated on the fly. and must rely on numerics to determine execution order rather than names. (eg 67 vs named, we could use 67named, at least. preserve sort order and provide information regarding action taken) master file could be a shell script, but in place of ascii sort order, a shell variable and a 'for x in $daemons' loop. (are we much closer to agreement than i realize?) > > > Like I said in my original response, just having /etc/rc.d with S and K > > > scripts run by /etc/rc and shutdown would be a massive improvement. > > > isnt this the one file that each port has to modify. an > > objection you raised above? > > Nope. You only move files into and out of the directory. > > I even ported this scheme to my Amiga. > ;) Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 06:43:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA26547 for hackers-outgoing; Sun, 24 Sep 1995 06:43:19 -0700 Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA26542 for ; Sun, 24 Sep 1995 06:43:17 -0700 Received: (from pechter@localhost) by shell.monmouth.com (8.6.12/8.6.12) id JAA27446 for freebsd-hackers@freebsd.org; Sun, 24 Sep 1995 09:45:14 -0400 From: Bill/Carolyn Pechter Message-Id: <199509241345.JAA27446@shell.monmouth.com> Subject: Linux emulator and AT&T's KSH93 To: freebsd-hackers@frebsd.org, freebsd-chat@freebsd.org Date: Sun, 24 Sep 1995 09:44:12 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1078 Sender: owner-hackers@freebsd.org Precedence: bulk Just for grins -- I downloaded the AT&T ksh93 for Linux and ran it on FreeBSD-stable. In addition to the shared libraries being a bad match (the ones I found in my Slackware weren't any good either)... I picked up the following error from the system. If this is the only thing missing from the Linux emulator -- we're doing pretty well. How about a linux-emulator mailing list? Any support for ELF being considered. (I'd love to run the Caldera desktop on FreeBSD). Sep 24 09:27:47 i4got /kernel: Linux-emul(262): syslog() not supported (BSD sigreturn) Sep 24 09:28:13 i4got last message repeated 3 times Sep 24 09:28:44 i4got /kernel: Linux-emul(270): syslog() not supported (BSD sigreturn) Sep 24 09:28:54 i4got last message repeated 2 times Bill ------------------------------------------------------------------------------- Bill Pechter/Carolyn Pechter | The postmaster always pings twice. Lakewood MicroSystems | 17 Meredith Drive, 908-389-3592 | Tinton Falls, NJ 07724 pechter@shell.monmouth.com | From owner-freebsd-hackers Sun Sep 24 06:58:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA27110 for hackers-outgoing; Sun, 24 Sep 1995 06:58:56 -0700 Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA27093 ; Sun, 24 Sep 1995 06:58:51 -0700 Received: (from pechter@localhost) by shell.monmouth.com (8.6.12/8.6.12) id KAA27727; Sun, 24 Sep 1995 10:00:48 -0400 From: Bill/Carolyn Pechter Message-Id: <199509241400.KAA27727@shell.monmouth.com> Subject: Linux emulator To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Date: Sun, 24 Sep 1995 10:00:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 882 Sender: owner-hackers@freebsd.org Precedence: bulk > Just for grins -- I downloaded the AT&T ksh93 for Linux and ran it on > FreeBSD-stable. > > In addition to the shared libraries being a bad match (the ones I found > in my Slackware weren't any good either)... > I picked up the following error from the system. here's another looks like mount() as well as syslog() don't work. so far everything else seems great. Sep 24 09:45:21 i4got /kernel: Linux-emul(378): syslog() not supported (BSD sigreturn) Sep 24 09:47:52 i4got /kernel: Linux-emul(385): mount() not supported Nice piece of work, though. Bill ------------------------------------------------------------------------------- Bill Pechter/Carolyn Pechter | The postmaster always pings twice. Lakewood MicroSystems | 17 Meredith Drive, 908-389-3592 | Tinton Falls, NJ 07724 pechter@shell.monmouth.com | From owner-freebsd-hackers Sun Sep 24 07:11:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA27719 for hackers-outgoing; Sun, 24 Sep 1995 07:11:47 -0700 Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA27714 for ; Sun, 24 Sep 1995 07:11:40 -0700 Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id WAA04847 for freebsd-hackers@freebsd.org; Sun, 24 Sep 1995 22:11:09 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-hackers@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-hackers@freebsd.org Date: 24 Sep 1995 22:11:04 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <443oto$4nb$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199509241222.WAA21144@asstdc.scgt.oz.au>, <199509241238.NAA02437@toplink1.toplink.net> Subject: Re: pppd server with dynamic ip assignment Sender: owner-hackers@freebsd.org Precedence: bulk ck@toplink.de (Christian Kratzer) writes: >Hi >> The person to speak to is probably Rod Grimes as his "signature" appears in >> the RCS identifiers. If it's a small(-ish) patch, you could probably post it >> to the -hackers list anyway. >Actually Peter Wemm who said he was currently incorporating a new pppd already >contacted me. The patch is on it's way to him and has also been cc'ed to hackers. I've been asked to hold back until FreeBSD-2.1 has been released, as it would make David's job more difficult with bigger diffs to read through. BTW: the name in the $Id$ line isn't really a good guide as to who's the maintainer. Right before 2.0.5 was released, Rod was the one who did the (infamous) "Delete trailing whitespace" cleanup, so his name is the last one that was stored on may files in the release. Incidently, I'm not sure that this patch is the best way to do it.. From what I've seen, it looks like it might be just as easy to create a hack script like this: % cat /etc/ppp/startup #! /bin/sh case "`tty`" in /dev/ttyd0) args=":ppp-005.toplink.de" ;; /dev/ttyd1) args=":ppp-005.toplink.de" ;; /dev/ttyd2) args=":ppp-005.toplink.de" ;; ... /dev/ttyd7) args=":ppp-010.toplink.de" ;; *) echo "This tty not supported.."; exit 1 ;; esac exec pppd $args And set the login shell of each "user" to be "/etc/ppp/startup". Their .ppprc will still work the same. Cheers, -Peter >Greetings >Christian >-- >TopLink GbR, Internet Services info@toplink.de >Christian Kratzer http://www.toplink.de/ >Phone: +49 7452 87174 >Fax: +49 7452 87175 FreeBSD spoken here! From owner-freebsd-hackers Sun Sep 24 07:49:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA29050 for hackers-outgoing; Sun, 24 Sep 1995 07:49:15 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA29045 for ; Sun, 24 Sep 1995 07:49:08 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA05504 (5.67a/IDA-1.5 for hackers@freebsd.org); Sun, 24 Sep 1995 09:48:08 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id JAA09429 for hackers@freebsd.org; Sun, 24 Sep 1995 09:34:56 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509241434.JAA09429@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Sun, 24 Sep 1995 09:34:56 -0500 (CDT) In-Reply-To: from "Jonathan M. Bresler" at Sep 24, 95 09:13:56 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1830 Sender: owner-hackers@freebsd.org Precedence: bulk > solves the rename problem. not the 'is it the same of is it not, > i have to did deeper' problem. Sure. If you do it right you just need to make sure it's a symlink. > startup and shutdown are inherently complicated with strict order > dependencies (eg mount, nfs, ifconfig, routing, ......) That's why the file names start with a number. > a single file (that may well invoke others to do the work) serves > as a clear outline of the startup/shutdown process. So does a directory. > should, but you question consistency and ability of those > writing install scripts. same question applies to files, contents, and > filenames. But those are easy: In /etc/daily: find /etc/rc*.d -type f -print > /tmp/$$ if [ ! -s /tmp/$$ ] then echo "Warning... files in /etc/rc.d" cat /tmp/$$ fi rm /tmp/$$ > i expect the ports-meister and packages-master to enforce that > level of consistency. You're assuming that only official ports are going to use this. Bad assumption. > > (If I had my druthers I'd have an /etc/inetd.d as well) > no master file?? what executes the individual files and > determines the order of execution....ascii sort order in a shell script? Yes. > thats a master file which is generated on the fly. Yes. Your point being? > and must rely on > numerics to determine execution order rather than names. (eg 67 vs > named, we could use 67named, at least. Exactly. That's precisely what System V does. Actually, it has: S67named K45named So you can have different startup/shutdown orders. I don't know that's necessary. > master file could be a shell script, but in place of ascii sort > order, a shell variable and a 'for x in $daemons' loop. That's not a master file that has to be edited. > (are we much closer to agreement than i realize?) I suspect so. From owner-freebsd-hackers Sun Sep 24 08:30:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA01262 for hackers-outgoing; Sun, 24 Sep 1995 08:30:08 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01257 for ; Sun, 24 Sep 1995 08:30:02 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA08236; Sun, 24 Sep 1995 09:32:07 -0600 Date: Sun, 24 Sep 1995 09:32:07 -0600 From: Nate Williams Message-Id: <199509241532.JAA08236@rocky.sri.MT.net> To: "Jonathan M. Bresler" Cc: Nate Williams , hackers@freebsd.org Subject: Re: multiple mail messages In-Reply-To: References: <199509240419.WAA07762@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk > > > People are generally too lazy to trim the Cc lists even when they know > > > that all recipients are actually on the mailing list. > > > > Actually, I *intentionally* leave people on the Cc lists if I think the > > material is going to be discussed some, since with the bulk_mailer stuff > > it is difficult to discuss topics with any sort of speed, since it may > > take a very long time for the person to get the reply via the mailing > > list. > > now, now, nate. with bulk_mailer mail will always reach more > people faster than without. Agreed. But, it still may take 2-4 hours for a reply to reach them depending on the state of the people in their 'group'. This wasn't meant to be a criticism of bull_mailer, but a statement of the way things are. Nate From owner-freebsd-hackers Sun Sep 24 08:31:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA01376 for hackers-outgoing; Sun, 24 Sep 1995 08:31:13 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01368 for ; Sun, 24 Sep 1995 08:31:09 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA08242; Sun, 24 Sep 1995 09:33:06 -0600 Date: Sun, 24 Sep 1995 09:33:06 -0600 From: Nate Williams Message-Id: <199509241533.JAA08242@rocky.sri.MT.net> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: nate@rocky.sri.MT.net (Nate Williams), hackers@freebsd.org Subject: Re: multiple mail messages In-Reply-To: <199509240747.IAA29850@uriah.heep.sax.de> References: <199509240419.WAA07762@rocky.sri.MT.net> <199509240747.IAA29850@uriah.heep.sax.de> Sender: owner-hackers@freebsd.org Precedence: bulk > > > People are generally too lazy to trim the Cc lists even when they know > > > that all recipients are actually on the mailing list. > > > > Actually, I *intentionally* leave people on the Cc lists if I think the > > material is going to be discussed some, since with the bulk_mailer stuff > > it is difficult to discuss topics with any sort of speed, since it may > > take a very long time for the person to get the reply via the mailing > > list. > > Do you remind that many people are not within a "can get'em within 10 > minutes" US Internet anyway? :-) Ahh, but generally speaking when 'discussions' are in effect you do get email messages going back and forth fairly quickly. These are the most typical email discussions I speak of. Nate From owner-freebsd-hackers Sun Sep 24 08:31:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA01435 for hackers-outgoing; Sun, 24 Sep 1995 08:31:43 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01428 for ; Sun, 24 Sep 1995 08:31:39 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id LAA03292; Sun, 24 Sep 1995 11:19:41 -0400 Date: Sun, 24 Sep 1995 11:19:40 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: ports startup scripts To: Peter da Silva cc: hackers@freebsd.org In-Reply-To: <199509241434.JAA09429@bonkers.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Peter da Silva wrote: > > solves the rename problem. not the 'is it the same of is it not, > > i have to did deeper' problem. > > Sure. If you do it right you just need to make sure it's a symlink. urg....symlink. two files. requires diff or ls -F to determine if same or not. why require this? what is the benefit? to use the same to do the same task but in different order a new name is required, due to the sort order mechanism. this is an artifact of the ascii sort order being used to determine the order of invokation. it provides no information to the user, only obscures the identity relation between the two files. not good. > > startup and shutdown are inherently complicated with strict order > > dependencies (eg mount, nfs, ifconfig, routing, ......) > > That's why the file names start with a number. > > > a single file (that may well invoke others to do the work) serves > > as a clear outline of the startup/shutdown process. > > So does a directory. one directory for all run-states?? or one directory for each. i am advocating one directory for all start, kill and restart scripts. > > should, but you question consistency and ability of those > > writing install scripts. same question applies to files, contents, and > > filenames. > > But those are easy: > > In /etc/daily: > find /etc/rc*.d -type f -print > /tmp/$$ > if [ ! -s /tmp/$$ ] > then > echo "Warning... files in /etc/rc.d" > cat /tmp/$$ > fi > rm /tmp/$$ yes. but when i want to understand the startup/shutdown process running a piece of /etc/daily is...not the obvious step. > > i expect the ports-meister and packages-master to enforce that > > level of consistency. > > You're assuming that only official ports are going to use this. Bad assumption. if you are using a non-offical port, you are NOT a newbie. if yoy really are a newbie, well, either you overestimated your capabilities or your gaining experience ;) > > > (If I had my druthers I'd have an /etc/inetd.d as well) > > > no master file?? what executes the individual files and > > determines the order of execution....ascii sort order in a shell script? > > Yes. > > > thats a master file which is generated on the fly. > > Yes. Your point being? that both use a master file. one exists as a file, the other exists as an artifact of ascii sort order (not obvious to our poor newbie, especially when we have to explain that 10 comes before 2). a list of tasks/scripts is clearer to our newbie and easier for everyone else. for instance: (concept, not correct implementation) multi_user = "syslog cron" network = "syslog cron_net ifconfig named" now i know that both use the same syslog start script and that they start cron differently. the order is explicit, not implicit ascii sort order > > and must rely on > > numerics to determine execution order rather than names. (eg 67 vs > > named, we could use 67named, at least. > > Exactly. That's precisely what System V does. Actually, it has: > > S67named > K45named > > So you can have different startup/shutdown orders. I don't know that's > necessary. yeah, i dont know shy either. > > master file could be a shell script, but in place of ascii sort > > order, a shell variable and a 'for x in $daemons' loop. > > That's not a master file that has to be edited. > > > (are we much closer to agreement than i realize?) > > I suspect so. ;))) in summary, my druthers are: one directory for all start and stop scripts explicit invocation order, a list one name per script regardless of run-state/level (no links hard or soft) explicit names: Snamed (start.named, whatever) comments: dont have to flip directories to see how level 0 differs from level 1--just check the list no ascii sort order surprises ( 0 1 2 243 43) no having to chase links increased clarity (i hope) jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 08:31:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA01466 for hackers-outgoing; Sun, 24 Sep 1995 08:31:50 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01459 for ; Sun, 24 Sep 1995 08:31:47 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA27363 for ; Sun, 24 Sep 1995 11:38:44 -0400 Date: Sun, 24 Sep 1995 11:38:44 -0400 Message-Id: <199509241538.LAA27363@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Sender: owner-hackers@freebsd.org Precedence: bulk >>Is there a generic or recommended way or example of installing a device's >>interrupt routine at mod-loading a device driver LKM time ? > >See pcibus.c:pcibus_ihandler_attach/detach. > >There are some minor problems with these routines: > >- the `func' arg should already have the correct type (inthand2_t). >- `deviced??' should be spelled `device_id??' >- it isn't possible to give a correect device_id. 0 is for clkintr. > The device_id is only used for counting interrupts. To fix this > you would have to expand the string table in vector.s and edit it. >- 1ul should be 1u. >- update_intr_masks() and INTREN() and INTRDIS() may need to be called > at a high ipl or with interrupts disabled. The whole routines may > need to be called at a high ipl or with interrupts disablied. >- INTRDIS() in pci_ihandler_detach() isn't right if several devices > are sharing the interrupt. >- INTRDIS() in pci_ihandler_detach() isn't right if the unregister_intr() > fails. > >>Does one have to copy the old isa_devtab_xxx[], expand it with an entry >>and exchange it with a new one ? > >That might work. You would have to edit the interrupt name string table >too. It would be better to supply a dummy driver and replace that, > >>What is the way to tell the driver at mod-load time it's IRQ and i/o addr ? > >There is no way. You could use the values from the dummy driver. These >values can be handled using standard methods (config, userconfig, dset). > This method is not good and requires some thought. In the big picture, one of the most useful purposes of modules is the ability to add devices without having to recompile the kernel. If I have to install dummy drivers I've lost my need to use modules. If the sole purpose of modules is to keep the kernel small.....then OK, but its a pretty short-sighted approach. Linux modules are nice because you can send someone who doesn't know how to to build a kernel a complete, complex subsystem and they can just pop it in. It expands the marketability of the module product as well as the O/S, because small, generic kernels can be expanded dynamically without having to know what you're doing. Dennis From owner-freebsd-hackers Sun Sep 24 08:37:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA01845 for hackers-outgoing; Sun, 24 Sep 1995 08:37:21 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA01838 for ; Sun, 24 Sep 1995 08:37:14 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id LAA03545; Sun, 24 Sep 1995 11:25:19 -0400 Date: Sun, 24 Sep 1995 11:25:19 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: multiple mail messages To: Nate Williams cc: Nate Williams , hackers@freebsd.org In-Reply-To: <199509241532.JAA08236@rocky.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Nate Williams wrote: > > > Actually, I *intentionally* leave people on the Cc lists if I think the > > > material is going to be discussed some, since with the bulk_mailer stuff > > > it is difficult to discuss topics with any sort of speed, since it may > > > take a very long time for the person to get the reply via the mailing > > > list. > > > > now, now, nate. with bulk_mailer mail will always reach more > > people faster than without. > > Agreed. But, it still may take 2-4 hours for a reply to reach them > depending on the state of the people in their 'group'. This wasn't > meant to be a criticism of bull_mailer, but a statement of the way ^^^^ sigmund! sigmund! come immediately! i need to you! > things are. yes the 2-4 hour delay is a drag. and hitting multiple lists may get at least one copy there faster. i have plans to segment the lists into the fast hosts and the slow hosts, then user bulk_mailer on each sub_list. no point in punishing all for the circumstances of some list members. peter wemm and i have discussed one method already and i have another brewing in the back of my mind...a very fetid place ;) jmb Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 09:49:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA04827 for hackers-outgoing; Sun, 24 Sep 1995 09:49:10 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id JAA04818 for ; Sun, 24 Sep 1995 09:49:07 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA05984 (5.67a/IDA-1.5 for hackers@freebsd.org); Sun, 24 Sep 1995 11:35:35 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id LAA25673; Sun, 24 Sep 1995 11:25:36 -0500 Date: Sun, 24 Sep 1995 11:25:36 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509241625.LAA25673@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: ports startup scripts Newsgroups: taronga.freebsd.hackers In-Reply-To: References: <199509241434.JAA09429@bonkers.taronga.com> Organization: Taronga Park BBS Sender: owner-hackers@freebsd.org Precedence: bulk In article , Jonathan M. Bresler wrote: > yes. but when i want to understand the startup/shutdown process >running a piece of /etc/daily is...not the obvious step. After you get that warning from /etc/daily and fix the installation problem you'll understand the process. If you use a script you'll never know if there's an installation problem until you find yourself rebuilding the script from your memory after the system doesn't come up one day. > if you are using a non-offical port, you are NOT a newbie. Say *what*? > that both use a master file. one exists as a file, the other >exists as an artifact of ascii sort order (not obvious to our poor >newbie, especially when we have to explain that 10 comes before 2). 02 comes before 10 > one directory for all start and stop scripts Not ideal, but acceptable. > explicit invocation order, a list Then why bother having a directory at all? You might as well just keep on editing /etc/rc.local... > dont have to flip directories to see how level 0 differs from >level 1--just check the list ls /etc/rc*.d is a list. > no ascii sort order surprises ( 0 1 2 243 43) I've been using the System V scheme for ten years and I've never seen a single "ascii sort order" surprise, even from Oracle (and they're *really* sloppy about this stuff, or used to be). > no having to chase links No having to chase links. > increased clarity (i hope) I find a script less clear than a directory listing. I've done it both ways. This one really does work better... well enough to have replaced /etc/rc on Xenix and s:user-startup on my Amiga. From owner-freebsd-hackers Sun Sep 24 10:00:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA05367 for hackers-outgoing; Sun, 24 Sep 1995 10:00:21 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA05360 for ; Sun, 24 Sep 1995 10:00:18 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id MAA05527; Sun, 24 Sep 1995 12:48:17 -0400 Date: Sun, 24 Sep 1995 12:48:16 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: ports startup scripts To: Peter da Silva cc: hackers@freebsd.org In-Reply-To: <199509241625.LAA25673@bonkers.taronga.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Peter da Silva wrote: > > After you get that warning from /etc/daily and fix the installation problem > you'll understand the process. > > If you use a script you'll never know if there's an installation problem until > you find yourself rebuilding the script from your memory after the system > doesn't come up one day. no backups ;( > > if you are using a non-offical port, you are NOT a newbie. > > Say *what*? > > > that both use a master file. one exists as a file, the other > >exists as an artifact of ascii sort order (not obvious to our poor > >newbie, especially when we have to explain that 10 comes before 2). > > 02 comes before 10 as does 002. still not obvious to a newbie > > one directory for all start and stop scripts > > Not ideal, but acceptable. > > > explicit invocation order, a list > > Then why bother having a directory at all? You might as well just keep on > editing /etc/rc.local... > > > dont have to flip directories to see how level 0 differs from > >level 1--just check the list > > ls /etc/rc*.d is a list. > > > no ascii sort order surprises ( 0 1 2 243 43) > > I've been using the System V scheme for ten years and I've never seen a > single "ascii sort order" surprise, even from Oracle (and they're *really* > sloppy about this stuff, or used to be). standard newbie stuff. create 1, 2, 3, 4 ... 10 hey why did 10 run before 2. now i KNOW that 2 < 10. 2 ran before 3, so i am right. better file a bug report. > > no having to chase links > > No having to chase links. > > > increased clarity (i hope) > > I find a script less clear than a directory listing. > > I've done it both ways. This one really does work better... well enough to > have replaced /etc/rc on Xenix and s:user-startup on my Amiga. Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Sun Sep 24 10:18:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA05952 for hackers-outgoing; Sun, 24 Sep 1995 10:18:58 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA05945 for ; Sun, 24 Sep 1995 10:18:55 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id KAA13720; Sun, 24 Sep 1995 10:17:53 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA27690; Sun, 24 Sep 1995 10:23:29 -0700 Date: Sun, 24 Sep 1995 10:23:29 -0700 Message-Id: <9509241723.AA27690@asimov.volant.org> To: peter@taronga.com, jmb@kryten.atinc.com Subject: Re: ports startup scripts Cc: hackers@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> > > if you are using a non-offical port, you are NOT a newbie. |> > |> > Say *what*? |> > |> > > that both use a master file. one exists as a file, the other |> > >exists as an artifact of ascii sort order (not obvious to our poor |> > >newbie, especially when we have to explain that 10 comes before 2). |> > |> > 02 comes before 10 |> |> as does 002. still not obvious to a newbie Even the rawest newbie should have no trouble noticing that all of the scripts have EXACTLY TWO DIGITS after the initial 'S' or 'K'. |> ... |> |> standard newbie stuff. create 1, 2, 3, 4 ... 10 |> |> hey why did 10 run before 2. now i KNOW that 2 < 10. 2 ran |> before 3, so i am right. better file a bug report. Even newbies don't usually create everything from scratch - they copy existing stuff and make the necessary mods. Why would they create 'S2mumble' when the existing examples are 'S01foo', 'S04bar', etc. ? If you are really worried about this, insist on explicit documentation of the expected number of digits, in both the man pages and the per-state README files. |> > > no having to chase links |> > |> > No having to chase links. |> > |> > > increased clarity (i hope) |> > |> > I find a script less clear than a directory listing. |> > |> > I've done it both ways. This one really does work better... well enough to |> > have replaced /etc/rc on Xenix and s:user-startup on my Amiga. If you are seriously worried about link chasing, a simple perl script added to the daily run can ensure that every [SK]* file in a rc?.d directory has at least two links. For the truely anal, it can ensure that every file with the same suffix (after the first three chars) in any of the rc?.d dirs are linked together (by checking inode numbers), and even that each [SK]##mumble is linked to init.d/mumble. -Pat From owner-freebsd-hackers Sun Sep 24 12:19:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10384 for hackers-outgoing; Sun, 24 Sep 1995 12:19:15 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA10379 for ; Sun, 24 Sep 1995 12:19:11 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA06830 (5.67a/IDA-1.5 for hackers@freebsd.org); Sun, 24 Sep 1995 14:04:40 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id NAA29787; Sun, 24 Sep 1995 13:50:55 -0500 Date: Sun, 24 Sep 1995 13:50:55 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509241850.NAA29787@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: ports startup scripts Newsgroups: taronga.freebsd.hackers In-Reply-To: References: <199509241625.LAA25673@bonkers.taronga.com> Organization: Taronga Park BBS Sender: owner-hackers@freebsd.org Precedence: bulk In article , Jonathan M. Bresler wrote: >> 02 comes before 10 > as does 002. still not obvious to a newbie As I said, I've been using this for ten years without this problem coming up once, and some of our techs haven't been the brightest. It's a lot easier than remembering to make backups (or even remembering to tell me that there's a new system to add to the backup list). From owner-freebsd-hackers Sun Sep 24 12:44:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10903 for hackers-outgoing; Sun, 24 Sep 1995 12:44:53 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10897 for hackers; Sun, 24 Sep 1995 12:44:52 -0700 Date: Sun, 24 Sep 1995 12:44:52 -0700 From: Jeffrey Hsu Message-Id: <199509241944.MAA10897@freefall.freebsd.org> To: hackers Subject: disk going bad? Sender: owner-hackers@FreeBSD.org Precedence: bulk I'm having incredibly bad luck w/ hard drives. One of my drives just exhibited the following errors. Fsck also fails on these medium errors. Does this mean my drive is going bad and I should replace it (still under warranty) or will a simple reformat take care of the problem? It's a scsi drive, which I thought took care of bad sector automatically, but I guess not. Note, I get a lot of these medium errors from running fsck and that just last night, everything was fine. Sep 24 12:27:41 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 Unrecovered read error Sep 24 12:27:46 armour /kernel: , retries:4 Sep 24 12:27:46 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 Unrecovered read error Sep 24 12:27:54 armour /kernel: , retries:3 Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 Unrecovered read error Sep 24 12:27:54 armour /kernel: , retries:2 Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 Unrecovered read error Sep 24 12:27:54 armour /kernel: , retries:1 Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1411 asc:11,0 Unrecovered read error Sep 24 12:27:54 armour /kernel: , FAILURE From owner-freebsd-hackers Sun Sep 24 12:50:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA11218 for hackers-outgoing; Sun, 24 Sep 1995 12:50:55 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA11213 for ; Sun, 24 Sep 1995 12:50:51 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id UAA06285; Sun, 24 Sep 1995 20:50:20 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509241950.UAA06285@gvr.win.tue.nl> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: taob@io.org (Brian Tao) Date: Sun, 24 Sep 1995 20:50:19 +0100 (MET) Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: from "Brian Tao" at Sep 23, 95 05:24:05 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 859 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Brian Tao wrote: > > On Fri, 22 Sep 1995, Mark Hittinger wrote: > > > > 12,870 lines in /etc/passwd today. > > Sorry, I'm just getting back up to speed again with my new job in > Toronto... what are these improvements to pwd_mkdb? A simple observation: most master.passwd updates are done because only one line needs to be updated. So I added an option to pwd_mkdb that only touches a specific record. Before commiting any of these, some discussions willbe necessary as I'd like a complete solution. That means that there is support to delete an entry and, when it's up to me, there willbe some replacement for vipw. Vipw is bad in that you can't tell which records were changed. Vipw can still be used, but only with care as *large* rebuild times are to be expected. I'll post my patches later tonight and I'd like other to comment on them. -Guido From owner-freebsd-hackers Sun Sep 24 13:23:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA12248 for hackers-outgoing; Sun, 24 Sep 1995 13:23:43 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA12227 for ; Sun, 24 Sep 1995 13:23:29 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id VAA06416; Sun, 24 Sep 1995 21:23:25 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509242023.VAA06416@gvr.win.tue.nl> Subject: pwd_mkdb speed up patches: please review and comment To: hackers@freebsd.org Date: Sun, 24 Sep 1995 21:23:24 +0100 (MET) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 14384 Sender: owner-hackers@freebsd.org Precedence: bulk Underneath are patches that try to touch all passwd related utils as little as possible while speeding up regular password updates dramatically. I'd like you all to look at them and give comments. What it does not solve is speeding up vipw. Chpass, chsh, chfn, passwd, yppasswd will be quicker: on a 486, 66MHz, a 10.000 line password file update will be limited by the disk transfer time. In my case it took 1.5 minute. Now it is 15 seconds. This isn't a real solution for the basic problem. But it makes the current problems with large password files a bit less painfull. What I did not do (yet) is change adduser. -Guido --- ./usr.bin/passwd/local_passwd.c.orig Sun Nov 6 22:08:19 1994 +++ ./usr.bin/passwd/local_passwd.c Sun Sep 10 20:03:48 1995 @@ -154,7 +154,7 @@ pw->pw_change = 0; pw_copy(pfd, tfd, pw); - if (!pw_mkdb()) + if (!pw_mkdb(uname)) pw_error((char *)NULL, 0, 1); return (0); } --- ./usr.bin/chpass/chpass.c.orig Tue May 30 08:29:36 1995 +++ ./usr.bin/chpass/chpass.c Fri Sep 22 19:42:57 1995 @@ -187,7 +187,7 @@ pw_copy(pfd, tfd, pw); - if (!pw_mkdb()) + if (!pw_mkdb(pw->pw_name)) pw_error((char *)NULL, 0, 1); exit(0); } --- ./usr.sbin/vipw/vipw.c.orig Tue May 30 05:52:55 1995 +++ ./usr.sbin/vipw/vipw.c Sun Sep 10 20:17:53 1995 @@ -96,7 +96,7 @@ warnx("no changes made"); pw_error((char *)NULL, 0, 0); } - if (pw_mkdb()) + if (pw_mkdb((char *)NULL)) break; pw_prompt(); } --- ./usr.sbin/vipw/pw_util.c.orig Tue May 30 05:52:54 1995 +++ ./usr.sbin/vipw/pw_util.c Fri Sep 22 19:39:07 1995 @@ -138,7 +138,8 @@ } int -pw_mkdb() +pw_mkdb(username) +char *username; { int pstat; pid_t pid; @@ -146,7 +147,12 @@ warnx("rebuilding the database..."); (void)fflush(stderr); if (!(pid = vfork())) { - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + if(!username) { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + } else { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, + "-u", username, NULL); + } pw_error(_PATH_PWD_MKDB, 1, 1); } pid = waitpid(pid, &pstat, 0); --- ./usr.sbin/vipw/pw_util.h.orig Thu May 26 07:23:31 1994 +++ ./usr.sbin/vipw/pw_util.h Sun Sep 10 20:04:57 1995 @@ -37,6 +37,6 @@ void pw_error __P((char *, int, int)); void pw_init __P((void)); int pw_lock __P((void)); -int pw_mkdb __P((void)); +int pw_mkdb __P((char *)); void pw_prompt __P((void)); int pw_tmp __P((void)); --- ./usr.sbin/pwd_mkdb/pwd_mkdb.c.orig Tue May 30 05:51:22 1995 +++ ./usr.sbin/pwd_mkdb/pwd_mkdb.c Sun Sep 10 20:14:32 1995 @@ -79,6 +79,7 @@ void cleanup __P((void)); void error __P((char *)); +void cp __P((char *, char *, mode_t mode)); void mv __P((char *, char *)); int scan __P((FILE *, struct passwd *)); void usage __P((void)); @@ -96,10 +97,12 @@ char *p, *t; char buf[MAX(MAXPATHLEN, LINE_MAX * 2)], tbuf[1024]; char buf2[MAXPATHLEN]; + char *username; + u_int method; strcpy(prefix, _PATH_PWD); makeold = 0; - while ((ch = getopt(argc, argv, "d:pv")) != EOF) + while ((ch = getopt(argc, argv, "d:pu:v")) != EOF) switch(ch) { case 'd': strcpy(prefix, optarg); @@ -107,6 +110,9 @@ case 'p': /* create V7 "file.orig" */ makeold = 1; break; + case 'u': /* only update this record */ + username = optarg; + break; case 'v': /* backward compatible */ break; case '?': @@ -141,8 +147,17 @@ /* Open the temporary insecure password database. */ (void)snprintf(buf, sizeof(buf), "%s/%s.tmp", prefix, _MP_DB); - dp = dbopen(buf, - O_RDWR|O_CREAT|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + if(username) { + (void)snprintf(buf2, sizeof(buf2), "%s/%s", prefix, _MP_DB); + cp(buf2, buf, PERM_INSECURE); + dp = dbopen(buf, + O_RDWR|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + method = 0; + } else { + dp = dbopen(buf, + O_RDWR|O_CREAT|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + method = R_NOOVERWRITE; + } if (dp == NULL) error(buf); clean = FILE_INSECURE; @@ -182,47 +197,49 @@ if(pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') yp_enabled = 1; #define COMPACT(e) t = e; while (*p++ = *t++); - /* Create insecure data. */ - p = buf; - COMPACT(pwd.pw_name); - COMPACT("*"); - memmove(p, &pwd.pw_uid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_gid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_change, sizeof(time_t)); - p += sizeof(time_t); - COMPACT(pwd.pw_class); - COMPACT(pwd.pw_gecos); - COMPACT(pwd.pw_dir); - COMPACT(pwd.pw_shell); - memmove(p, &pwd.pw_expire, sizeof(time_t)); - p += sizeof(time_t); - memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); - p += sizeof pwd.pw_fields; - data.size = p - buf; - - /* Store insecure by name. */ - tbuf[0] = _PW_KEYBYNAME; - len = strlen(pwd.pw_name); - memmove(tbuf + 1, pwd.pw_name, len); - key.size = len + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + if(!username || (strcmp(username, pwd.pw_name) == 0)) { + /* Create insecure data. */ + p = buf; + COMPACT(pwd.pw_name); + COMPACT("*"); + memmove(p, &pwd.pw_uid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_gid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_change, sizeof(time_t)); + p += sizeof(time_t); + COMPACT(pwd.pw_class); + COMPACT(pwd.pw_gecos); + COMPACT(pwd.pw_dir); + COMPACT(pwd.pw_shell); + memmove(p, &pwd.pw_expire, sizeof(time_t)); + p += sizeof(time_t); + memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); + p += sizeof pwd.pw_fields; + data.size = p - buf; + + /* Store insecure by name. */ + tbuf[0] = _PW_KEYBYNAME; + len = strlen(pwd.pw_name); + memmove(tbuf + 1, pwd.pw_name, len); + key.size = len + 1; + if ((dp->put)(dp, &key, &data, method) == -1) + error("put"); - /* Store insecure by number. */ - tbuf[0] = _PW_KEYBYNUM; - memmove(tbuf + 1, &cnt, sizeof(cnt)); - key.size = sizeof(cnt) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + /* Store insecure by number. */ + tbuf[0] = _PW_KEYBYNUM; + memmove(tbuf + 1, &cnt, sizeof(cnt)); + key.size = sizeof(cnt) + 1; + if ((dp->put)(dp, &key, &data, method) == -1) + error("put"); - /* Store insecure by uid. */ - tbuf[0] = _PW_KEYBYUID; - memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); - key.size = sizeof(pwd.pw_uid) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + /* Store insecure by uid. */ + tbuf[0] = _PW_KEYBYUID; + memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); + key.size = sizeof(pwd.pw_uid) + 1; + if ((dp->put)(dp, &key, &data, method) == -1) + error("put"); + } /* Store insecure special plus and special minus */ if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { @@ -235,7 +252,7 @@ else minuscnt++; key.size = sizeof(cnt) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } @@ -251,7 +268,7 @@ data.size = 1; tbuf[0] = _PW_KEYYPENABLED; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } /* If we have +@netgroup entries, store the plus counter */ @@ -260,7 +277,7 @@ data.size = sizeof(pluscnt); tbuf[0] = _PW_KEYPLUSCNT; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } /* If we have -@netgroup entries, store the minus counter */ @@ -269,7 +286,7 @@ data.size = sizeof(minuscnt); tbuf[0] = _PW_KEYMINUSCNT; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } @@ -281,8 +298,15 @@ /* Open the temporary encrypted password database. */ (void)snprintf(buf, sizeof(buf), "%s/%s.tmp", prefix, _SMP_DB); - edp = dbopen(buf, - O_RDWR|O_CREAT|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + if(username) { + (void)snprintf(buf2, sizeof(buf2), "%s/%s", prefix, _SMP_DB); + cp(buf2, buf, PERM_SECURE); + edp = dbopen(buf, + O_RDWR|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + } else { + edp = dbopen(buf, + O_RDWR|O_CREAT|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + } if (!edp) error(buf); clean = FILE_SECURE; @@ -291,61 +315,63 @@ minuscnt = pluscnt = 0; for (cnt = 1; scan(fp, &pwd); ++cnt) { - /* Create secure data. */ - p = buf; - COMPACT(pwd.pw_name); - COMPACT(pwd.pw_passwd); - memmove(p, &pwd.pw_uid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_gid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_change, sizeof(time_t)); - p += sizeof(time_t); - COMPACT(pwd.pw_class); - COMPACT(pwd.pw_gecos); - COMPACT(pwd.pw_dir); - COMPACT(pwd.pw_shell); - memmove(p, &pwd.pw_expire, sizeof(time_t)); - p += sizeof(time_t); - memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); - p += sizeof pwd.pw_fields; - data.size = p - buf; - - /* Store secure by name. */ - tbuf[0] = _PW_KEYBYNAME; - len = strlen(pwd.pw_name); - memmove(tbuf + 1, pwd.pw_name, len); - key.size = len + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); - - /* Store secure by number. */ - tbuf[0] = _PW_KEYBYNUM; - memmove(tbuf + 1, &cnt, sizeof(cnt)); - key.size = sizeof(cnt) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); - - /* Store secure by uid. */ - tbuf[0] = _PW_KEYBYUID; - memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); - key.size = sizeof(pwd.pw_uid) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + if(!username || (strcmp(username, pwd.pw_name) == 0)) { + /* Create secure data. */ + p = buf; + COMPACT(pwd.pw_name); + COMPACT(pwd.pw_passwd); + memmove(p, &pwd.pw_uid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_gid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_change, sizeof(time_t)); + p += sizeof(time_t); + COMPACT(pwd.pw_class); + COMPACT(pwd.pw_gecos); + COMPACT(pwd.pw_dir); + COMPACT(pwd.pw_shell); + memmove(p, &pwd.pw_expire, sizeof(time_t)); + p += sizeof(time_t); + memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); + p += sizeof pwd.pw_fields; + data.size = p - buf; + + /* Store secure by name. */ + tbuf[0] = _PW_KEYBYNAME; + len = strlen(pwd.pw_name); + memmove(tbuf + 1, pwd.pw_name, len); + key.size = len + 1; + if ((dp->put)(edp, &key, &data, method) == -1) + error("put"); - /* Store secure special plus and special minus */ - if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { - tbuf[0] = (pwd.pw_name[0] == '+') ? - _PW_KEYPLUSBYNUM : _PW_KEYMINUSBYNUM; - memmove(tbuf + 1, (pwd.pw_name[0] == '+') ? - &pluscnt : &minuscnt, sizeof(cnt)); - if (pwd.pw_name[0] == '+') - pluscnt++; - else - minuscnt++; + /* Store secure by number. */ + tbuf[0] = _PW_KEYBYNUM; + memmove(tbuf + 1, &cnt, sizeof(cnt)); key.size = sizeof(cnt) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(edp, &key, &data, method) == -1) error("put"); + + /* Store secure by uid. */ + tbuf[0] = _PW_KEYBYUID; + memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); + key.size = sizeof(pwd.pw_uid) + 1; + if ((dp->put)(edp, &key, &data, method) == -1) + error("put"); + + /* Store secure special plus and special minus */ + if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { + tbuf[0] = (pwd.pw_name[0] == '+') ? + _PW_KEYPLUSBYNUM : _PW_KEYMINUSBYNUM; + memmove(tbuf + 1, (pwd.pw_name[0] == '+') ? + &pluscnt : &minuscnt, sizeof(cnt)); + if (pwd.pw_name[0] == '+') + pluscnt++; + else + minuscnt++; + key.size = sizeof(cnt) + 1; + if ((dp->put)(edp, &key, &data, method) == -1) + error("put"); + } } } /* If YP enabled, set flag. */ @@ -354,7 +380,7 @@ data.size = 1; tbuf[0] = _PW_KEYYPENABLED; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } /* If we have +@netgroup entries, store the plus counter */ @@ -363,7 +389,7 @@ data.size = sizeof(pluscnt); tbuf[0] = _PW_KEYPLUSCNT; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } /* If we have -@netgroup entries, store the minus counter */ @@ -372,7 +398,7 @@ data.size = sizeof(minuscnt); tbuf[0] = _PW_KEYMINUSCNT; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } (void)(edp->close)(edp); @@ -437,6 +463,37 @@ } void +cp(from, to, mode) + char *from, *to; + mode_t mode; +{ + static char buf[MAXBSIZE]; + int from_fd, rcount, to_fd, wcount; + + if ((from_fd = open(from, O_RDONLY, 0)) < 0) + error(from); + if ((to_fd = open(to, O_WRONLY|O_CREAT|O_EXCL, mode)) < 0) + error(to); + while ((rcount = read(from_fd, buf, MAXBSIZE)) > 0) { + wcount = write(to_fd, buf, rcount); + if (rcount != wcount || wcount == -1) { + int sverrno = errno; + + (void)snprintf(buf, sizeof(buf), "%s to %s", from, to); + errno = sverrno; + error(buf); + } + } + if (rcount < 0) { + int sverrno = errno; + + (void)snprintf(buf, sizeof(buf), "%s to %s", from, to); + errno = sverrno; + error(buf); + } +} + +void mv(from, to) char *from, *to; { @@ -484,6 +541,6 @@ usage() { - (void)fprintf(stderr, "usage: pwd_mkdb [-p] [-d ] file\n"); + (void)fprintf(stderr, "usage: pwd_mkdb [-p] [-d ] [-u username] file\n"); exit(1); } --- ./gnu/usr.sbin/yppasswdd/pw_util.c.orig Tue May 30 07:05:28 1995 +++ ./gnu/usr.sbin/yppasswdd/pw_util.c Sun Sep 10 21:06:06 1995 @@ -132,7 +132,8 @@ } int -pw_mkdb() +pw_mkdb(username) +char *username; { int pstat; pid_t pid; @@ -140,7 +141,12 @@ warnx("rebuilding the database..."); (void)fflush(stderr); if (!(pid = vfork())) { - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + if(!username) { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + } else { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, + "-u", username, NULL); + } pw_error(_PATH_PWD_MKDB, 1, 1); } pid = waitpid(pid, &pstat, 0); From owner-freebsd-hackers Sun Sep 24 13:37:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA12888 for hackers-outgoing; Sun, 24 Sep 1995 13:37:48 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA12882 for ; Sun, 24 Sep 1995 13:37:43 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id NAA01842; Sun, 24 Sep 1995 13:37:21 -0700 To: Olof Johansson cc: "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Sat, 23 Sep 1995 00:13:10 +0200." Date: Sun, 24 Sep 1995 13:37:21 -0700 Message-ID: <1839.811975041@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > On Fri, 22 Sep 1995, Kaleb S. KEITHLEY wrote: > > > > Don't know if any of you have seen the news about Netscape apparently > > dropping Linux from its supported platforms for its 2.0 version. Without > > a compatible platform (I guess SCO iBCS doesn't cut it?) Linux users won't > > have Netscape 2.x to cruise the iway with. So far Netscape hasn't dropped > > BSD/OS as a supported platform though and it seems to me that FreeBSD > > leverage this to win a convert or three. > > Let's just hope the support is for the 1.x BSD/OS, and not 2.0. I'm currently talking with them (Netscape) about this very subject. Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 and this is not provided in BSDI 1.1, so there's a problem. I'm now busily trying to talk them into doing both BSDI 2.0 and FreeBSD 2.x native ports.. :-) Jordan From owner-freebsd-hackers Sun Sep 24 13:42:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13038 for hackers-outgoing; Sun, 24 Sep 1995 13:42:20 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA13028 for ; Sun, 24 Sep 1995 13:42:16 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03797; Sun, 24 Sep 1995 13:39:10 -0700 From: Terry Lambert Message-Id: <199509242039.NAA03797@phaeton.artisoft.com> Subject: Re: ports startup scripts To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Date: Sun, 24 Sep 1995 13:39:10 -0700 (MST) Cc: peter@taronga.com, hackers@FreeBSD.ORG In-Reply-To: from "Jonathan M. Bresler" at Sep 23, 95 08:57:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2102 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > with the K* and S* files in different directories, one for each > run level, ascertaining the differences is needlessly harder. > > consider instead a file that lists which scripts to run for each > 'run level or the term of the day we are using' and the order of > execution. now if both level A and level B need script Sfoo, there is > only one Sfoo. no symlinks required. no hard links required. it is > immediately obvious what is differnct and what is the same among the run > levels. > > same name == same script == same actions. > > no grep'ping. no diff'ing. no uncertainty. Uncertainty on package install/deinstall. Consider: A package which requires a daemon to be run needs to add a startup and a shutdown script to the list of scripts to be executed. It may also need to add a cron job to rotate the damons logs. A single file containing this information requires additional locking, etc. to make it work properly (consider: one package being installed in one xterm and another being installed in another). The point of using seperate files is that the directory entry/deletion mechanism is arbitrated automatically, in the kernel, without the use of user level locks. A seperate file does not require a grep/sed of the single monolithic data file to add/delete. Ordering guarantees within a single run level/state are hard to provide with the single monolithic file model. Finally, what if I don't want to delete the package, I just want to disable it? How to I prevent the package daemon's and cron jobs from running without losing the information needed to reeenable them later without needing to fully reinstall them? Typically, I'd put the "cron" jobs as at commands in the startup script, though this begs the question of providing configurability under administrative control (for instance, what if I want to specify a higher or lower frequency of log rotation?). Cron actually faces the same issues as init. 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 Sep 24 13:44:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13297 for hackers-outgoing; Sun, 24 Sep 1995 13:44:04 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA13290 for ; Sun, 24 Sep 1995 13:44:01 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id NAA01909; Sun, 24 Sep 1995 13:43:15 -0700 To: Coranth Gryphon cc: archie@tribe.com, freebsd-hackers@freebsd.org Subject: Re: /usr/src/Makefile targets In-reply-to: Your message of "Fri, 22 Sep 1995 15:39:57 EDT." <199509221939.PAA04298@healer.com> Date: Sun, 24 Sep 1995 13:43:14 -0700 Message-ID: <1907.811975394@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > What I'd like to do is to develop an "in-house" customized FreeBSD I recommend anyone truly interested in customizable setups to jump on-board with me now in the new "setup" effort. Things have been slow there the last week due to other committments and a USENIX conference in the middle, but I expect the fur to be flying there again next week. Jordan From owner-freebsd-hackers Sun Sep 24 14:00:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA13861 for hackers-outgoing; Sun, 24 Sep 1995 14:00:22 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA13852 for ; Sun, 24 Sep 1995 14:00:16 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id VAA00770; Sun, 24 Sep 1995 21:59:47 +0100 Date: Sun, 24 Sep 1995 21:59:46 +0100 (MET) From: Olof Johansson To: "Jordan K. Hubbard" cc: "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <1839.811975041@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > I'm currently talking with them (Netscape) about this very subject. > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > and this is not provided in BSDI 1.1, so there's a problem. > > I'm now busily trying to talk them into doing both BSDI 2.0 and > FreeBSD 2.x native ports.. :-) Ahem, didn't they say they wouldn't support 'free' OS:es, and that's why Linux wasn't on the list? I wouldn't mind if you talked them into doing a FreeBSD port though. :-) -Olof From owner-freebsd-hackers Sun Sep 24 14:09:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14274 for hackers-outgoing; Sun, 24 Sep 1995 14:09:33 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14265 for ; Sun, 24 Sep 1995 14:09:31 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id OAA06989; Sun, 24 Sep 1995 14:09:04 -0700 Message-Id: <199509242109.OAA06989@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Olof Johansson cc: "Jordan K. Hubbard" , "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Sun, 24 Sep 1995 21:59:46 BST." Date: Sun, 24 Sep 1995 14:09:04 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org Precedence: bulk >On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > >> I'm currently talking with them (Netscape) about this very subject. >> Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 >> and this is not provided in BSDI 1.1, so there's a problem. >> >> I'm now busily trying to talk them into doing both BSDI 2.0 and >> FreeBSD 2.x native ports.. :-) > >Ahem, didn't they say they wouldn't support 'free' OS:es, and that's why >Linux wasn't on the list? I wouldn't mind if you talked them into doing a >FreeBSD port though. :-) > > > -Olof What about BSDI 2.0 binary compatibility? Anyone working on this? Jordan, you have a BSDI 2.0 box around don't you? -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sun Sep 24 14:10:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14351 for hackers-outgoing; Sun, 24 Sep 1995 14:10:29 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14327 for ; Sun, 24 Sep 1995 14:10:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03837; Sun, 24 Sep 1995 14:06:50 -0700 From: Terry Lambert Message-Id: <199509242106.OAA03837@phaeton.artisoft.com> Subject: Re: multiple mail messages To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 24 Sep 1995 14:06:50 -0700 (MST) Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.ORG In-Reply-To: <199509240747.IAA29850@uriah.heep.sax.de> from "J Wunsch" at Sep 24, 95 08:47:56 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3298 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Actually, I *intentionally* leave people on the Cc lists if I think the > > material is going to be discussed some, since with the bulk_mailer stuff > > it is difficult to discuss topics with any sort of speed, since it may > > take a very long time for the person to get the reply via the mailing > > list. > > Do you remind that many people are not within a "can get'em within 10 > minutes" US Internet anyway? :-) > > For me with my polled UUCP link for example, i'm typically getting 50 > ... 100 messages in a single batch... No speedup by duplicates. :) I've sometimes wondered if it's worthwhile to hack the mail tools for a message id field to be respected by majorodomo when handling mail from someone on the basis of crossposts. I've also wondered about changing the header rewrite to be more elm friendly. The elm program has "r(eply)" and "g(roup reply", and the way the headers come in from the mailing lists means you can "r" to the original sender or "g" to the mailing lists. For questions, I pick "g" so the answers go into the archives and I don't have to answer the same thing over and over again (as much, anyway). If I don't take the time to edit the "To" line post-facto after this, then there's a duplicate message to the questioner. In the case of the questions list, this is generally not a problem, since the questioner may not be a member of the list, and this is the only way to guarantee that the answer both goes to the list archive (and any other people who had the same question and *are* on the list) and the original questioner. For discussion lists, like hackers and current, etc., this works to a disadvantage, since a thread will typically grow duplicates with each responder in the thread body. On the other hand, these lists *also* do not enforce list membership, and so there is no way to ensure the original sender gets the reply other than doing group replies. One soloution would be to have majordomo delete duplicate targets from the to line. That is, if it goes to multiple lists, then send it once to the recipients that are on multiple lists. This would require a n:m map of actual recipient lists and an i:j map to lists based on a message id field. It's questionable whether this is realistic, given the processing requirements. inbound: hackers hackers-list hackers+questions-list current+hackers-list current+hackers+questions-list current current-list current+questions-list current+hackers-list current+hackers+questions-list ... outbound: hackers+questions-list bob@foo.fee fred@xxx.yyy current+hackers-list tom@zzz.zzz barb@qqq.qqq current+hackers_questions-list mark@fff.org ... Finally, this would once again break elm, since duplicate message would be distributed to a single list by list order of the recipient, and the use of the elm "filter" program would not guarantee proper list ordering. For instance, a crosspost to current/questions/hackers that "belonged" on questions would go to hackers only for the hackers+questions-list members, current for the current+hackers+questions-list and the current+questions-list and the current-list members, etc. 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 Sep 24 14:18:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14923 for hackers-outgoing; Sun, 24 Sep 1995 14:18:52 -0700 Received: from virgo.ai.net (root@virgo.ai.net [198.69.44.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14906 for ; Sun, 24 Sep 1995 14:18:37 -0700 Received: from aries.ai.net (aries.ai.net [198.69.44.1]) by virgo.ai.net (8.6.11/8.6.12) with ESMTP id RAA04001; Sun, 24 Sep 1995 17:17:35 -0400 Received: (from nc@localhost) by aries.ai.net (8.6.11/8.6.12) id RAA04402; Sun, 24 Sep 1995 17:17:30 -0400 Date: Sun, 24 Sep 1995 17:17:30 -0400 (EDT) From: Network Coordinator To: "Jordan K. Hubbard" cc: Olof Johansson , "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <1839.811975041@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk > I'm currently talking with them (Netscape) about this very subject. > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > and this is not provided in BSDI 1.1, so there's a problem. > > I'm now busily trying to talk them into doing both BSDI 2.0 and > FreeBSD 2.x native ports.. :-) If they don't add FreeBSD 2.x native support, how hard would it be too add dlopen()/dlsym() support for BSDI 2.0 binaries? I am not a programmer, so please excuse the ignorance. Collette From owner-freebsd-hackers Sun Sep 24 14:32:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15215 for hackers-outgoing; Sun, 24 Sep 1995 14:32:14 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15210 ; Sun, 24 Sep 1995 14:32:11 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id OAA06139; Sun, 24 Sep 1995 14:32:06 -0700 From: Julian Elischer Message-Id: <199509242132.OAA06139@ref.tfs.com> Subject: Re: disk going bad? To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Sun, 24 Sep 1995 14:32:06 -0700 (PDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509241944.MAA10897@freefall.freebsd.org> from "Jeffrey Hsu" at Sep 24, 95 12:44:52 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1377 Sender: owner-hackers@FreeBSD.org Precedence: bulk Under 2.0.5, run the sample script in the scsi(8 or 1) man page to turn on bad-block remapping julian > > I'm having incredibly bad luck w/ hard drives. One of my drives just > exhibited the following errors. Fsck also fails on these medium errors. > Does this mean my drive is going bad and I should replace it (still > under warranty) or will a simple reformat take care of the problem? > It's a scsi drive, which I thought took care of bad sector automatically, > but I guess not. Note, I get a lot of these medium errors from running > fsck and that just last night, everything was fine. > > Sep 24 12:27:41 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 > Unrecovered read error > Sep 24 12:27:46 armour /kernel: , retries:4 > Sep 24 12:27:46 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 > Unrecovered read error > Sep 24 12:27:54 armour /kernel: , retries:3 > Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 > Unrecovered read error > Sep 24 12:27:54 armour /kernel: , retries:2 > Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1412 asc:11,0 > Unrecovered read error > Sep 24 12:27:54 armour /kernel: , retries:1 > Sep 24 12:27:54 armour /kernel: sd2(uha0:6:0): MEDIUM ERROR info:2f1411 asc:11,0 > Unrecovered read error > Sep 24 12:27:54 armour /kernel: , FAILURE > From owner-freebsd-hackers Sun Sep 24 14:36:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15491 for hackers-outgoing; Sun, 24 Sep 1995 14:36:02 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15484 for ; Sun, 24 Sep 1995 14:36:00 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id OAA06150; Sun, 24 Sep 1995 14:35:06 -0700 From: Julian Elischer Message-Id: <199509242135.OAA06150@ref.tfs.com> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Sun, 24 Sep 1995 14:35:05 -0700 (PDT) Cc: taob@io.org, bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: <199509241950.UAA06285@gvr.win.tue.nl> from "Guido van Rooij" at Sep 24, 95 08:50:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1112 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk you can sort the passwd on uid and name before editing it, do the same afterwards, get a diff, change those records and then store the version of the passwd file the user saved (user selected order) > > Brian Tao wrote: > > > > On Fri, 22 Sep 1995, Mark Hittinger wrote: > > > > > > 12,870 lines in /etc/passwd today. > > > > Sorry, I'm just getting back up to speed again with my new job in > > Toronto... what are these improvements to pwd_mkdb? > > A simple observation: most master.passwd updates are done because > only one line needs to be updated. So I added an option to > pwd_mkdb that only touches a specific record. > > Before commiting any of these, some discussions willbe necessary as > I'd like a complete solution. That means that there is support to delete > an entry and, when it's up to me, there willbe some replacement for > vipw. Vipw is bad in that you can't tell which records were changed. > Vipw can still be used, but only with care as *large* rebuild times > are to be expected. I'll post my patches later tonight and I'd like other > to comment on them. > > -Guido > From owner-freebsd-hackers Sun Sep 24 14:41:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15857 for hackers-outgoing; Sun, 24 Sep 1995 14:41:54 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15851 for ; Sun, 24 Sep 1995 14:41:47 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id RAA22260; Sun, 24 Sep 1995 17:41:11 -0400 Date: Sun, 24 Sep 1995 17:41:09 -0400 (EDT) From: Brian Tao To: Guido van Rooij cc: hackers@FreeBSD.ORG Subject: Re: Guido's pwd_mkdb improvements (fwd) In-Reply-To: <199509241950.UAA06285@gvr.win.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > A simple observation: most master.passwd updates are done because > only one line needs to be updated. So I added an option to > pwd_mkdb that only touches a specific record. I read something about BSD/OS 2.0 having "incremental passwd database rebuilding"... same thing? > Vipw is bad in that you can't tell which records were changed. Can't you just sort the file (both before and after) and do a diff on the outputs? -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 24 15:07:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA17152 for hackers-outgoing; Sun, 24 Sep 1995 15:07:41 -0700 Received: from casparc.ppp.net (casparc.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA17061 for ; Sun, 24 Sep 1995 15:07:03 -0700 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0swz7a-000I0iC; Sun, 24 Sep 95 23:02 MET Received: by ernie.altona.hamburg.com (Smail3.1.29.1 #3) id m0swyfW-000013C; Sun, 24 Sep 95 22:33 MET Message-Id: From: hm@altona.hamburg.com (Hellmuth Michaelis) Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? To: dennis@etinc.com (dennis) Date: Sun, 24 Sep 1995 22:33:02 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: <199509241538.LAA27363@etinc.com> from "dennis" at Sep 24, 95 11:38:44 am Reply-To: hm@altona.hamburg.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1904 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From the keyboard of dennis: > >>Is there a generic or recommended way or example of installing a device's > >>interrupt routine at mod-loading a device driver LKM time ? > > > >See pcibus.c:pcibus_ihandler_attach/detach. > > > >There are some minor problems with these routines: [...] > >- it isn't possible to give a correect device_id. 0 is for clkintr. > > The device_id is only used for counting interrupts. To fix this > > you would have to expand the string table in vector.s and edit it. It seems to be almost impossible to give it, NR_DEVICES is a constant computed by config, it must be made a variable. > >>What is the way to tell the driver at mod-load time it's IRQ and i/o addr ? > > > >There is no way. There should be a way to make this usable. > This method is not good and requires some thought. In the big picture, one of > the most useful purposes of modules is the ability to add devices without having > to recompile the kernel. If I have to install dummy drivers I've lost my > need to use modules. Right, but someone has to implement it. It seems that some work is necessary on the device driver lkm model to make it fully work: there must be a way to specify a device driver interrupt handler, the hardware interrupt to use and a i/o and memory address (range). For me it looks like certain constants are computed at compile time rather than runtime, and depending on this constants some kernel tables are sized. This has to change, there should be a fixed size table (filled with dummies for nonexistent devices) for all possible interrupts which will be filled with the respective entries by mod-loading a driver. Also, it is unclear what should happen with the probe and attach routines. hellmuth -- Hellmuth Michaelis hm@altona.hamburg.com Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? From owner-freebsd-hackers Sun Sep 24 16:04:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA19192 for hackers-outgoing; Sun, 24 Sep 1995 16:04:03 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA19183 for ; Sun, 24 Sep 1995 16:04:00 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id TAA25386; Sun, 24 Sep 1995 19:03:44 -0400 Date: Sun, 24 Sep 1995 19:03:43 -0400 (EDT) From: Brian Tao To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <1839.811975041@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > > I'm currently talking with them (Netscape) about this very subject. > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > and this is not provided in BSDI 1.1, so there's a problem. I wonder how many BSD/OS 1.1 users are out there, and how much of a stink they would raise if Netscape doesn't support it with the new Navigator. :) Writing code that works both with BSD/OS 2.0 and FreeBSD 2.x should not be terribly difficult, and Netscape can always calls for help from FreeBSD users if they are *that* afraid of the support issue. > I'm now busily trying to talk them into doing both BSDI 2.0 and > FreeBSD 2.x native ports.. :-) Cool beans. :) -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 24 16:21:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA20976 for hackers-outgoing; Sun, 24 Sep 1995 16:21:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA20971 ; Sun, 24 Sep 1995 16:21:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA02560; Sun, 24 Sep 1995 16:21:04 -0700 To: Julian Elischer cc: jkh@freefall.freebsd.org (Jordan K. Hubbard), hackers@freefall.freebsd.org Subject: Re: Whither wait_t? In-reply-to: Your message of "Sat, 23 Sep 1995 22:27:06 PDT." <199509240527.WAA04774@ref.tfs.com> Date: Sun, 24 Sep 1995 16:21:03 -0700 Message-ID: <2557.811984863@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > What's our evil friend POSIX say? > I don't think POSIX has ever heard of wait_t > (BTW what IS it?. it's not in 2.0.5 either..) I think it's an unofficial extension - I *do* remember seeing it somewhere, but now don't have access to my usual array of platforms to check. Maybe AIX? HP/UX? Solaris? I kinda thought it was a nice idea.. The more you can push system returned types away to arm's length, the better! Jordan From owner-freebsd-hackers Sun Sep 24 16:24:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA21157 for hackers-outgoing; Sun, 24 Sep 1995 16:24:55 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA21151 for ; Sun, 24 Sep 1995 16:24:46 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA04102; Sun, 24 Sep 1995 16:21:32 -0700 From: Terry Lambert Message-Id: <199509242321.QAA04102@phaeton.artisoft.com> Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? To: hm@altona.hamburg.com Date: Sun, 24 Sep 1995 16:21:32 -0700 (MST) Cc: dennis@etinc.com, hackers@FreeBSD.ORG In-Reply-To: from "Hellmuth Michaelis" at Sep 24, 95 10:33:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2319 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > It seems that some work is necessary on the device driver lkm model to make > it fully work: there must be a way to specify a device driver interrupt > handler, the hardware interrupt to use and a i/o and memory address (range). > > For me it looks like certain constants are computed at compile time rather > than runtime, and depending on this constants some kernel tables are sized. > This has to change, there should be a fixed size table (filled with dummies > for nonexistent devices) for all possible interrupts which will be filled > with the respective entries by mod-loading a driver. I agree that there should be a fixed size interrupt table. But I think there are ISA/EISA/PCI issues to be worked out for this to happen. As in the previous discussion of PCI with CGD, I think that the idea of seperating the mapping and the bridging will have to be worked out before this is possible. As more and more PCI machines are produced, it's only a matter of time before a "pure PCI" box is built, or a PCI box that uses ISA->PCI bridgning to get it's ISA support. This is a problem that already faces Motorolla PPC Ultra 603/604 and DEC Alpha 21066/21068 machines, which are native PCI and only support ISA through bridging. A table of vector lists for shared interrupts is a move in the right direction on this. > Also, it is unclear what should happen with the probe and attach routines. I think they need to be wrappered so that interrupts on devices on a shared interrupt can be disabled during a probe to avoid false positives. There's still problems with devices that have destructive probes, and the reading of config information given the I/O window (like you can do on WD and NE2000 cards, for instance) needs to be worked over to have a uniform probe/attach/detach interface. The 3COM "Plug-N-Play" features work similarly. Perhaps it's worth a look at the MS "Plug-N-Play" specification from their FTP site? I'm not sure the information in the SDK/DDK packages can be used without violation of licensing. 8-(. Now that MS owns 20% or more of UNIX (I'm not sure exactly how much of SCO they own; it was 20% around 1990), it could get real sticky. 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 Sep 24 16:37:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA21671 for hackers-outgoing; Sun, 24 Sep 1995 16:37:21 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA21664 for ; Sun, 24 Sep 1995 16:37:16 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA02687; Sun, 24 Sep 1995 16:36:58 -0700 To: Olof Johansson cc: "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Sun, 24 Sep 1995 21:59:46 BST." Date: Sun, 24 Sep 1995 16:36:57 -0700 Message-ID: <2685.811985817@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk That hasn't been my impression. They haven't out-and-out said no or indicated that FreeBSD would be out of the running due to being "free." A couple of netscape people came up to me at WC's booth at USENIX and indicated that they ran FreeBSD themselves, so who knows? :-) Jordan > On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > > > I'm currently talking with them (Netscape) about this very subject. > > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > > and this is not provided in BSDI 1.1, so there's a problem. > > > > I'm now busily trying to talk them into doing both BSDI 2.0 and > > FreeBSD 2.x native ports.. :-) > > Ahem, didn't they say they wouldn't support 'free' OS:es, and that's why > Linux wasn't on the list? I wouldn't mind if you talked them into doing a > FreeBSD port though. :-) > > > -Olof From owner-freebsd-hackers Sun Sep 24 16:39:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA21822 for hackers-outgoing; Sun, 24 Sep 1995 16:39:19 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA21815 ; Sun, 24 Sep 1995 16:39:15 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA02698; Sun, 24 Sep 1995 16:39:11 -0700 To: "Justin T. Gibbs" cc: Olof Johansson , "Kaleb S. KEITHLEY" , hackers@freefall.FreeBSD.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Sun, 24 Sep 1995 14:09:04 PDT." <199509242109.OAA06989@aslan.cdrom.com> Date: Sun, 24 Sep 1995 16:39:10 -0700 Message-ID: <2696.811985950@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > What about BSDI 2.0 binary compatibility? Anyone working on this? > Jordan, you have a BSDI 2.0 box around don't you? I do, but it's a cast-iron &*^%$#@!! BSDI apparently changed crt0.o fairly substantially but not the magic number. Now explain to me how we're supposed to tell the difference and be selectively compatible? :-( It's gonna be some fun, and that's not even counting the shared lib compatibility problem now that they've gone shared. Jordan From owner-freebsd-hackers Sun Sep 24 16:44:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA22125 for hackers-outgoing; Sun, 24 Sep 1995 16:44:36 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA22117 for ; Sun, 24 Sep 1995 16:44:33 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA02740; Sun, 24 Sep 1995 16:44:09 -0700 To: Network Coordinator cc: Olof Johansson , "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Sun, 24 Sep 1995 17:17:30 EDT." Date: Sun, 24 Sep 1995 16:44:09 -0700 Message-ID: <2738.811986249@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I'm currently talking with them (Netscape) about this very subject. > > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > > and this is not provided in BSDI 1.1, so there's a problem. > > > > I'm now busily trying to talk them into doing both BSDI 2.0 and > > FreeBSD 2.x native ports.. :-) > > If they don't add FreeBSD 2.x native support, how hard would it be too > add dlopen()/dlsym() support for BSDI 2.0 binaries? I am not a > programmer, so please excuse the ignorance. That's not the issue. The issue is that Netscape 2.0 obviously now needs dl*() functionality (these routines allow a shared executable to dynamically load more shared libs at runtime ala `DLL's) and such is not supported by BSDI 1.1 (and would be almost impossible to add). Since we're only compatible with BSDI 1.1 and not 2.0, we're screwed if they decide to port to 2.0 only. Therein lies our mutual problem. Jordan From owner-freebsd-hackers Sun Sep 24 16:52:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA22606 for hackers-outgoing; Sun, 24 Sep 1995 16:52:15 -0700 Received: from localhost.lightside.com (user44.lightside.com [198.81.209.44]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA22596 for ; Sun, 24 Sep 1995 16:52:11 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id QAA01850; Sun, 24 Sep 1995 16:53:14 -0700 Date: Sun, 24 Sep 1995 16:53:13 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: hackers@FreeBSD.ORG Subject: What about NetBSD binary compat? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk I knew that FreeBSD would run BSDI 1.1 binaries, but why can't it run NetBSD-1.0 binaries? I get the message "Bad magic: ld.so" when I try. Would it be an easy fix to add NetBSD support, or is there some incompatibilities between the shared libraries? P.S. I just received an announcement that NetBSD 1.1 will be released November 17, 1995. This is the first official release in a year, since NetBSD 1.0 last October... And you thought six months in between FreeBSD releases was too long to wait! :-) ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-hackers Sun Sep 24 16:57:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA22941 for hackers-outgoing; Sun, 24 Sep 1995 16:57:00 -0700 Received: from dtihost.datatrek.com (dtihost.datatrek.com [204.31.148.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA22936 for ; Sun, 24 Sep 1995 16:56:57 -0700 Received: from home (gcppp [204.31.148.125]) by dtihost.datatrek.com (8.6.12/8.6.9) with SMTP id QAA18945 for ; Sun, 24 Sep 1995 16:55:18 -0700 X-Mailer: Mi'Mail from IRISoft Works, Evaluation Version 1.11 From: gcrutcher@datatrek.com (Gary Crutcher) Subject: FreeBSD Questions Mime-Version: 1.0 Date: Sun, 24 Sep 1995 17:08:9 Message-Id: <24091995171734970.II18467@datatrek.com> To: hackers@freebsd.org Content-Transfer-Encoding: Quoted-Printable Content-Type: Text/plain; charset=ISO-8859-1 Sender: owner-hackers@freebsd.org Precedence: bulk Hi, I am configuring a commercial Web site using FreeBSD. I have a few questions: 1) How or where do I get a 'restricted' shell program for customers telneting into my site? 2) How do I get my printer to work? I followed all the directions=20 in the man pages, but get a 'device busy' error when I try it: cp somefile /dev/lpt0 and lp somefile does not seem to do anything. My lpd daemon is running. Any suggestions? 3) Is there any way to restrict directory access in the FTP program that came with FreeBSD? If a user ftp's in, I do NOT want them confined= =20 to their login directory. Thanks, Gary ------------------------------------------------------------- Gary Crutcher email: gcrutcher@datatrek.com Mgr. New Technology voice: 619-431-8400 x140 Data Trek, Inc. fax: 619-431-8448 5838 Edison Place URL: www.datatrek.com Carlsbad, California 92008 USA "Serving the library needs of the world." From owner-freebsd-hackers Sun Sep 24 18:35:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA25482 for hackers-outgoing; Sun, 24 Sep 1995 18:35:39 -0700 Received: from virgo.ai.net (root@virgo.ai.net [198.69.44.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA25468 for ; Sun, 24 Sep 1995 18:35:33 -0700 Received: from aries.ai.net (aries.ai.net [198.69.44.1]) by virgo.ai.net (8.6.11/8.6.12) with ESMTP id VAA04176; Sun, 24 Sep 1995 21:35:26 -0400 Received: (from nc@localhost) by aries.ai.net (8.6.11/8.6.12) id VAA07484; Sun, 24 Sep 1995 21:35:22 -0400 Date: Sun, 24 Sep 1995 21:35:22 -0400 (EDT) From: Network Coordinator To: Gary Crutcher cc: hackers@freebsd.org Subject: Re: FreeBSD Questions In-Reply-To: <24091995171734970.II18467@datatrek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk > > 3) Is there any way to restrict directory access in the FTP program > that came with FreeBSD? If a user ftp's in, I do NOT want them confined > to their login directory. 1) Most of these questions should not be hackers. Try questions. 2) Try using wu-ftp. Its available in the ports directory. Its what ftp.cdrom.com and wuarchive.wustl.edu use. -Jerry. From owner-freebsd-hackers Sun Sep 24 21:16:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA00388 for hackers-outgoing; Sun, 24 Sep 1995 21:16:12 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA00382 for ; Sun, 24 Sep 1995 21:16:08 -0700 Received: by sequent.kiae.su id AA02505 (5.65.kiae-2 ); Mon, 25 Sep 1995 08:01:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 25 Sep 95 08:01:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA04958; Mon, 25 Sep 1995 06:59:55 +0300 To: Guido van Rooij , Brian Tao Cc: hackers@FreeBSD.ORG References: In-Reply-To: ; from Brian Tao at Sun, 24 Sep 1995 17:41:09 -0400 (EDT) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 25 Sep 1995 06:59:55 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Guido's pwd_mkdb improvements (fwd) Lines: 17 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 737 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message Brian Tao writes: >> A simple observation: most master.passwd updates are done because >> only one line needs to be updated. So I added an option to >> pwd_mkdb that only touches a specific record. > I read something about BSD/OS 2.0 having "incremental passwd >database rebuilding"... same thing? BSD/OS2 variant fails for users with same uid and different names. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Sep 24 21:16:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA00499 for hackers-outgoing; Sun, 24 Sep 1995 21:16:47 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA00494 for ; Sun, 24 Sep 1995 21:16:44 -0700 Received: by sequent.kiae.su id AA02503 (5.65.kiae-2 ); Mon, 25 Sep 1995 08:01:56 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 25 Sep 95 08:01:56 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id GAA04937; Mon, 25 Sep 1995 06:55:21 +0300 To: Guido van Rooij , Brian Tao Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG References: <199509241950.UAA06285@gvr.win.tue.nl> In-Reply-To: <199509241950.UAA06285@gvr.win.tue.nl>; from Guido van Rooij at Sun, 24 Sep 1995 20:50:19 +0100 (MET) Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 25 Sep 1995 06:55:20 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Guido's pwd_mkdb improvements (fwd) Lines: 17 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 743 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199509241950.UAA06285@gvr.win.tue.nl> Guido van Rooij writes: >A simple observation: most master.passwd updates are done because >only one line needs to be updated. So I added an option to >pwd_mkdb that only touches a specific record. Does it handle in right way users with different names but the same uid? I remember 1.x one-record-update version update only first one in this case... I.e. how store-by-uid works in this case? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sun Sep 24 21:45:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA01183 for hackers-outgoing; Sun, 24 Sep 1995 21:45:40 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA01175 for ; Sun, 24 Sep 1995 21:45:37 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id VAA07615 for ; Sun, 24 Sep 1995 21:45:33 -0700 To: hackers@freebsd.org Subject: Unusual networking question from the net.. Date: Sun, 24 Sep 1995 21:45:33 -0700 Message-ID: <7613.812004333@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Subject: heavy preformance-problems Date: 21 Sep 1995 10:18:45 +0200 From: unrz38@cd4680fs.rrze.uni-erlangen.de (Eduard Beier) Organization: Regionales Rechenzentrum Erlangen, Germany Newsgroups: comp.unix.bsd.freebsd.misc we have developed an application for network-monitoring, using the bpf. With bsdi, we can moitor ca. 6000 packets without packetloss on a 486/66mhz-eisa. Using FreeBSD 2.0.5 , the packet-loss starts at very light load (ca. 500Packets/s). Without the update-process (Process #4), the loss starts at 3000 P/s, even on a P90/PCI. what's going wrong? is it the scheduler, the drivers? Thanx in advance eduard.beier@rrze.uni-erlangen.de From owner-freebsd-hackers Sun Sep 24 23:41:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03417 for hackers-outgoing; Sun, 24 Sep 1995 23:41:04 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA03412 for ; Sun, 24 Sep 1995 23:41:01 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id HAA24503 for ; Mon, 25 Sep 1995 07:40:58 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id HAA24690 for freebsd-hackers@FreeBSD.ORG; Mon, 25 Sep 1995 07:40:57 +0100 Received: (from roberto@localhost) by keltia.Freenix.FR (8.7/keltia-uucp-2.5.1) id BAA06996 for freebsd-hackers@FreeBSD.ORG; Mon, 25 Sep 1995 01:36:41 +0100 (MET) From: Ollivier Robert Message-Id: <199509250036.BAA06996@keltia.Freenix.FR> Subject: gunzip and uncompress To: freebsd-hackers@FreeBSD.ORG (FreeBSD Hackers' list) Date: Mon, 25 Sep 1995 01:36:40 +0100 (MET) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1085 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Is there a strong opposition about making uncompress a hard link to gunzip? I do it there because some of the UUCP sites I feed send me !cunbatch batches compressed with gzip and it makes life easier to let gunzip handle both .Z and .gz files... I have the patch if there is an interest. -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.Freenix.FR 2.2-CURRENT #1: Sun Sep 10 18:50:19 MET DST 1995 From owner-freebsd-hackers Sun Sep 24 23:50:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03645 for hackers-outgoing; Sun, 24 Sep 1995 23:50:13 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA03637 ; Sun, 24 Sep 1995 23:50:11 -0700 Date: Sun, 24 Sep 1995 23:50:11 -0700 From: Jeffrey Hsu Message-Id: <199509250650.XAA03637@freefall.freebsd.org> To: julian Subject: Re: disk going bad? Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Under 2.0.5, run the sample script in the scsi(8 or 1) man page to turn on bad-block remapping I did this and found Auto Read Reallocation was already on. In theory, how is this supposed to work? If the drive replaces the bad read block w/ a good block, how does the fs handle the lost data? From owner-freebsd-hackers Mon Sep 25 00:21:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04097 for hackers-outgoing; Mon, 25 Sep 1995 00:21:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04091 for ; Mon, 25 Sep 1995 00:21:17 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA02192; Mon, 25 Sep 1995 17:20:04 +1000 Date: Mon, 25 Sep 1995 17:20:04 +1000 From: Bruce Evans Message-Id: <199509250720.RAA02192@godzilla.zeta.org.au> To: dennis@etinc.com, hm@altona.hamburg.com Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> >- it isn't possible to give a correect device_id. 0 is for clkintr. >> > The device_id is only used for counting interrupts. To fix this >> > you would have to expand the string table in vector.s and edit it. >It seems to be almost impossible to give it, NR_DEVICES is a constant >computed by config, it must be made a variable. Allocate some spare devices in vector.s. Note that until you change all clients of intrcnt[] and intrnames[] (in particular, systat and vmstat), the interrupt arrays have to be statically allocated. Also, once allocated, the interrupt names and counts must be preserved until the system is rebooted (the interrupt names are actually device+ interrupt names and it is possible for the same interrupt to be attached to different devices at different times). >> >>What is the way to tell the driver at mod-load time it's IRQ and i/o addr ? >> > >> >There is no way. >There should be a way to make this usable. You get to implement new things if you write the first modloadable driver :-). Actually, the question is wrong. Modload shouldn't do any more than load and attach the driver. Once it is loaded you can send ioctls to it. There probably needs to be a non-physical control device that the ioctls can be sent to to tell the driver where the physical devices are. >> This method is not good and requires some thought. In the big picture, one of >> the most useful purposes of modules is the ability to add devices without having >> to recompile the kernel. If I have to install dummy drivers I've lost my >> need to use modules. The dummy drivers are a temporary kludge. The system could supply a limited number of dummy drivers. E.g., until devfs exists, major device numbers must be reserved and there is little extra overhead for reserving a dummy device for each reserved major. >It seems that some work is necessary on the device driver lkm model to make >it fully work: there must be a way to specify a device driver interrupt >handler, the hardware interrupt to use and a i/o and memory address (range). To make it work at all :-). >For me it looks like certain constants are computed at compile time rather >than runtime, and depending on this constants some kernel tables are sized. >This has to change, there should be a fixed size table (filled with dummies >for nonexistent devices) for all possible interrupts which will be filled >with the respective entries by mod-loading a driver. A fixed size table would be worse than what I suggested above: a variable user-configured table (the same as now) with `n' (>= 0) user- configured dummy entries. When a new driver is loaded it takes one of the free dummy entries just like it would if everything was fully dynamic; the case n == 0 must be handled the same as if some dynamically allocated resource is exhausted. >Also, it is unclear what should happen with the probe and attach routines. They will have to be much more careful to run in multi-user mode. Bruce From owner-freebsd-hackers Mon Sep 25 00:31:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04262 for hackers-outgoing; Mon, 25 Sep 1995 00:31:48 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04256 for ; Mon, 25 Sep 1995 00:31:44 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA28628; Mon, 25 Sep 1995 08:31:02 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA02076; Mon, 25 Sep 1995 08:31:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA06270; Mon, 25 Sep 1995 08:11:02 +0100 From: J Wunsch Message-Id: <199509250711.IAA06270@uriah.heep.sax.de> Subject: Re: FreeBSD Questions To: gcrutcher@datatrek.com (Gary Crutcher) Date: Mon, 25 Sep 1995 08:11:01 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <24091995171734970.II18467@datatrek.com> from "Gary Crutcher" at Sep 24, 95 05:08:09 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 711 Sender: owner-hackers@freebsd.org Precedence: bulk As Gary Crutcher wrote: > > 1) How or where do I get a 'restricted' shell program for customers > telneting into my site? There's no such thing like a `restricted' shell available. All the so-called `restricted' shells on other systems give admins a false confidence; they usually could be bypassed by a hacker in (depending on the line speed) less than 5 minutes. I'm not sure if you'd like it still... The only safe environment for such a case is setting up a chroot environment. It's a bit more work, but you can have a better feeling after you're done. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 25 00:45:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04590 for hackers-outgoing; Mon, 25 Sep 1995 00:45:25 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04577 ; Mon, 25 Sep 1995 00:45:23 -0700 Message-Id: <199509250745.AAA04577@freefall.freebsd.org> Subject: Re: disk going bad? To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Mon, 25 Sep 1995 00:45:23 -0700 (PDT) Cc: julian@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199509250650.XAA03637@freefall.freebsd.org> from "Jeffrey Hsu" at Sep 24, 95 11:50:11 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 792 Sender: owner-hackers@FreeBSD.org Precedence: bulk In reply to Jeffrey Hsu who wrote: > > Under 2.0.5, run the sample script in the scsi(8 or 1) man page > to turn on bad-block remapping > > I did this and found Auto Read Reallocation was already on. > > In theory, how is this supposed to work? If the drive replaces the > bad read block w/ a good block, how does the fs handle the lost > data? It doesn't and thats why you get the errors. What I'm interested in is what kind of controller/disk you are using since I have a combination that produces these error very predictably though I seem to be the only one having seen this... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Mon Sep 25 00:46:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA04636 for hackers-outgoing; Mon, 25 Sep 1995 00:46:18 -0700 Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA04631 for ; Mon, 25 Sep 1995 00:46:15 -0700 Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id IAA06834 for ; Mon, 25 Sep 1995 08:45:40 +0100 Received: from unknown(130.144.198.1) by relay.philips.nl via smap (V1.3+ESMTP) with SMTP id sma006816; Mon Sep 25 08:44:51 1995 Received: from spooky.lss.cp.philips.com by cnps.lss.cp.philips.com with smtp (Smail3.1.28.1 #1) id m0sx8Dv-0001aFC; Mon, 25 Sep 95 08:45 MET Received: by spooky.lss.cp.philips.com (Smail3.1.29.1 #1) id m0sx8DY-000HneC; Mon, 25 Sep 95 08:44 MET Message-Id: From: guido@spooky.lss.cp.philips.com (Guido van Rooij) Subject: Re: ANNOUNCE: ComOS 3.1.4 released for PortMaster (fwd) To: freebsd-hackers@freebsd.org Date: Mon, 25 Sep 1995 08:44:48 +0100 (MET) Reply-To: Guido.vanRooij@nl.cis.philips.com (Guido van Rooij) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2507 Sender: owner-hackers@freebsd.org Precedence: bulk This came up in a discussion about what OS'es to support on the Livingstone PM mailing list. -Guido Elya Kurktchi wrote: > From livingston.com!owner-portmaster-users Sun Sep 24 15:03:33 1995 > Date: Sun, 24 Sep 1995 06:53:12 -0700 > From: Elya Kurktchi > Message-Id: <199509241353.GAA26313@inet1.inetworld.net> > To: portmaster-users@livingston.com > Subject: Re: ANNOUNCE: ComOS 3.1.4 released for PortMaster > Sender: owner-portmaster-users@livingston.com > Precedence: bulk > Reply-To: Elya Kurktchi > > > At 12:54 AM 9/24/95 -0700, Ron Pinz wrote: > >>Once upon a time Chris B. Wilson, VectorNet shaped the electrons to say... > >>>Give them the hint and set the password to "PortItToBSDAlready!" :) > >> > > > >For those of you not capable of running PMConsole today, INVEST IN A REAL > >OS! It is youring whining, bitching, and complaining detracting from the > >usefulness of this mailing list. > > Well, for some reason a $2K pentium running freebsd with 64MB of RAM outperforms > a $35K Sparc20/71 with 512MB of RAM and best of all, you get to run real bsd > unix rather than solaris. Isn't that shocking? That means that I can spend > $33K on my customers, buying more modems and lines and offering more people > a job then wasting it on a machine that may have a supported os, but stinks > when it comes to doing the real job. I hate PC's personally, but after working > with crays and bleeding-edge desktop workstations, there seems to be some use > to them. SGI is a great platform and it has an unsupported OS, but it can > waste a SUN anytime, and in the real world case, so can a pentium running unix. > > >>People wanted PMconsole for Linux - that is in beta. > > > >I would be curious to know the installed base of PM equipment, where the > >customers do not have a supported OS available. Livinston has been > >supporting the majority of the commercial OS' (non-intel based) for years! > > Quite a bit now. Again why waste so much money when an intel based machine > can do the job. Note for an ISP, we want the job done with as little money > as possible so that we can make a profit, not waste it all on equipment. > > Elya > > ------------------------------------------------------------- > Elya S. Kurktchi Simply Internet > Vice President-Systems Admin 7841 Balboa Avenue, Suite 101 > elya@inetworld.net San Diego, CA 92111 > ------------------------------------------------------------- > > From owner-freebsd-hackers Mon Sep 25 01:18:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05301 for hackers-outgoing; Mon, 25 Sep 1995 01:18:27 -0700 Received: (from hsu@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05291 ; Mon, 25 Sep 1995 01:18:22 -0700 Date: Mon, 25 Sep 1995 01:18:22 -0700 From: Jeffrey Hsu Message-Id: <199509250818.BAA05291@freefall.freebsd.org> To: sos@FreeBSD.org Subject: Re: disk going bad? Cc: hackers Sender: owner-hackers@FreeBSD.org Precedence: bulk > It doesn't and thats why you get the errors. Let's distinguish between hardware and software errors. Here's what I think is going on. Please correct me immediately if I'm wrong at any step. With bad read block reallocation, the hard drive will automatically replace references to the bad block w/ a reference to a working block, right? This means fsck can only detect corrupt directory blocks, since it has no way to check the integrety of data files. Thus, aside from the new bad sectors, the drive is still safe to use, right? The concern from the hardware point of view is whether this is predictive of a general hardware catastrophe or of a slow degenerative failure. >From the fs point of view, the bad directories (references to new uninitialized blocks) can be corrected by fsck. I just have some bad directories which I need to replace from backup or some other source. And I have possibly some undetected bad data blocks somewhere, which I can also try to find by comparison w/ a recent backup. > What I'm interested in is what kind of controller/disk you are using > since I have a combination that produces these error very predictably > though I seem to be the only one having seen this... I have an UltraStor 34F (anyone want to buy one cheap?) and the drive which in question is a Quantum Empire 2100S. It's interesting and puzzling to note that the read failures are not completely reproducible. Some blocks which failed at one point are readable now. The whole thing has me pretty spooked about the continued reliance on this drive and I've since moved my home directory off it. Jeffrey From owner-freebsd-hackers Mon Sep 25 01:21:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05405 for hackers-outgoing; Mon, 25 Sep 1995 01:21:06 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id BAA05400 for ; Mon, 25 Sep 1995 01:21:03 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0sx8m1-0003voC; Mon, 25 Sep 95 01:20 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id JAA00231; Mon, 25 Sep 1995 09:20:20 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: dennis@etinc.com, hm@altona.hamburg.com, hackers@freebsd.org Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? In-reply-to: Your message of "Mon, 25 Sep 1995 17:20:04 +1000." <199509250720.RAA02192@godzilla.zeta.org.au> Date: Mon, 25 Sep 1995 09:20:19 +0100 Message-ID: <229.812017219@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-hackers@freebsd.org Precedence: bulk I guess, that you have noticed that pccard is doing this kind of stuff today, and isn't doing it particular well, since nobody knows what to do :-( It seems to me that we have several kinds of devices: 1. things which say: give me 0x200-0x21f, (similar for iomem, irq & dma). 2. things which say: give me one of {0x200-0x21f,0x300-0x31f,0x320-0x33f} (similar for iomem, irq & dma). 3. things which say: give me 0x20 ioaddresses. (similar for iomem, irq & dma) Now, we need to cater for all of these one way or another, and it doesn't get any easier when some pieces of HW use method 2 for port, 1 for irq and 3 for iomem. Anybody thought about this from scratch ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. It will be some time yet before progress goes to far... (Poul Henningsen) From owner-freebsd-hackers Mon Sep 25 02:48:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA07555 for hackers-outgoing; Mon, 25 Sep 1995 02:48:16 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA07549 for ; Mon, 25 Sep 1995 02:48:08 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id KAA02688; Mon, 25 Sep 1995 10:47:25 +0100 Date: Mon, 25 Sep 1995 10:47:24 +0100 (MET) From: Olof Johansson To: "Jordan K. Hubbard" cc: "Kaleb S. KEITHLEY" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <2685.811985817@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > That hasn't been my impression. They haven't out-and-out said no or > indicated that FreeBSD would be out of the running due to being > "free." A couple of netscape people came up to me at WC's booth at > USENIX and indicated that they ran FreeBSD themselves, so who knows? > :-) Cool! :-) Do they run FreeBSD at work, or just for themselves? The question is probably wether the FreeBSD-market is big enough for an own distribution or not. But there seems to be quite a few WWW-sites running FreeBSD. Let's hope they aren't too few. :) -Olof From owner-freebsd-hackers Mon Sep 25 04:04:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA08884 for hackers-outgoing; Mon, 25 Sep 1995 04:04:26 -0700 Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id EAA08879 ; Mon, 25 Sep 1995 04:04:21 -0700 Received: from rocannon.cam.harlequin.co.uk by holly.cam.harlequin.co.uk; Mon, 25 Sep 1995 12:04:10 +0100 Received: from [192.88.238.248] (dynamic-mac4.cam.harlequin.co.uk) by rocannon.cam.harlequin.co.uk; Mon, 25 Sep 1995 12:04:07 +0100 X-Sender: richard@mailhost.cam.harlequin.co.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Sep 1995 12:04:09 +0100 To: freebsd-hackers@freebsd.org, freebsd-install@freebsd.org, freebsd-question@freebsd.org From: richard@harlequin.co.uk (Richard Brooksby) Subject: Booting FreeBSD from the Windows NT Loader Sender: owner-hackers@freebsd.org Precedence: bulk I run my PC with Windows 95, Windows NT, and FreeBSD. I had some problems with the FreeBSD boot selector and Windows 95, so I started investigating other ways to boot. (Has anyone else had problems with Windows 95 and booteasy, by the way?) I discovered that the Windows NT loader can be configured to run other boot sectors from files in the DOS partition. The boot loader's INI file (usually C:\BOOT.INI) just needs to be edited to point at the file containing the sector. DON'T ATTEMPT THIS UNLESS YOU KNOW WHAT YOU'RE DOING. I think you must be ready to edit partition tables by hand using a sector editor before you start mucking about with them, in general. I've had to do this on several occasions to avoid trashing Windows NT, which is a bit sensitive about them. Make backup copies on floppy disks and make sure you have the utilities to put them back if things should go wrong. To boot FreeBSD from the NT loader, copy your existing boot sector for the FreeBSD partition to a file on the DOS C: drive. Something like this will do the trick: dd if=/dev/wd0c of=/freebsd.sec bs=512 count=1 (Change wd0c to sd0c if you boot from a SCSI disk. You could copy the appropriate file from /usr/mdec instead, but I'm typing this from memory on my Mac and couldn't tell you which ones offhand. Read the manual.) Then alter the BOOT.INI file on C: so it contains a line like this under the "[operating systems]" heading: c:\freebsd.sec="FreeBSD" The NT boot loader will then give you FreeBSD as an option. You can make it the default by editing the "DEFAULT=" line in BOOT.INI in the obvious manner. You can also add other boot sectors for other systems, although I haven't tried it with the Linux LILO boot loader. Once you have this working, you can restore the original master boot record for DOS or Windows 95 use by running "FDISK /MBR" from DOS. You are less likely to have trouble with Windows 95, Windows NT, or OS/2 booting and partitioning if you keep the default MBR. I would be interested to hear from anyone else who uses this trick. Please send me some mail if you try it, successfully or not. FYI, I'm running: - FreeBSD 2.0 with a locally patched kernel - Windows 95 beta (as released on the Microsoft Developer's Network) - Windows NT 3.51 retail version --- Richard Brooksby Manager & Developer / Memory Management / Symbolic Processing / Harlequin +44 1223 873881 (voice) +44 1223 872519 (fax) From owner-freebsd-hackers Mon Sep 25 06:21:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10745 for hackers-outgoing; Mon, 25 Sep 1995 06:21:03 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA10734 for ; Mon, 25 Sep 1995 06:21:00 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08987; Mon, 25 Sep 1995 09:20:28 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 25 Sep 1995 09:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id UAA13182; Sat, 23 Sep 1995 20:07:24 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id UAA10972; Sat, 23 Sep 1995 20:17:35 -0400 Date: Sat, 23 Sep 1995 20:17:35 -0400 From: Thomas David Rivers Message-Id: <199509240017.UAA10972@lakes> To: dfr@render.com, blob.best.net!dillon@dg-rtp.dg.com Subject: Re: More on NFS bug... can be reproduced with dd Cc: bugs@freebsd.org, hackers@freebsd.org Content-Type: text Content-Length: 721 Sender: owner-hackers@freebsd.org Precedence: bulk > > Yes, the allocbuf() patch did the trick! > > -Matt Being out of the loop for a while, I missed this fix. Would someone be kind enough to send it to me... - Thanks - - Dave Rivers - (ponds!rivers@dg-rtp.dg.com) > > > >On Fri, 14 Jul 1995, Matt Dillon wrote: > > > >> dd if=bigfile of=outfile bs=1536 > >> > >> Where if and of are both on an NFS mounted filesystem seems to reproduce > >> the bug. > > > >Is is possible that this might be fixed by the recent change to vfs_bio? > >Can you reproduce it with that fix in place? > > > >-- > >Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com > > Phone: +44 171 251 4411 > > FAX: +44 171 251 0939 > > > > > > From owner-freebsd-hackers Mon Sep 25 06:21:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10747 for hackers-outgoing; Mon, 25 Sep 1995 06:21:04 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA10735 for ; Mon, 25 Sep 1995 06:21:00 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA08963; Mon, 25 Sep 1995 09:20:26 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 25 Sep 1995 09:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id UAA13172; Sat, 23 Sep 1995 20:02:55 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id UAA10946; Sat, 23 Sep 1995 20:13:05 -0400 Date: Sat, 23 Sep 1995 20:13:05 -0400 From: Thomas David Rivers Message-Id: <199509240013.UAA10946@lakes> To: rah.star-gate.com!hasty@dg-rtp.dg.com, witr@rwwa.com Subject: Re: TCL vs... Cc: hackers@freebsd.org Content-Type: text Content-Length: 1737 Sender: owner-hackers@freebsd.org Precedence: bulk Amancio said: > >>> Robert Withrow said: > > > >>> Peter da Silva said: > > > > > The "FreeBSD killer app" syndrome smells like technology for the > > > > > sake of technology. > > > > > > > > Quite the contrary. It's a challenge to that mindset. > > > > > > Sorry I don't consider this a challenge at all. > > > > > What will end users do with FreeBSD? > > > So lets see, hack on device drivers, VM systems, add new system calls, etc > .. > > > > Well, in my company's case, they use it to measure and manufacture > > jet engines...In a nifty integrated yet distributed way... > > > > And I am sure that your company developed or ported the application. > BTW: I am very impressed... > > This brings about another interesting point what are people doing > with FreeBSD besides kernel hacking or system related work? > > Amancio Well - I know this was from a long time ago; I've been laid up with a bad back for quite a while; and am just now able to sit up long enough to read mail. Anyway, I thought I'd respond to Amancio's question. I use FreeBSD at home as a uucp connection to several sites on the east coast. I use FreeBSD at work as another endian host for the SAS/C Cross-Platform C compiler (an IBM-370 targetted ANSI C/C++ system.) My goal is to address all the endian issues in the product, without having to set up a different (i.e. windows) build environment. I was even able to talk my managers into getting me a fancy Dell P-90 to do this with... Also, we use it, along with a SunOs 4.1.x box, as our BSD reference, when we need to determine "Now just what does UNIX do with this function?" [We have some other SysV boxes to answer that end of the question.] - Dave Rivers - From owner-freebsd-hackers Mon Sep 25 06:21:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10770 for hackers-outgoing; Mon, 25 Sep 1995 06:21:07 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA10744 for ; Mon, 25 Sep 1995 06:21:02 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09008; Mon, 25 Sep 1995 09:20:30 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 25 Sep 1995 09:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id UAA13236 for ; Sat, 23 Sep 1995 20:29:10 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id UAA11120 for freebsd-hackers@freebsd.org; Sat, 23 Sep 1995 20:39:21 -0400 Date: Sat, 23 Sep 1995 20:39:21 -0400 From: Thomas David Rivers Message-Id: <199509240039.UAA11120@lakes> To: freebsd-hackers@freebsd.org Subject: That annoying pty problem again... Content-Type: text Content-Length: 754 Sender: owner-hackers@freebsd.org Precedence: bulk I just had the "old" vs. "new" (SIGHUP?) pty problem again. Just to refresh everone's memory, let me know if you've seen this: 1) Start an Xterm... 2) Start 'vi' in that xterm. 3) Shut down the X server, forcing logoff (i.e. CNTL-ALT-BS) 4) Restart the X server 5) Start another xterm - which happens to get the same pty as the one running 'vi' 6) Suddenly, you'll discover that some of your keystrokes are going to that (now supposedly dead) 'vi' session, which is also producing output to your pty (xterm) - along with the shell you have running in your xterm. That is - it would appear that a SIGHUP is getting lost; or the pty driver isn't sending one when the client side is cut off... - Dave Rivers - From owner-freebsd-hackers Mon Sep 25 06:21:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10796 for hackers-outgoing; Mon, 25 Sep 1995 06:21:10 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA10748 for ; Mon, 25 Sep 1995 06:21:04 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA09018; Mon, 25 Sep 1995 09:20:32 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 25 Sep 1995 09:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id GAA03273 for ; Mon, 25 Sep 1995 06:59:36 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id HAA00233 for freebsd-hackers@freefall.cdrom.com; Mon, 25 Sep 1995 07:06:48 -0400 Date: Mon, 25 Sep 1995 07:06:48 -0400 From: Thomas David Rivers Message-Id: <199509251106.HAA00233@lakes> To: freebsd-hackers@freefall.FreeBSD.org Subject: My sound problems... (sound stopping after a second.) Content-Type: text Content-Length: 434 Sender: owner-hackers@FreeBSD.org Precedence: bulk Just to let everyone know - I figured out my sound problems. Turns out I had configured the sound card at IRQ 5, but had not done the same in my kernel config file (it was still at IRQ 7.) I forgot that on this paricular machine, I use 'boot -c' to move the IRQ... this lets me share the same kernel with other machines (handy feature, that 'boot -c') - keeping the number of config files to a minimum. - Dave Rivers - From owner-freebsd-hackers Mon Sep 25 07:32:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA12341 for hackers-outgoing; Mon, 25 Sep 1995 07:32:06 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA12328 for ; Mon, 25 Sep 1995 07:31:56 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id KAA29509; Mon, 25 Sep 1995 10:39:25 -0400 Date: Mon, 25 Sep 1995 10:39:25 -0400 Message-Id: <199509251439.KAA29509@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Poul-Henning Kamp From: dennis@etinc.com (dennis) Subject: Re: LKM: how to fiddle in interrupt routine ptrs ? Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >I guess, that you have noticed that pccard is doing this kind of stuff today, >and isn't doing it particular well, since nobody knows what to do :-( > >It seems to me that we have several kinds of devices: > >1. things which say: give me 0x200-0x21f, (similar for iomem, irq & dma). >2. things which say: give me one of {0x200-0x21f,0x300-0x31f,0x320-0x33f} > (similar for iomem, irq & dma). >3. things which say: give me 0x20 ioaddresses. (similar for iomem, irq & dma) > >Now, we need to cater for all of these one way or another, and it doesn't >get any easier when some pieces of HW use method 2 for port, 1 for irq and >3 for iomem. > >Anybody thought about this from scratch ? > Linux uses a check_region(), request_region() and release_region() approach, although I don't think there is a giveme_a_region_please(). Memory is a little tricky because many cards don't initalize the memory until they are started, which may not be at device load time. We don't initialize our card with the device specified location, which gives you the flexibility to move it around (in case of confict) without changing the kernel. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Mon Sep 25 07:38:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA12676 for hackers-outgoing; Mon, 25 Sep 1995 07:38:37 -0700 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA12661 for ; Mon, 25 Sep 1995 07:38:34 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA20471; Mon, 25 Sep 1995 07:12:58 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA20291; Mon, 25 Sep 1995 10:12:56 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id KAA06744 for ; Mon, 25 Sep 1995 10:14:01 GMT Message-Id: <199509251014.KAA06744@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: Your message of "Sun, 24 Sep 1995 17:17:30 -0400." X-Mailer: exmh version 1.5omega 10/6/94 Date: Mon, 25 Sep 1995 10:13:56 +0000 From: Matt Thomas Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan Hubbard said: > I'm currently talking with them (Netscape) about this very subject. > Apparently they need dlopen()/dlsym() functionality in Netscape 2.0 > and this is not provided in BSDI 1.1, so there's a problem. > > I'm now busily trying to talk them into doing both BSDI 2.0 and > FreeBSD 2.x native ports.. :-) However BSD/OS 2.0 doesn't have dlopen or dlsym either. From the 2.0 slicc man page: BUGS Shlicc is currently a shell script, with all the problems that entail from that. Pure compiles aren't too much slower because the script execs cc(1) as soon as it parses enough arguments to realize that linking isn't necessary. Linking ought to be slower because the script runs awk(1) and other heavyweight programs, but the fact that no code needs to be loaded from the stub library, and hence no relocations need to be performed on the library or its symbols, can actually make linking a little faster. If a shared library is missing or corrupted or unreadable, programs will print errors and dump core. The shared C library contains the library loader routine; if it's hosed, then basically nothing works. If the shared C library is deleted or mangled, you may need to boot from floppy to restore it. Turning on profiling turns off shared libraries. It didn't seem useful to save space in binaries and then waste it by producing profiled shared libraries that are hardly ever used. Shared library text and data do not appear in core dumps. The current core dump file format isn't rich enough to support multi-segment core im- ages. Also, debugging can be inconvenient because you can't put break- points in code that isn't mapped yet, and the libraries are not mapped until after the program starts. The overhead of loading the shared libraries is small but measurable. There are 6 system calls per library at startup before executing any user code. There is also some small overhead in indirecting through the jump table. On the plus side, sharing library pages means that they are more likely to be in core and thus less likely to require paging in. The current implementation is cheap and fast, using statically linked li- braries rather than dynamically linked libraries. This scheme makes bi- naries smaller and start-up much faster, but it has some limitations. In particular, if you write a substitute for a library routine and use the shared library, the calls to that routine from within the shared library will use the library version, not your version. This is particularly an- noying with programs that provide their own malloc(3) and free(3) rou- tines; if you try to free memory that was generated from (say) the shared strdup(3), your program can dump core. Also, if library code compares a pointer to a library function that was passed to it from user code to the address of the library function, it will fail because the user code sees only the address of the jump table slot. (Yes, some standard library code actually does this!) The current implementation has no automatic versioning. Crude library version changes can be effected using the shlib.map file, however. In spite of the names and the implementation strategy, these shared li- braries have nothing in common with SVr3 shared libraries and are not compatible with them. You aren't imagining things, though; this imple- mentation is just as simple and lacking in features. Simpler, actually: there is no special kernel support for these shared libraries; they are implemented in user mode with standard BSD system calls. While this may be fine for BSDI to base their product, there is no way of any third party product (such as Netscape) to produce their own shared libraries. All libraries have base addresses and there is not a guarunteed way of avoiding address conflicts. The FreeBSD (and NetBSD for that matter) dynamic libraries is much more sophisticated than what's in BSD/OS 2.0. Matt Thomas Internet: matt@lkg.dec.com 3am Software Foundry WWW URL: Westford, MA Disclaimer: Digital disavows all knowledge of this message From owner-freebsd-hackers Mon Sep 25 08:11:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA13598 for hackers-outgoing; Mon, 25 Sep 1995 08:11:52 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA13593 for ; Mon, 25 Sep 1995 08:11:44 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA12188; Mon, 25 Sep 1995 10:47:24 -0400 Date: Mon, 25 Sep 1995 10:47:24 -0400 From: Coranth Gryphon Message-Id: <199509251447.KAA12188@healer.com> To: guido@gvr.win.tue.nl, julian@ref.tfs.com Subject: Re: Guido's pwd_mkdb improvements (fwd) Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG, taob@io.org Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Julian Elischer > you can sort the passwd on uid and name before editing it, do the same > afterwards, get a diff, change those records and then store the version > of the passwd file the user saved (user selected order) There is one thing that this might break (I'm not sure, but lest ye forget). I often use the "multiple names/passwords, single uid" system. And since the first encountered name with that uid is considered "canonical", might an alphabetic sorting not screw things up? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 08:13:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA13659 for hackers-outgoing; Mon, 25 Sep 1995 08:13:33 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA13652 for ; Mon, 25 Sep 1995 08:13:08 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA12169; Mon, 25 Sep 1995 10:41:35 -0400 Date: Mon, 25 Sep 1995 10:41:35 -0400 From: Coranth Gryphon Message-Id: <199509251441.KAA12169@healer.com> To: jmb@kryten.atinc.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > > same name == same script == same actions. > Consider: A package which requires a daemon to be run needs to add a > startup and a shutdown script to the list of scripts to be executed. That's why I've been advocating a single master file. It adds the script to the startup script directory (we've been calling it "/etc/init/d") and makes a one line addition to "inittab". > It may also need to add a cron job to rotate the damons logs. No. With the new "daily" script handler (Jordan, have you told anyone else about this yet?) all it needs to do is add a line to the scheduled jobs config file (current name "sched.conf" like: rotate_log daily /some/log/file > The point of using seperate files is that the directory entry/deletion > mechanism is arbitrated automatically, in the kernel, without the use of > user level locks. Granted. But I think it's still worth it for a control file. It makes everything else simpler, and the kernel/file-system already supports the "Nope you can't open this file for writing, someone else already has it open for writing". (If it doesn't then it's a wonder everything hasn't broken a lot already :-) > Ordering guarantees within a single run level/state are hard to provide > with the single monolithic file model. Actually, a single file is the easiest to control ordering in. Last I checked, line 1 always came before line 2. :-) > Finally, what if I don't want to delete the package, I just want to > disable it? How to I prevent the package daemon's and cron jobs from Comment out the line in the control file? > Typically, I'd put the "cron" jobs as at commands in the startup script, > though this begs the question of providing configurability under > administrative control (for instance, what if I want to specify a higher > or lower frequency of log rotation?). Cron actually faces the same > issues as init. As above, given that you have the granularity of "daily", "weekly", or "monthly". I suppose we could always add "bi-weekly" and "bi-monthy" :-/ -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 08:14:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA13723 for hackers-outgoing; Mon, 25 Sep 1995 08:14:30 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA13718 for ; Mon, 25 Sep 1995 08:14:16 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA12130; Mon, 25 Sep 1995 10:25:22 -0400 Date: Mon, 25 Sep 1995 10:25:22 -0400 From: Coranth Gryphon Message-Id: <199509251425.KAA12130@healer.com> To: hackers@FreeBSD.ORG, peter@jhome.DIALix.COM Subject: Re: IPFW vs IPACCT vs IPFIL2.8 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Peter Wemm > With all the talk about swapping IPFW for IPFIL2.8 from Darren Reed, the > main reason that's come up as to why not, is that IPFW can do accounting. > Perhaps it might be an idea to try and split off the accounting functions > from the ipfw package, or make an entirely self-contained accounting system. I like this idea a lot. Help offered. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 08:14:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA13739 for hackers-outgoing; Mon, 25 Sep 1995 08:14:51 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA13733 for ; Mon, 25 Sep 1995 08:14:44 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA12122; Mon, 25 Sep 1995 10:22:40 -0400 Date: Mon, 25 Sep 1995 10:22:40 -0400 From: Coranth Gryphon Message-Id: <199509251422.KAA12122@healer.com> To: jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Sat, 23 Sep 1995, Peter da Silva wrote: > hold all the random *.conf files (/etc/conf.d?) > would tidy up /etc no end too... One thing that came up earlier (I forgot who I agreed with :-) was to put anything that had a bunch of control files (ppp, named, inet, uucp, mail) in it's own directory and keep the generic stuff (everything with only one or two files) in /etc. Why? Because /etc IS the one-stop-shopping place for config files. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 08:15:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA13806 for hackers-outgoing; Mon, 25 Sep 1995 08:15:29 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA13792 for ; Mon, 25 Sep 1995 08:15:17 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA12092; Mon, 25 Sep 1995 10:02:39 -0400 Date: Mon, 25 Sep 1995 10:02:39 -0400 From: Coranth Gryphon Message-Id: <199509251402.KAA12092@healer.com> To: jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Sun Sep 24 14:40:07 1995 Date: Sun, 24 Sep 1995 11:19:40 -0400 (EDT) Subject: Re: ports startup scripts To: Peter da Silva cc: hackers@freebsd.org In-Reply-To: <199509241434.JAA09429@bonkers.taronga.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Peter da Silva wrote: > > solves the rename problem. not the 'is it the same of is it not, > > i have to did deeper' problem. > > Sure. If you do it right you just need to make sure it's a symlink. From: "Jonathan M. Bresler" > urg....symlink. two files. requires diff or ls -F to determine Agreed. I've said it before - symlink are only useful if you (for some reason) can't put something where it belongs, of if it really needs to be in two places at one: the latter translates as "cannot be easily gotten at in the proper place" or "a non-optimal location is hard-coded in something". There is no need to two sets of directorys off of /etc with the contents of one being linked to the other. > one directory for all run-states?? or one directory for each. i > am advocating one directory for all start, kill and restart scripts. I still prefer run-levels (as opposed to states), but I'd still rather see one directory per state than anything else. Run levels solve all the problems of "But it may need to be in more than one place". Or if you put it in one directory, you need either very careful naming (can be done, risky) or a "inittab" control file. (solves the ordering problem). > > > In /etc/daily: > > find /etc/rc*.d -type f -print > /tmp/$$ > yes. but when i want to understand the startup/shutdown process > running a piece of /etc/daily is...not the obvious step. Before depending upon /etc/daily, check with Jordan as to the new way of doing daily/weekly/... I mailed him the final version a couple of days ago. Daily (and weekly and monthly) is now just a list of scripts to call (the list being just for ordering purposes) and is auto-generated from a config file. This is very simple to implement and very easy to keep from getting screwed up. We might just want to go with this framework for init as well... > > i expect the ports-meister and packages-master to enforce that > > level of consistency. > > You're assuming that only official ports are going to use this. Bad assumption. > if you are using a non-offical port, you are NOT a newbie. if > yoy really are a newbie, well, either you overestimated your capabilities > or your gaining experience ;) Put in a "site.Ports.FAQ" to explain what is being done and the pitfalls to watch out for. > for instance: (concept, not correct implementation) > multi_user = "syslog cron" > network = "syslog cron_net ifconfig named" Yep. That works. The only problem is shutting things down, if you are not simple shutting everything down. Actually, at that point you'd need a matrix of what to stop and start depending upon what run-state you are going from and to. All the more reason to go with linear run-levels. > now i know that both use the same syslog start script > and that they start cron differently. > the order is explicit, not implicit ascii sort order Yep. Alternately, the "cron" script can take an argument of "multi-user" or "network" and do the right thing. in summary, my druthers are: > one directory for all start and stop scripts > explicit invocation order, a list > one name per script regardless of run-state/level > (no links hard or soft) Yep. I'll buy that for a dollar. > explicit names: Snamed (start.named, whatever) Or two optional arguments to each script: the name of the run-state or number of the run-level and "start"/"stop"/"restart". Even clearer. > that both use a master file. one exists as a file, the other > exists as an artifact of ascii sort order (not obvious to our poor > newbie, especially when we have to explain that 10 comes before 2). a > list of tasks/scripts is clearer to our newbie and easier for everyone else. A master file, which generates a set of run-state script. The program which generates the "rc.N" scripts (N being run-state #) check for consistency (ie major screw-ups, possibly even dependencies) before replacing the older "rc.N" file. All the scripts reside in /etc/init.d and take a single argument of "start", "stop", or "restart". Very similar to what is now being done for "daily"/"weekly". Which I've already done, so could do this one just as easily. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 08:48:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA14836 for hackers-outgoing; Mon, 25 Sep 1995 08:48:55 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA14830 for ; Mon, 25 Sep 1995 08:48:49 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id IAA25402; Mon, 25 Sep 1995 08:47:33 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA28921; Mon, 25 Sep 1995 08:53:10 -0700 Date: Mon, 25 Sep 1995 08:53:10 -0700 Message-Id: <9509251553.AA28921@asimov.volant.org> To: jmb@kryten.atinc.com, terry@lambert.org, gryphon@healer.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, peter@taronga.com X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > Consider: A package which requires a daemon to be run needs to add a |> > startup and a shutdown script to the list of scripts to be executed. |> |> That's why I've been advocating a single master file. It adds the script |> to the startup script directory (we've been calling it "/etc/init/d") and |> makes a one line addition to "inittab". Aaaccckkkk!!!! One of the biggest wins of the SVr4/Solaris2/etc. system is that packages -NEVER NEED TO EDIT STARTUP FILES-. Automatic editting of files is DANGEROUS and should be avoided. (Please excuse me for shouting there, but this is important.) |> > It may also need to add a cron job to rotate the damons logs. |> |> No. With the new "daily" script handler (Jordan, have you told anyone |> else about this yet?) all it needs to do is add a line to the scheduled |> jobs config file (current name "sched.conf" like: |> |> rotate_log daily /some/log/file Could this be changed to 'add a file to the scheduled jobs directory', to avoid the need to automatically edit a file? |> > Ordering guarantees within a single run level/state are hard to provide |> > with the single monolithic file model. |> |> Actually, a single file is the easiest to control ordering in. |> Last I checked, line 1 always came before line 2. :-) Ah, but can you guarantee that the install script that inserts a few new lines is putting them in the right place? -Pat From owner-freebsd-hackers Mon Sep 25 08:49:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA14878 for hackers-outgoing; Mon, 25 Sep 1995 08:49:34 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA14873 for ; Mon, 25 Sep 1995 08:49:30 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA12856 (5.67a/IDA-1.5 for hackers@freebsd.org); Mon, 25 Sep 1995 10:20:05 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id JAA12801; Mon, 25 Sep 1995 09:16:54 -0500 Date: Mon, 25 Sep 1995 09:16:54 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509251416.JAA12801@bonkers.taronga.com> To: hackers@freebsd.org Subject: Re: That annoying pty problem again... Newsgroups: taronga.freebsd.hackers In-Reply-To: <199509240039.UAA11120@lakes> Organization: Taronga Park BBS Sender: owner-hackers@freebsd.org Precedence: bulk I've been getting it from people quitting telnet sessions without exiting the program they were running. When you close a PTY, what should happen is you get a SIGHUP, and further reads from the PTY get EOF. I suspect that some programs ignore both these events. From owner-freebsd-hackers Mon Sep 25 09:55:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA16586 for hackers-outgoing; Mon, 25 Sep 1995 09:55:40 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA16571 for ; Mon, 25 Sep 1995 09:55:31 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id MAA12655; Mon, 25 Sep 1995 12:57:13 -0400 Date: Mon, 25 Sep 1995 12:57:13 -0400 From: Coranth Gryphon Message-Id: <199509251657.MAA12655@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From patl@asimov.volant.org Mon Sep 25 11:52:00 1995 Date: Mon, 25 Sep 1995 08:53:10 -0700 To: jmb@kryten.atinc.com, terry@lambert.org, gryphon@healer.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, peter@taronga.com X-Sun-Charset: US-ASCII From: patl@asimov.volant.org > |> > Consider: A package which requires a daemon to be run needs to add a > |> > startup and a shutdown script to the list of scripts to be executed. > |> > |> That's why I've been advocating a single master file. It adds the script > |> to the startup script directory (we've been calling it "/etc/init/d") and > |> makes a one line addition to "inittab". > One of the biggest wins of the SVr4/Solaris2/etc. system is that > packages -NEVER NEED TO EDIT STARTUP FILES-. Automatic editting > of files is DANGEROUS and should be avoided. > |> Actually, a single file is the easiest to control ordering in. > |> Last I checked, line 1 always came before line 2. :-) > Ah, but can you guarantee that the install script that inserts a > few new lines is putting them in the right place? Can you guarantee that the install script is going to get the numbering right if we go with implicit order based upon script name? Or worse, is every install going to check to make sure that no other scripts exists which use that order number? Or renumber all the other scripts if they do? Or come with a list of numbers to choose from? I think these are a LOT more dangerous. File order is explicit and simple. Anything else is headaches. > |> > It may also need to add a cron job to rotate the damons logs. > |> > |> No. With the new "daily" script handler (Jordan, have you told anyone > |> else about this yet?) all it needs to do is add a line to the scheduled > |> jobs config file (current name "sched.conf" like: > |> > |> rotate_log daily /some/log/file > Could this be changed to 'add a file to the scheduled jobs directory', > to avoid the need to automatically edit a file? If you want, put it as "mumble.daily" in /etc/bin and it will be run automatically. Yes, this relies upon implicit order (whatever "find" returns), which I really don't like. But I couldn't see any other option, and if you were hand-adding scripts you could bloody well get the order right yourself DESIGNING a system around implicit order I consider reckless. And yes, I know that SysV does it, and that is works fine for whoever. I don't like SysV. Specifically, I don't like this "feature" of SysV. That's what I run a BSD variant. It boils down to that. A few other people have said it, and I'll say it too. I don't want FreeBSD to become a SysV-clone. That's what Linux is for. If people want changes to the startup mechanism, to incorporate the best concepts from SysV, that's fine. It's call improving. But throwing out the entire "rc" script concept, and going with (pick an implemention, any mutant implementation) SysV-clone I consider bad. It also comes down to implementation and support. I'll gladly volunteer to write and support the version I'm pushing for, and do whatever the improvements to that base design that people want. Will you volunteer the same for your version? Including a re-write of the "daily/weekly" stuff that reallly should use the same mechanism? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 11:03:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18127 for hackers-outgoing; Mon, 25 Sep 1995 11:03:15 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18119 for ; Mon, 25 Sep 1995 11:03:08 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05448; Mon, 25 Sep 1995 10:59:42 -0700 From: Terry Lambert Message-Id: <199509251759.KAA05448@phaeton.artisoft.com> Subject: Re: Unusual networking question from the net.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 25 Sep 1995 10:59:42 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <7613.812004333@time.cdrom.com> from "Jordan K. Hubbard" at Sep 24, 95 09:45:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 677 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > we have developed an application for network-monitoring, using the bpf. > With bsdi, we can moitor ca. 6000 packets without packetloss on a > 486/66mhz-eisa. > > Using FreeBSD 2.0.5 , the packet-loss starts at very light load > (ca. 500Packets/s). > Without the update-process (Process #4), the loss starts at 3000 P/s, > even on a P90/PCI. > what's going wrong? > is it the scheduler, the drivers? My guess is that because they are selling as a net server, they have raised the priority of SPLNET to the detriment of other drivers. 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 Sep 25 11:04:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18186 for hackers-outgoing; Mon, 25 Sep 1995 11:04:56 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18181 for ; Mon, 25 Sep 1995 11:04:52 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id SAA08425; Mon, 25 Sep 1995 18:59:24 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509251759.SAA08425@gvr.win.tue.nl> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Mon, 25 Sep 1995 18:59:24 +0100 (MET) Cc: taob@io.org, bugs@ns1.win.net, hackers@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Sep 25, 95 06:55:20 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 630 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= wrote: > > In message <199509241950.UAA06285@gvr.win.tue.nl> Guido van Rooij > writes: > > >A simple observation: most master.passwd updates are done because > >only one line needs to be updated. So I added an option to > >pwd_mkdb that only touches a specific record. > > Does it handle in right way users with different names but the same uid? > I remember 1.x one-record-update version update only first one > in this case... I.e. how store-by-uid works in this case? > Yes. It does handle them correctly. The username is used as the identifier, not the uid. -Guido From owner-freebsd-hackers Mon Sep 25 11:07:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18263 for hackers-outgoing; Mon, 25 Sep 1995 11:07:23 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18250 for ; Mon, 25 Sep 1995 11:06:55 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05460; Mon, 25 Sep 1995 11:02:38 -0700 From: Terry Lambert Message-Id: <199509251802.LAA05460@phaeton.artisoft.com> Subject: Re: FreeBSD Questions To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 25 Sep 1995 11:02:38 -0700 (MST) Cc: gcrutcher@datatrek.com, hackers@FreeBSD.ORG In-Reply-To: <199509250711.IAA06270@uriah.heep.sax.de> from "J Wunsch" at Sep 25, 95 08:11:01 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 467 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > The only safe environment for such a case is setting up a chroot > environment. It's a bit more work, but you can have a better feeling > after you're done. :-) And there's a nice large hole in that, too, if you have any directory hard links or fd's open to directories without close on exec set (or implied by the chroot). 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 Sep 25 11:08:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18332 for hackers-outgoing; Mon, 25 Sep 1995 11:08:26 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18327 for ; Mon, 25 Sep 1995 11:08:25 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA04534 for ; Mon, 25 Sep 1995 11:08:05 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id TAA08447; Mon, 25 Sep 1995 19:01:08 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509251801.TAA08447@gvr.win.tue.nl> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 19:01:07 +0100 (MET) Cc: julian@ref.tfs.com, bugs@ns1.win.net, hackers@FreeBSD.ORG, taob@io.org In-Reply-To: <199509251447.KAA12188@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:47:24 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 455 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > There is one thing that this might break (I'm not sure, but lest ye forget). > > I often use the "multiple names/passwords, single uid" system. > And since the first encountered name with that uid is considered "canonical", > might an alphabetic sorting not screw things up? I am using the exact same scheme as used by the original pwd_mkdb. My patches thus won't break something that wasn't broken before (modulo bugs in my improvements ;-)) -Guido From owner-freebsd-hackers Mon Sep 25 11:25:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18786 for hackers-outgoing; Mon, 25 Sep 1995 11:25:56 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18780 for ; Mon, 25 Sep 1995 11:25:52 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA27181; Tue, 26 Sep 1995 04:22:29 +1000 Date: Tue, 26 Sep 1995 04:22:29 +1000 From: Bruce Evans Message-Id: <199509251822.EAA27181@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, ponds!rivers@dg-rtp.dg.com Subject: Re: That annoying pty problem again... Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >I just had the "old" vs. "new" (SIGHUP?) pty problem again. >Just to refresh everone's memory, let me know if you've seen this: > 1) Start an Xterm... > 2) Start 'vi' in that xterm. > 3) Shut down the X server, forcing logoff (i.e. CNTL-ALT-BS) > 4) Restart the X server > 5) Start another xterm - which happens to get the same > pty as the one running 'vi' > 6) Suddenly, you'll discover that some of your keystrokes are > going to that (now supposedly dead) 'vi' session, which is > also producing output to your pty (xterm) - along with > the shell you have running in your xterm. > That is - it would appear that a SIGHUP is getting lost; or > the pty driver isn't sending one when the client side is cut > off... This should be fixed in current. Bruce ---------------------------- revision 1.21 date: 1995/09/19 12:26:47; author: bde; state: Exp; lines: +1 -2 Don't clear the session pointer in ptcclose(). It must be left alone until the session leader exits so that a SIGHUP gets sent to the process group and the pty slave gets revoked. ---------------------------- Index: tty_pty.c =================================================================== RCS file: /a/ncvs/src/sys/kern/tty_pty.c,v retrieving revision 1.20 retrieving revision 1.21 diff -c -2 -r1.20 -r1.21 *** 1.20 1995/09/08 11:08:38 --- 1.21 1995/09/19 12:26:47 *************** *** 32,36 **** * * @(#)tty_pty.c 8.2 (Berkeley) 9/23/93 ! * $Id: tty_pty.c,v 1.20 1995/09/08 11:08:38 bde Exp $ */ --- 32,36 ---- * * @(#)tty_pty.c 8.2 (Berkeley) 9/23/93 ! * $Id: tty_pty.c,v 1.21 1995/09/19 12:26:47 bde Exp $ */ *************** *** 323,327 **** tp->t_oproc = 0; /* mark closed */ - tp->t_session = 0; return (0); } --- 323,326 ---- From owner-freebsd-hackers Mon Sep 25 11:27:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA18844 for hackers-outgoing; Mon, 25 Sep 1995 11:27:26 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA18774 for ; Mon, 25 Sep 1995 11:25:18 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05510; Mon, 25 Sep 1995 11:17:52 -0700 From: Terry Lambert Message-Id: <199509251817.LAA05510@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 11:17:52 -0700 (MST) Cc: jmb@kryten.atinc.com, terry@lambert.org, hackers@FreeBSD.ORG, peter@taronga.com In-Reply-To: <199509251441.KAA12169@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:41:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2227 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > It may also need to add a cron job to rotate the damons logs. > > No. With the new "daily" script handler (Jordan, have you told anyone > else about this yet?) all it needs to do is add a line to the scheduled > jobs config file (current name "sched.conf" like: > > rotate_log daily /some/log/file What if I want to rotate them twice a week instead of daily? What about twice a day? > > Ordering guarantees within a single run level/state are hard to provide > > with the single monolithic file model. > > Actually, a single file is the easiest to control ordering in. > Last I checked, line 1 always came before line 2. :-) The problem is that the line starts are not a fixed locations and are therefore variant without whole file locking. Which is bad. > > Finally, what if I don't want to delete the package, I just want to > > disable it? How to I prevent the package daemon's and cron jobs from > > Comment out the line in the control file? OK. Then: 1) How do I tell which line(s) correspond to which package? 2) How do I reenable it? 3) How do I do this from an administrative utility instead of having to actually know what's what myself? > > Typically, I'd put the "cron" jobs as at commands in the startup script, > > though this begs the question of providing configurability under > > administrative control (for instance, what if I want to specify a higher > > or lower frequency of log rotation?). Cron actually faces the same > > issues as init. > > As above, given that you have the granularity of "daily", "weekly", or > "monthly". I suppose we could always add "bi-weekly" and "bi-monthy" :-/ The question was in terms of specification by administrative fiat after boot time. With a cron job, I can change the file and reset cron. With an at job, I am pretty much screwed. The cron data files suffer from the same failings as the mondo-data-file correspondance ambiguities: how do I correlate lines with administrative actions on a package basis? The problem is that the n:m mapping goes to hell rather quickly when it becomes n:m:l mapping. 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 Sep 25 11:52:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19289 for hackers-outgoing; Mon, 25 Sep 1995 11:52:10 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA19284 for ; Mon, 25 Sep 1995 11:52:00 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05564; Mon, 25 Sep 1995 11:47:11 -0700 From: Terry Lambert Message-Id: <199509251847.LAA05564@phaeton.artisoft.com> Subject: Re: ports startup scripts To: patl@asimov.volant.org Date: Mon, 25 Sep 1995 11:47:11 -0700 (MST) Cc: jmb@kryten.atinc.com, terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, peter@taronga.com In-Reply-To: from "patl@asimov.volant.org" at Sep 25, 95 08:53:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5794 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Ah, but can you guarantee that the install script that inserts a > > few new lines is putting them in the right place? > > Can you guarantee that the install script is going to get the numbering > right if we go with implicit order based upon script name? Yes, actually. By using a sparse numeric order designator at the front of the name to enforce ordering by strict lexical (numeric) order. Like numbering your lines by 10 or 100 in a BASIC program. > Or worse, is every install going to check to make sure that no other > scripts exists which use that order number? No. Because the number is not the only designator. By definition, collisions in order designation are "don't care". This is because if one package depended on another having been run first, the dependency would show as an order designator that was lexically prior to the order designator selected for the dependant package. By definition, a dependant package must have the package it depends on (and thus its write must be aware of the depended packages order of initialization). > Or renumber all the other scripts if they do? Never necessary. As I said, a don't care state. > Or come with a list of numbers to choose from? If a dependency graph were needed, then "depends on " and the installation log would have to be consulted. Personally, I think this is unnecessary because of the aformentioned collision/don't-care relationship. > I think these are a LOT more dangerous. File order is explicit and simple. > Anything else is headaches. You are not expected to manually edit the data. If you want to, fine: you deserve headaches. The point is to make it easy for the tools, not easy for a human that wants to much about in things that should be done via tool in the first place. > > Could this be changed to 'add a file to the scheduled jobs directory', > > to avoid the need to automatically edit a file? > > If you want, put it as "mumble.daily" in /etc/bin and it will be run > automatically. I have a problem with this. My problem is that I want finer control over the granularity as part of the administrative range granted me by the configuration control file I expect to install to allow me to administrate the package as a unified system component in my standard system administration utility. > Yes, this relies upon implicit order (whatever "find" returns), which I > really don't like. But I couldn't see any other option, and if you > were hand-adding scripts you could bloody well get the order right yourself > DESIGNING a system around implicit order I consider reckless. I agree. The explicit ordering required in a lexically ordered system is fairly simple: pick a number after the number of the packages you depend on, but low enough that other packages may depend on you without overflowing the lexical name space. I'd suggest 3 digits rather than 2 as a guard against overflow, though I expect the lead digit to remain 0 for a long time (if not forever). > And yes, I know that SysV does it, and that is works fine for whoever. > I don't like SysV. Specifically, I don't like this "feature" of SysV. > That's what I run a BSD variant. The feature we are considering is the ability to drop in add on components as if they were system components and provide a unified administrative interface for their control. Currently, we don't have *any* administrative interface (except perhaps 'vi') precisely because there is no unified view of the system which one could import. It's possible to write one, but it'd be a kludge, and we all know it. > It boils down to that. A few other people have said it, and I'll say it too. > I don't want FreeBSD to become a SysV-clone. That's what Linux is for. Neither do I. But don't condemn the idea because of the messenger. A valid idea is a valid idea no matter where it comes from (I feel like I'm teaching phenomenology to bomb #28 8-)). > If people want changes to the startup mechanism, to incorporate the best > concepts from SysV, that's fine. It's call improving. The best concept they had was the ability to component administrative portions of package data so it looked like the package was a part of the OS, even if it came from a third party. The second best concept they had was run levels/states to allow staged "run-up" and "run-down". > But throwing out the entire "rc" script concept, and going with (pick an > implemention, any mutant implementation) SysV-clone I consider bad. What '"rc" script concept"? There's one script, init runs it, and if you don't like the system state after that, tough. Hardly a paradigm. > It also comes down to implementation and support. I'll gladly volunteer > to write and support the version I'm pushing for, and do whatever > the improvements to that base design that people want. > > Will you volunteer the same for your version? Including a re-write of the > "daily/weekly" stuff that reallly should use the same mechanism? I'll volunteer for the administrative utility *if* a unified view is presented. If you think you can present a unified view of all system components without seperate scripts, fine, I'd like to see a set of libraries for dealing with components. I already have a GUI library that will put out the right thing from the same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and OpenLook, dependent on shared library path (UNIX versions, of course). I'll give out the termcap/X/Motif libraries. Though I'd prefer a GUI based Drag-N-Drop interface, like the Mac System folder concept, I'm willing to throw the (IMO) less powerful paradigm out the door to get something started. 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 Sep 25 12:07:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19499 for hackers-outgoing; Mon, 25 Sep 1995 12:07:45 -0700 Received: from casparc.ppp.net (casparc.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA19494 for ; Mon, 25 Sep 1995 12:07:37 -0700 Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0sxImx-000I0GC; Mon, 25 Sep 95 20:02 MET Received: by ernie.altona.hamburg.com (Smail3.1.29.1 #3) id m0sxHxl-000013C; Mon, 25 Sep 95 19:09 MET Message-Id: From: hm@altona.hamburg.com (Hellmuth Michaelis) Subject: LKM example device driver available To: freebsd-hackers@freebsd.org Date: Mon, 25 Sep 1995 19:09:09 +0100 (MET) Reply-To: hm@altona.hamburg.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 611 Sender: owner-hackers@freebsd.org Precedence: bulk Since i could not find any examples of a LKM device driver i wrote one myself. It is a very basic one, it just controls two 7segment displays connected to a 8255 parallel port (no interrupts), commented and with a postinstall script to make device files. I think it would be a good thing to put it into /usr/src/share/examples/lkm. It is available from wcarchive.cdrom.com in directory pub/FreeBSD/incoming as led-lkm-driver.tar.gz. hellmuth -- Hellmuth Michaelis hm@altona.hamburg.com Hamburg, Europe (A)bort, (R)etry, (I)nstall BSD ? From owner-freebsd-hackers Mon Sep 25 12:16:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19731 for hackers-outgoing; Mon, 25 Sep 1995 12:16:37 -0700 Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19726 for ; Mon, 25 Sep 1995 12:16:35 -0700 Received: from ugen (ugen-tr.worldbank.org [138.220.101.58]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id PAA17478; for ; Mon, 25 Sep 1995 15:15:07 -0400 Date: Mon, 25 Sep 95 15:13:29 PDT From: "Ugen J.S.Antsilevich" Subject: Re: Unusual networking question from the net.. To: "Jordan K. Hubbard" , Terry Lambert Cc: hackers@FreeBSD.ORG X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >My guess is that because they are selling as a net server, they have >raised the priority of SPLNET to the detriment of other drivers. Hmm..could we do the same as an option to kernel, so that ppl who want to have internet servers would be able to get more efficient processing?:) --Ugen From owner-freebsd-hackers Mon Sep 25 12:36:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA20183 for hackers-outgoing; Mon, 25 Sep 1995 12:36:46 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id MAA20167 for ; Mon, 25 Sep 1995 12:35:05 -0700 Received: by sequent.kiae.su id AA25947 (5.65.kiae-2 ); Mon, 25 Sep 1995 23:25:27 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 25 Sep 95 23:25:25 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id WAA01702; Mon, 25 Sep 1995 22:07:20 +0300 To: Coranth Gryphon , guido@gvr.win.tue.nl, julian@ref.tfs.com Cc: bugs@ns1.win.net, hackers@FreeBSD.ORG, taob@io.org References: <199509251447.KAA12188@healer.com> In-Reply-To: <199509251447.KAA12188@healer.com>; from Coranth Gryphon at Mon, 25 Sep 1995 10:47:24 -0400 Message-Id: Organization: Olahm Ha-Yetzirah Date: Mon, 25 Sep 1995 22:07:20 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: Guido's pwd_mkdb improvements (fwd) Lines: 20 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 961 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199509251447.KAA12188@healer.com> Coranth Gryphon writes: >From: Julian Elischer >> you can sort the passwd on uid and name before editing it, do the same >> afterwards, get a diff, change those records and then store the version >> of the passwd file the user saved (user selected order) >There is one thing that this might break (I'm not sure, but lest ye forget). >I often use the "multiple names/passwords, single uid" system. >And since the first encountered name with that uid is considered "canonical", >might an alphabetic sorting not screw things up? Yes. It screws up things. Passwd automatic sorting IS NOT ALLOWED! -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Mon Sep 25 13:16:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20691 for hackers-outgoing; Mon, 25 Sep 1995 13:16:53 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA20684 for ; Mon, 25 Sep 1995 13:16:32 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id NAA03384; Mon, 25 Sep 1995 13:15:00 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29198; Mon, 25 Sep 1995 13:20:30 -0700 Date: Mon, 25 Sep 1995 13:20:30 -0700 Message-Id: <9509252020.AA29198@asimov.volant.org> To: jmb@kryten.atinc.com, peter@taronga.com, gryphon@healer.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > > solves the rename problem. not the 'is it the same of is it not, |> > > i have to did deeper' problem. |> > |> > Sure. If you do it right you just need to make sure it's a symlink. |> |> From: "Jonathan M. Bresler" |> > urg....symlink. two files. requires diff or ls -F to determine |> |> Agreed. I've said it before - symlink are only useful if you |> (for some reason) can't put something where it belongs, of if |> it really needs to be in two places at one: the latter translates |> as "cannot be easily gotten at in the proper place" or "a non-optimal |> location is hard-coded in something". |> |> There is no need to two sets of directorys off of /etc with |> the contents of one being linked to the other. You are right - it isn't NECESSARY. But it is convienient. Because if you have a separate directory for -all- startup scripts, you don't need to remember which run states or sequence numbers they have when invoking them by hand. This is particularly useful if you have any services which are not (yet) automatically invoked at startup time. It is also very helpful if you consider the different runlevels to be independant states, not a monotically increasing set of levels. And hard links are even more useful than symlinks. With hard links, you can easily determine how many states are using a given script simply by checking the number of links to the master copy. |> > one directory for all run-states?? or one directory for each. i |> > am advocating one directory for all start, kill and restart scripts. |> |> I still prefer run-levels (as opposed to states), but I'd still |> rather see one directory per state than anything else. Right. One directory per state, and one directory for the cannonical location of the scripts. |> > for instance: (concept, not correct implementation) |> |> > multi_user = "syslog cron" |> > network = "syslog cron_net ifconfig named" |> |> Yep. That works. The only problem is shutting things down, if you |> are not simple shutting everything down. You need to document both what each state is ('single user', 'multi user, no network', 'multi-user, network clients only', etc.); and the sequence points within each level (from Solaris2.4 rc2.d/README): After the S20 scripts have executed, local file systems are mounted and temporary directories have been cleaned as appropriate. After the S80 scripts have executed, the machine is a fully configured NFS client. NFS file systems have been mounted. The name service (if any) is running. syslogd and cron are running. This documentation should be in README files in each rc?.d directory. |> Actually, at that point you'd need a matrix of what to stop and start |> depending upon what run-state you are going from and to. |> |> All the more reason to go with linear run-levels. Not really - a stateX-to-stateY transition could be done by shutting down stateX completely and then starting stateY from scratch. This also avoids the crossbar problem. My problem with run levels is that if I want a state which does not correspond to any of the standard levels, it will probably need to go inbetween two of the standard ones. (E.g. multi-user, with full networking on the LAN, but no outside connection) If it is done as levels, I'd have to re-number the levels to insert my new state. If I then try to install a package that adds a startup script to that state... Also, I can easily conceive of desirable site-specific states where neither is a subset of the other. If the implementation supports states, it is easy to use it to provide levels. (In each state, have S00. simply invoke ../rc[state-1]. [*]) If it only supports levels, using it to get distinct states is going to be pretty tough. [*] In practice, we'd want to be able to determine the current state and only invoke the state startup scripts for level above the currently active one. All this reversed for reducing level, of course. |> > now i know that both use the same syslog start script |> > and that they start cron differently. |> > the order is explicit, not implicit ascii sort order |> |> Yep. Alternately, the "cron" script can take an argument of "multi-user" |> or "network" and do the right thing. Cron shouldn't need to know. And doing that limits the possible cron actions choosable from the different states. |> in summary, my druthers are: |> > one directory for all start and stop scripts |> > explicit invocation order, a list |> > one name per script regardless of run-state/level |> > (no links hard or soft) |> |> Yep. I'll buy that for a dollar. I won't. My druthers are: One master directory for start/stop/restart scripts. One directory per run state, with hardlinks to above. Invocation order dictated by digits in script name. |> > explicit names: Snamed (start.named, whatever) |> |> Or two optional arguments to each script: the name of the run-state |> or number of the run-level and "start"/"stop"/"restart". Even clearer. Script names in init.d should simply name the service ('named'). Script names in rc?.d have 'S' or 'K' and a two (or three) digit number prepended to dictate order and action. ('S*' are invoked when entering the state, 'K*' when exiting it.) |> > that both use a master file. one exists as a file, the other |> > exists as an artifact of ascii sort order (not obvious to our poor |> > newbie, especially when we have to explain that 10 comes before 2). a |> > list of tasks/scripts is clearer to our newbie and easier for everyone else. |> |> A master file, which generates a set of run-state script. The program |> which generates the "rc.N" scripts (N being run-state #) check for |> consistency (ie major screw-ups, possibly even dependencies) before |> replacing the older "rc.N" file. All the scripts reside in /etc/init.d |> and take a single argument of "start", "stop", or "restart". --- NO SCRIPT EDITING !!! ---- I cannot possibly overemphasize the advantages of a system which avoids the need to ever automatically edit any file. This avoidance is the single biggest advantage of the SVr4 model. If all of our scripts have the same number of digits, there won't be a '2' to come after '10'. It will be '02'. Just for emphasis, we can mention that fine point of lexical ordering in the man page and per-rc-dir README files. Anybody who is still caught by it after that needs the object lesson they will get in tracking down the problem. (And should probably consider a career which doesn't involve any system administration.) |> Very similar to what is now being done for "daily"/"weekly". |> Which I've already done, so could do this one just as easily. Personally, I think the daily/weekly cron jobs should also have directories of sub-scripts, invoked in lexical order. -Pat From owner-freebsd-hackers Mon Sep 25 13:54:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21630 for hackers-outgoing; Mon, 25 Sep 1995 13:54:22 -0700 Received: (from pds@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA21624 for hackers@freebsd.org; Mon, 25 Sep 1995 13:54:21 -0700 Date: Mon, 25 Sep 1995 13:54:21 -0700 From: Peter da Silva Message-Id: <199509252054.NAA21624@freefall.freebsd.org> To: hackers@freebsd.org Subject: Problems with packages, and general third party software. Sender: owner-hackers@freebsd.org Precedence: bulk One problem with installing things from packages is you don't get any convenient pointer to how to configure them. For example, if I hadn't already installed amanda on our system, I'd have no idea what to put in /etc/inetd.conf and /etc/services. Looking through what the package installs there's really not enough to install it. You really have to at least unpack the amanda port to complete installation. (or have a working amanda installation...) I'm thinking... as well as the /etc/rc*.d stuff, we need to look at how to mechanise standard crontab and inetd.conf and services entries. amanda 10080/udp amanda dgram udp wait operator /usr/local/libexec/amanda/amandad amandad And you have to add "operator" to the operator group in /etc/group. I don't think we want pkg_add doing this either. From owner-freebsd-hackers Mon Sep 25 14:00:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA21878 for hackers-outgoing; Mon, 25 Sep 1995 14:00:43 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA21847 for ; Mon, 25 Sep 1995 14:00:11 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id QAA13268; Mon, 25 Sep 1995 16:58:08 -0400 Date: Mon, 25 Sep 1995 16:58:08 -0400 From: Coranth Gryphon Message-Id: <199509252058.QAA13268@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > > > It may also need to add a cron job to rotate the damons logs. > > > > rotate_log daily /some/log/file > What if I want to rotate them twice a week instead of daily? > What about twice a day? We don't have that granularity for anything else right now. If you wanted something with a different resolution, you couldn't do it with the daily/weekly stuff anyway. You could always make a cron job that did it, but the only way to do it is (A) edit crontab by hand or (B) have the install edit the crontab. Either way, it's just as complicated, and I only offered the simple solution that tacked onto the existing mechanism. You can always come up with a special case. But nobody has proposed a means for dealing with every special case. Just for the standard ones. > > > Ordering guarantees within a single run level/state are hard to provide > > > with the single monolithic file model. > > > Actually, a single file is the easiest to control ordering in. > > Last I checked, line 1 always came before line 2. :-) > The problem is that the line starts are not a fixed locations and are > therefore variant without whole file locking. Which is bad. So the whole file gets locked. I really can't see the case of multiple parallel package installs happening ** and hitting the "add one line to a file" step ** at the same time that frequently. > > > Finally, what if I don't want to delete the package, I just want to > > > disable it? How to I prevent the package daemon's and cron jobs from > > > > Comment out the line in the control file? > 1) How do I tell which line(s) correspond to which package? Whatever added the line better know which it is :-) If the package added it, and it's removing it, we're fine. If you added it by hand, then you can remove it just as easily. If you used an admin tool (gui-ish thing or shell script) to add it, then it can keep track of the name of the script. If the package added it but cannot delete it itself, then (1) it should have a coherent name (which makes the process trivial) or (2) you might have to grep (in the single directory) through the scripts to find out which line to comment out. > 2) How do I reenable it? Uncomment it? > 3) How do I do this from an administrative utility instead of > having to actually know what's what myself? All these default to #1. The admin tool can always refer to scripts by name if it doesn't know anything else about it (that is, if you think "apache.httpd" is much less informative than "Apache Web Server"). We're making the blatant assumption that the sys-admin doing the removing knows what they want to remove. Unless you want the admin tool itself making the decision of WHAT to remove. Sorry, the AI interface is not showing up until FreeBSD 3.0 :-) > > > Typically, I'd put the "cron" jobs as at commands in the startup script, > > > > As above, given that you have the granularity of "daily", "weekly", or > > "monthly". I suppose we could always add "bi-weekly" and "bi-monthy" :-/ > The question was in terms of specification by administrative fiat after > boot time. With a cron job, I can change the file and reset cron. With > an at job, I am pretty much screwed. OK, sorry. I missed the word "at" in the original comment by whoever. My point was again, if you wanted to use the normal scheduled-job mechanism (daily/weekly/monthly) you were limited to that granularity. If you want other frequencies, your options are either (1) do it not using that mechanism, or (2) enchance that mechanism to add other times. > The cron data files suffer from the same failings as the mondo-data-file > correspondance ambiguities: how do I correlate lines with administrative > actions on a package basis? Same answer. We name the job based upon (not the same as) the init script name. For example, the script name is "mumbled" (to start the "mumble" daemon). The daily job entry in the schedule file would be "DO_mumble") or you could create a seperate script called "mumble.daily". Or you do things by hand in cron, and deal with things by hand, since the script is refusing to conform to standard frequencies (every 2.5 days) or needs to do someting else weird (package named mumble cannot have a crontab entry with that word in it). Or don't use cron. > The problem is that the n:m mapping goes to hell rather quickly when it > becomes n:m:l mapping. Granted. If the names are different. So we come up with a standard. "mumble" is the init script. "DO_mumble" is the daily job entry. "mumble.weekly" is the additional script to be run weekly. If we are standardizing the process, then either (1) ports and packages conform to the standard (which we can control for those distributed as part of FreeBSD) or (2) they do not, in which case we document the simple process and fall back on the "If you are hand-installing ports, then you better either not be a newbie or better be able to follow directions". -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 14:09:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA22295 for hackers-outgoing; Mon, 25 Sep 1995 14:09:21 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA22289 for ; Mon, 25 Sep 1995 14:09:12 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id RAA26419; Mon, 25 Sep 1995 17:07:31 -0400 Date: Mon, 25 Sep 1995 17:07:30 -0400 (EDT) From: Brian Tao To: Matt Thomas cc: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <199509251014.KAA06744@whydos.lkg.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Mon, 25 Sep 1995, Matt Thomas wrote: > > However BSD/OS 2.0 doesn't have dlopen or dlsym either. I guess Netscape will just have to develop it on the FreeBSD platform then. ;-) -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Mon Sep 25 14:27:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA22745 for hackers-outgoing; Mon, 25 Sep 1995 14:27:30 -0700 Received: from trepan.io.org (root@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA22735 for ; Mon, 25 Sep 1995 14:27:18 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id RAA26620; Mon, 25 Sep 1995 17:11:12 -0400 Date: Mon, 25 Sep 1995 17:11:12 -0400 (EDT) From: Brian Tao To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <2696.811985950@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 24 Sep 1995, Jordan K. Hubbard wrote: > > I do, but it's a cast-iron &*^%$#@!! BSDI apparently changed crt0.o > fairly substantially but not the magic number. Now explain to me how > we're supposed to tell the difference and be selectively compatible? :-( Well, how does BSD/OS 2.0 stay compatible with its own 1.1 binaries? -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Mon Sep 25 14:44:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23333 for hackers-outgoing; Mon, 25 Sep 1995 14:44:55 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA23327 for ; Mon, 25 Sep 1995 14:44:49 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA29349; Mon, 25 Sep 95 21:43:22 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA11504; Mon, 25 Sep 1995 15:43:15 -0600 Date: Mon, 25 Sep 1995 15:43:15 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509252143.AA11504@emu.fsl.noaa.gov> To: gryphon@healer.com, freebsd-hackers@freebsd.org, freebsd-ports@freebs.org Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk "Coranth" == Coranth Gryphon writes: Coranth> But throwing out the entire "rc" script concept, and Coranth> going with (pick an implemention, any mutant Coranth> implementation) SysV-clone I consider bad. Agreed. So what we *really* DON'T need is an all-singing, all-dancing automatic startup/shutdown configuration manager with cycle detection and autoremoval that ports, packages, and anyone else can use, along with a WWW based browser/editor so even someone with less computer experience that one could possibly gain on a Mac can jump right in and with a few drags of the mouse, make one's in.gaflorkd to start up before /usr/libexec/rpc.rfribbitzd. Or, perhaps I should say ... It's NOT THAT HARD to use your own built-in pattern recognition software and hand-configure /etc/rc.local. Often times, the software configuration issue is so complex, what with commercial vendors who won't give you the time of day (much less answer the phone) to poorly assembled freeware, that there's really no better expedient than to read a few convoluted READMEs or what-have-you and fire up (all at the same time now) ``your favorite text editor.'' Remember Jordan's words: we lost the desktop market, and that seems to be the primary target of all this proposed reconfiguration. People using are systems will have enough gray matter to know what to do when they see: % make install Installing fizzlefrazzle-1.2 install -c -o bin -g bin -m 555 fizzd /usr/local/libexec install -c -o bin -g bin -m 555 fizzclean /usr/local/libexec install -c -o bin -g bin -m 555 fizzle /usr/local/bin Installation complete. Now, edit your /etc/rc.local file and add a line to start fizzd. Also, add fizzclean to root's cron, set to run every half hour, more if you think you need it. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA A power surge on the Bridge is fails to electrocute the user of a computer panel, due to a highly sophisticated 24th century surge protection feature called a 'fuse'. -- One of 46 things that never happen on Star Trek From owner-freebsd-hackers Mon Sep 25 14:56:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23634 for hackers-outgoing; Mon, 25 Sep 1995 14:56:47 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23626 for ; Mon, 25 Sep 1995 14:56:21 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA13441; Mon, 25 Sep 1995 17:52:42 -0400 Date: Mon, 25 Sep 1995 17:52:42 -0400 From: Coranth Gryphon Message-Id: <199509252152.RAA13441@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: patl@asimov.volant.org > And hard links are even more useful than symlinks. With hard links, > you can easily determine how many states are using a given script > simply by checking the number of links to the master copy. ... > Right. One directory per state, and one directory for the cannonical > location of the scripts. Same problem. I've just seen two many times when keeping multiple copies of something has led to problems. |> Yep. That works. The only problem is shutting things down, if you |> are not simple shutting everything down. > |> Actually, at that point you'd need a matrix of what to stop and start > |> depending upon what run-state you are going from and to. > |> > |> All the more reason to go with linear run-levels. > Not really - a stateX-to-stateY transition could be done by shutting > down stateX completely and then starting stateY from scratch. Yeah, thought of that. Was trying to avoid it to maintain continuity between daemons. > My problem with run levels is that if I want a state which does not > correspond to any of the standard levels, it will probably need to > go inbetween two of the standard ones. (E.g. multi-user, with full Same problem occurs with states - you have to pick the one closest to what you want and > as levels, I'd have to re-number the levels to insert my new state. Granted, that is a problem. We could solve most of it by allocating a half-way state that is unused at each point a "local". > If the implementation supports states, it is easy to provide levels. > If it only supports levels, using it to get distinct states is going > to be pretty tough. Yep, you're right. That's the biggest drawback of levels. It quickly becomes a matter of - how much flexibility is really going to be used how often. If it's twice the work for twice the functionality, it's worth it. If it's twice the work to make +5% people happy, then it's questionable. If twice the work makes ten people happy, then it's not. > |> Yep. Alternately, the "cron" script can take an argument of "multi-user" > |> or "network" and do the right thing. > Cron shouldn't need to know. And doing that limits the possible cron > actions choosable from the different states. Cron doesn't know. The script that runs starts/runs/creates/whatever the crontab entry knows. |> in summary, my druthers are: |> > one directory for all start and stop scripts |> > explicit invocation order, a list |> > one name per script regardless of run-state/level |> > (no links hard or soft) |> > One master directory for start/stop/restart scripts. > One directory per run state, with hardlinks to above. > Invocation order dictated by digits in script name. As I said in my response to Terry, it quickly becomes religious discussion of which is better, numbered scripts or control files. > --- NO SCRIPT EDITING !!! ---- We are not talking about script editing. We are talking about adding a line to a control file, versus adding a line to a directory. > I cannot possibly overemphasize the advantages of a system which > avoids the need to ever automatically edit any file. This avoidance > is the single biggest advantage of the SVr4 model. And one of it's single biggest confusions. I prefer BSD variants over SysV variants BECAUSE of design decisions like this. A lot of other people probably do as well. If you want SysV, use Linux. If you want FreeBSD to get some new flexibility (based upon concepts from anywhere else) - GREAT. But don't say "SysV is doing it so we should"! At this point, we have two distinct camps - those who want to see the {S|K}NNfoo scripts in "rc?.d" with a copy in "init.d" subdir. In other words "SysV". And those of us who want one directory ("init.d") and a control file to specify what gets run when. In other words, a hybrid. Neither camp is going to convince the other. So someone who can make the decision of which direction to head in should do so, and let us get down to doing the best implementation of whichever that we can, rather than debating it for another three months, and then kludging something together in a hurry. Or, if we want to put a little more work in, we can do both and make everyone happy. We have to define the commonalities (one script per subsys/package/component, a copy in "init.d") and a fixed interface so that the two different startup "descriptions" can both use the underlying mechanism. What this means is that both camps will write versions, and make sure they work together. But we'll end up with something that is simply fantastic, and will suit both styles. If we go with control files, or with the do-it-both-ways system, count me in as willing to do a large chunk of it. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 15:01:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA23913 for hackers-outgoing; Mon, 25 Sep 1995 15:01:58 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA23888 for ; Mon, 25 Sep 1995 15:01:32 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA13404; Mon, 25 Sep 1995 17:27:36 -0400 Date: Mon, 25 Sep 1995 17:27:36 -0400 From: Coranth Gryphon Message-Id: <199509252127.RAA13404@healer.com> To: patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert >>> Ah, but can you guarantee that the install script that inserts a >>> few new lines is putting them in the right place? > >+> Can you guarantee that the install script is going to get the numbering >+> right if we go with implicit order based upon script name? > Yes, actually. By using a sparse numeric order designator at the front > of the name to enforce ordering by strict lexical (numeric) order. Like > numbering your lines by 10 or 100 in a BASIC program. Like it adds to the end of the file. Or adds to the first (or fourth or ...) line after its dependancy. > +> Or worse, is every install going to check to make sure that no other > +> scripts exists which use that order number? > No. Because the number is not the only designator. By definition, > collisions in order designation are "don't care". This is because if Again, you can always append to the file if it is a "don't care", unless we are allowing additions that MUST come before other things that already exist in the startup sequence. I can think of it happening, though I'd like to see ANY automated sequence deal gracefully with it. And if it does, the same logic can be applied to the file edit. It really boils down to perference of style, and... > +> I think these are a LOT more dangerous. File order is explicit and simple. > +> Anything else is headaches. > You are not expected to manually edit the data. If you want to, fine: > you deserve headaches. The point is to make it easy for the tools, not It always comes down to a person trying to figure it out when something is wrong. I'd rather spend a little more time making the tools smarter, so that a person has an easier time of it, than making the tools stupid, and hoping the person is smart enought to work around that. That's the whole point of everything we're doing. Give the average person on the street a system that they can understand and maintain. Personally, I'd rather me (the designer/programmer) spend the time to make their lives easier, since that generates a larger customer/user base. Make things so that only long-time sys-admins with a serious understanding of OS concepts can debug this, and such free OS's will die. > +> If you want, put it as "mumble.daily" in /etc/bin and it will be run > +> automatically. > I have a problem with this. My problem is that I want finer control > over the granularity as part of the administrative range granted me There is no mechanism for doing this now. Either modify the current one with a few additional granularity levels, or let people do it by hand (which they have to do now anyway). I really can't see that there will be that many things that cannot conform into the "hourly, daily, weekly, monthly" framework we are currently using. > +> Yes, this relies upon implicit order (whatever "find" returns), which I > +> really don't like. But I couldn't see any other option, and if you > fairly simple: pick a number after the number of the packages you depend > on, but low enough that other packages may depend on you without overflowing > the lexical name space. I'd suggest 3 digits rather than 2 as a guard Or use file order, in which case your numbering limit is maximum number of lines in the file. Again, it quickly becomes a religious battle of which people prefer - numbered scripts or a control file. Personally, I like the control file. I can print it out, and know exactly what will run in what order. You like numbered scripts, you can print out a directory listing, and know exactly what will run in what order. Functionally, they are the same. Issues for the automation are similar in most cases (getting the ordering right, dependancies, collisions). You way requires sym-linked sub-dirs to control the order, mine still holds to the same master file. The danger of mine is that packages need to modify the master file, the danger of yours is that packages need to make sure they put the right files and links in the right places. > The feature we are considering is the ability to drop in add on components > as if they were system components and provide a unified administrative ... > It's possible to write one, but it'd be a kludge, and we all know it. We're in agreement here. It's just a matter of seeing different ways to implement similar concepts (gee, programmers never suffer this problem do they :-) > valid idea is a valid idea no matter where it comes from (I feel like Granted. A hundered times over :-) > The second best concept [SysV] had was run levels/states to allow staged > "run-up" and "run-down". I still like linear run-levels, rather than arbitrary states (and think the former would be a LOT easier to implement). > If you think you can present a unified view of all system > components without seperate scripts, fine, I'd like to see a set of > libraries for dealing with components. Is this a tangent, or missed interpretation? I have always been in favor of seperate scripts for each sub-system/component/package. I just want to put them in one place and have them run from a master file, rather than sym-links to state-based subdirectories. And yes, I'd be very happy a combined mechanism that includes startup of the various levels, plus the regularly scheduled daily/weekly stuff. > I already have a GUI library that will put out the right thing from the > same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and Great. Given a simple GUI library, I'll even do the GUI's for both parts. > I'll give out the termcap/X/Motif libraries. Though I'd prefer a GUI > based Drag-N-Drop interface, like the Mac System folder concept, I'm > willing to throw the (IMO) less powerful paradigm out the door to get Drag-and-Drop I really think would be frosting. If you have the libraries for the standard GUI cake, let's go with what we have. We can always do a different GUI later. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 15:24:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA24819 for hackers-outgoing; Mon, 25 Sep 1995 15:24:32 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA24796 for ; Mon, 25 Sep 1995 15:24:24 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id SAA00606; Mon, 25 Sep 1995 18:31:55 -0400 Date: Mon, 25 Sep 1995 18:31:55 -0400 Message-Id: <199509252231.SAA00606@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: inet-access@earth.com From: dennis@etinc.com (dennis) Subject: Big Net Frame Relay for BSD Unix Cc: bsdi-users@bsdi.com, hackers@freebsd.org, frame-relay@indiana.edu Sender: owner-hackers@freebsd.org Precedence: bulk Emerging Technologies, Inc. today announces a new release of frame relay software for BSD/OS and FreeBSD operating systems. The new release implements a dynamic sub-interface technique that substantially increases the flexibility of the frame relay subsystem. The new release allows for the proper modeling of large scale networks with multiple logical networks per physical line, simplifying multi-homing and multiple default scenarios and the mixing of point-to-point and multi-point (meshed) networking models. Most importantly, the new sub-interface system provides the necessary interface for implementing complex routing protocols like BGP4 and OSPF with GateD on frame relay networks. On-line information is available at www.etinc.com/bsddata.htm Emerging Technologies, Inc. ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Mon Sep 25 15:34:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26113 for hackers-outgoing; Mon, 25 Sep 1995 15:34:38 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA26104 for ; Mon, 25 Sep 1995 15:34:33 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA05992; Mon, 25 Sep 1995 15:29:53 -0700 From: Terry Lambert Message-Id: <199509252229.PAA05992@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 15:29:52 -0700 (MST) Cc: patl@asimov.volant.org, terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <199509252127.RAA13404@healer.com> from "Coranth Gryphon" at Sep 25, 95 05:27:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3072 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > +> Yes, this relies upon implicit order (whatever "find" returns), which I > > +> really don't like. But I couldn't see any other option, and if you > > > fairly simple: pick a number after the number of the packages you depend > > on, but low enough that other packages may depend on you without overflowing > > the lexical name space. I'd suggest 3 digits rather than 2 as a guard > > Or use file order, in which case your numbering limit is maximum number > of lines in the file. Again, it quickly becomes a religious battle of > which people prefer - numbered scripts or a control file. > > Personally, I like the control file. I can print it out, and know > exactly what will run in what order. > > You like numbered scripts, you can print out a directory listing, > and know exactly what will run in what order. > > Functionally, they are the same. Issues for the automation are similar > in most cases (getting the ordering right, dependancies, collisions). Functionally, I can union mount my script directory over a read-only template directory to add my local scripts. How do I union two files? > You way requires sym-linked sub-dirs to control the order, mine still > holds to the same master file. The danger of mine is that packages > need to modify the master file, the danger of yours is that packages > need to make sure they put the right files and links in the right places. Creation is arbitrated at the directory entry level in the FS code itself. > > If you think you can present a unified view of all system > > components without seperate scripts, fine, I'd like to see a set of > > libraries for dealing with components. > > Is this a tangent, or missed interpretation? I have always been in favor > of seperate scripts for each sub-system/component/package. I just want > to put them in one place and have them run from a master file, rather > than sym-links to state-based subdirectories. this still doesn't handle the "union of several directories" problem, even if the contents are simply a file, if order of operation is based on file order. > And yes, I'd be very happy a combined mechanism that includes startup of > the various levels, plus the regularly scheduled daily/weekly stuff. > > > I already have a GUI library that will put out the right thing from the > > same program on DOS, Windows, Mac, UNIX Text, Vanilla X, Motif, and > > Great. Given a simple GUI library, I'll even do the GUI's for both parts. > > > I'll give out the termcap/X/Motif libraries. Though I'd prefer a GUI > > based Drag-N-Drop interface, like the Mac System folder concept, I'm > > willing to throw the (IMO) less powerful paradigm out the door to get > > Drag-and-Drop I really think would be frosting. If you have the > libraries for the standard GUI cake, let's go with what we have. > > We can always do a different GUI later. I will get the GUI stuff together for public use by November. 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 Sep 25 15:38:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26283 for hackers-outgoing; Mon, 25 Sep 1995 15:38:33 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA26269 for ; Mon, 25 Sep 1995 15:38:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA06011; Mon, 25 Sep 1995 15:34:10 -0700 From: Terry Lambert Message-Id: <199509252234.PAA06011@phaeton.artisoft.com> Subject: Re: ports startup scripts To: kelly@fsl.noaa.gov (Sean Kelly) Date: Mon, 25 Sep 1995 15:34:10 -0700 (MST) Cc: gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org In-Reply-To: <9509252143.AA11504@emu.fsl.noaa.gov> from "Sean Kelly" at Sep 25, 95 03:43:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1376 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > It's NOT THAT HARD to use your own built-in pattern recognition > software and hand-configure /etc/rc.local. Unless /etc is read-only and the only method you have to add your own stuff is union mounts (additional directory entries). > Remember Jordan's words: we lost the desktop market, and that seems to > be the primary target of all this proposed reconfiguration. People > using are systems will have enough gray matter to know what to do when > they see: Jordan is wrong. I was in the meeting in the conference room in Sandy, Utah when Kanwahl Rheki "gave way" the UNIX destop. The UNIX desktop was not "lost", it was "conceded without a fight". I don't agree that it was "lost". > % make install > Installing fizzlefrazzle-1.2 > install -c -o bin -g bin -m 555 fizzd /usr/local/libexec > install -c -o bin -g bin -m 555 fizzclean /usr/local/libexec > install -c -o bin -g bin -m 555 fizzle /usr/local/bin > > Installation complete. Now, edit your /etc/rc.local file > and add a line to start fizzd. Also, add fizzclean to root's > cron, set to run every half hour, more if you think you need > it. If /etc is read-only, well, then you're SOL. 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 Sep 25 15:46:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA27484 for hackers-outgoing; Mon, 25 Sep 1995 15:46:22 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA27443 ; Mon, 25 Sep 1995 15:46:12 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA29897; Mon, 25 Sep 95 22:44:13 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA11640; Mon, 25 Sep 1995 16:44:08 -0600 Date: Mon, 25 Sep 1995 16:44:08 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509252244.AA11640@emu.fsl.noaa.gov> To: terry@lambert.org Cc: gryphon@healer.com, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org In-Reply-To: <199509252234.PAA06011@phaeton.artisoft.com> (message from Terry Lambert on Mon, 25 Sep 1995 15:34:10 -0700 (MST)) Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "Terry" == Terry Lambert writes: Terry> The UNIX desktop was not "lost", it was "conceded without a Terry> fight". Whatever. There's still probably going to be little return (in our project, I suppose that's measured by the size of the user base) on any investment put into completely automating package installation that requires system configuration. Terry> If /etc is read-only, well, then you're SOL. But the more experienced user who's given himself a read-only /etc should know what to do. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA TASK: Shoot yourself in the foot. In FORTH: Foot in yourself shoot. From owner-freebsd-hackers Mon Sep 25 15:50:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA27892 for hackers-outgoing; Mon, 25 Sep 1995 15:50:06 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA27887 ; Mon, 25 Sep 1995 15:50:04 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id PAA08301; Mon, 25 Sep 1995 15:49:57 -0700 From: Julian Elischer Message-Id: <199509252249.PAA08301@ref.tfs.com> Subject: Re: disk going bad? To: hsu@freefall.freebsd.org (Jeffrey Hsu) Date: Mon, 25 Sep 1995 15:49:56 -0700 (PDT) Cc: julian@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199509250650.XAA03637@freefall.freebsd.org> from "Jeffrey Hsu" at Sep 24, 95 11:50:11 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 426 Sender: owner-hackers@FreeBSD.org Precedence: bulk It only replaces it if it can recover the data.. try writing to that block.. then it should replace it.. > > Under 2.0.5, run the sample script in the scsi(8 or 1) man page > to turn on bad-block remapping > > I did this and found Auto Read Reallocation was already on. > > In theory, how is this supposed to work? If the drive replaces the > bad read block w/ a good block, how does the fs handle the lost > data? > From owner-freebsd-hackers Mon Sep 25 15:57:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA28353 for hackers-outgoing; Mon, 25 Sep 1995 15:57:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA28332 ; Mon, 25 Sep 1995 15:57:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA06113; Mon, 25 Sep 1995 15:51:22 -0700 From: Terry Lambert Message-Id: <199509252251.PAA06113@phaeton.artisoft.com> Subject: Re: ports startup scripts To: kelly@fsl.noaa.gov (Sean Kelly) Date: Mon, 25 Sep 1995 15:51:22 -0700 (MST) Cc: terry@lambert.org, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG In-Reply-To: <9509252244.AA11640@emu.fsl.noaa.gov> from "Sean Kelly" at Sep 25, 95 04:44:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 451 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Terry> If /etc is read-only, well, then you're SOL. > > But the more experienced user who's given himself a read-only /etc > should know what to do. But the more experienced user who's manually manipulating the startup and cron directories instead of using an administrative tool should know what to do. 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 Sep 25 16:06:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA28578 for hackers-outgoing; Mon, 25 Sep 1995 16:06:50 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA28573 for ; Mon, 25 Sep 1995 16:06:48 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id QAA08337; Mon, 25 Sep 1995 16:03:48 -0700 From: Julian Elischer Message-Id: <199509252303.QAA08337@ref.tfs.com> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 16:03:47 -0700 (PDT) Cc: guido@gvr.win.tue.nl, bugs@ns1.win.net, hackers@FreeBSD.ORG, taob@io.org In-Reply-To: <199509251447.KAA12188@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:47:24 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1111 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > From: Julian Elischer > > you can sort the passwd on uid and name before editing it, do the same > > afterwards, get a diff, change those records and then store the version > > of the passwd file the user saved (user selected order) > > There is one thing that this might break (I'm not sure, but lest ye forget). > > I often use the "multiple names/passwords, single uid" system. > And since the first encountered name with that uid is considered "canonical", > might an alphabetic sorting not screw things up? > > -coranth > that's why I said > > "store the version > > of the passwd file the user saved (user selected order)" the alphabetic sorting is just to find the diffs.. > > ------------------------------------------+------------------------+ > Coranth Gryphon | "Faith Manages." | > | - Satai Delenn | > Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ > USMail: 11 Carver St, Nashua, NH 03060 > Disclaimer: All these words are yours, except Europa... > > From owner-freebsd-hackers Mon Sep 25 16:07:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA28628 for hackers-outgoing; Mon, 25 Sep 1995 16:07:13 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA28617 ; Mon, 25 Sep 1995 16:07:07 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA12073; Mon, 25 Sep 1995 17:09:11 -0600 Date: Mon, 25 Sep 1995 17:09:11 -0600 From: Nate Williams Message-Id: <199509252309.RAA12073@rocky.sri.MT.net> To: Terry Lambert Cc: kelly@fsl.noaa.gov (Sean Kelly), freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: ports startup scripts In-Reply-To: <199509252251.PAA06113@phaeton.artisoft.com> References: <9509252244.AA11640@emu.fsl.noaa.gov> <199509252251.PAA06113@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert writes: > > Terry> If /etc is read-only, well, then you're SOL. > > > > But the more experienced user who's given himself a read-only /etc > > should know what to do. > > But the more experienced user who's manually manipulating the startup > and cron directories instead of using an administrative tool should > know what to do. No way, no how. I've been adminstering BSD systems for years and years, and I still have problems on SysV boxes trying to find things. Your way requires change (ie; more work), while Sean is arguing for the less work case. The average FreeBSD user won't gain anything with the change (asserting that the Desktop is lost), so why give ourselves more work being different just to be different? Nate From owner-freebsd-hackers Mon Sep 25 17:34:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA01871 for hackers-outgoing; Mon, 25 Sep 1995 17:34:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA01850 ; Mon, 25 Sep 1995 17:34:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA06329; Mon, 25 Sep 1995 17:31:20 -0700 From: Terry Lambert Message-Id: <199509260031.RAA06329@phaeton.artisoft.com> Subject: Re: ports startup scripts To: nate@rocky.sri.MT.net (Nate Williams) Date: Mon, 25 Sep 1995 17:31:20 -0700 (MST) Cc: terry@lambert.org, kelly@fsl.noaa.gov, freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG In-Reply-To: <199509252309.RAA12073@rocky.sri.MT.net> from "Nate Williams" at Sep 25, 95 05:09:11 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 541 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Your way requires change (ie; more work), while Sean is arguing for the > less work case. The average FreeBSD user won't gain anything with the > change (asserting that the Desktop is lost), so why give ourselves more > work being different just to be different? Why does having a utility to adminster the system imply "desktop! desktop" in your mind? Because it's usable by desktop-level people? 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 Sep 25 17:52:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA02384 for hackers-outgoing; Mon, 25 Sep 1995 17:52:40 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA02363 for ; Mon, 25 Sep 1995 17:52:27 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id UAA14129; Mon, 25 Sep 1995 20:53:28 -0400 Date: Mon, 25 Sep 1995 20:53:28 -0400 From: Coranth Gryphon Message-Id: <199509260053.UAA14129@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > Functionally, I can union mount my script directory over a read-only > template directory to add my local scripts. OK. But I really doubt this is something the average person is going to attempt. > How do I union two files? Have a basic file, and a local file which is called aftter the basic file. > this still doesn't handle the "union of several directories" problem, > even if the contents are simply a file, if order of operation is based > on file order. No, you've got me there, you can't easily mix lines from two different files to get an arbitrary order. But this falls into my very-small-fraction of people category. I really can't conceive of it being a general case to want two unique sets of start ups that need to be interspesed, in a generic manner, on the fly. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 17:54:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA02532 for hackers-outgoing; Mon, 25 Sep 1995 17:54:26 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA02511 for ; Mon, 25 Sep 1995 17:54:05 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id UAA14148; Mon, 25 Sep 1995 20:56:08 -0400 Date: Mon, 25 Sep 1995 20:56:08 -0400 From: Coranth Gryphon Message-Id: <199509260056.UAA14148@healer.com> To: kelly@fsl.noaa.gov, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, gryphon@healer.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > Unless /etc is read-only and the only method you have to add your own > stuff is union mounts (additional directory entries). In which case, you've set up a very unique configuration, where you cannot change "motd", cannot edit password files, change mail aliases, add new hosts to DNS, ... These types of changes are at least as common, if not a lot more so, than adding packages. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 18:06:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA02755 for hackers-outgoing; Mon, 25 Sep 1995 18:06:09 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA02749 for ; Mon, 25 Sep 1995 18:05:56 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id VAA14193; Mon, 25 Sep 1995 21:02:01 -0400 Date: Mon, 25 Sep 1995 21:02:01 -0400 From: Coranth Gryphon Message-Id: <199509260102.VAA14193@healer.com> To: hackers@freebsd.org, pds@freefall.freebsd.org Subject: Re: Problems with packages, and general third party software. Sender: owner-hackers@freebsd.org Precedence: bulk From: Peter da Silva > One problem with installing things from packages is you don't get any > convenient pointer to how to configure them. For example, if I hadn't That's a problem with the port not containing documentation on its own configuration. > I'm thinking... as well as the /etc/rc* stuff, we need to look at how to > mechanise standard crontab and inetd.conf and services entries. It's always possible to auto-edit files. The problems come in when you have potential conflicts with service numbers, or other such... For complex sub-systems, there will (if not always, at least for the next long while) be things that need to be hand-configured. > And you have to add "operator" to the operator group in /etc/group. I don't > think we want pkg_add doing this either. No, but operator should probably be in the "operator" group anyway, ya think? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 18:34:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03266 for hackers-outgoing; Mon, 25 Sep 1995 18:34:06 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA03261 for ; Mon, 25 Sep 1995 18:34:03 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA27379; Tue, 26 Sep 95 02:34:29 +0100 Date: Tue, 26 Sep 95 02:34:29 +0100 Message-Id: <9509260134.AA27379@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: freebsd-hackers@freebsd.org Subject: f77 (f2c) update X-Mailer: Emacs Sender: owner-hackers@freebsd.org Precedence: bulk Hi, I have an updated (and working!) version of f2c and the accompanying libraries. This version fixes many bugs in the compiler. Will you object to an update of the tree? Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-hackers Mon Sep 25 18:46:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03600 for hackers-outgoing; Mon, 25 Sep 1995 18:46:48 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03595 for ; Mon, 25 Sep 1995 18:46:45 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06510; Mon, 25 Sep 1995 18:42:34 -0700 From: Terry Lambert Message-Id: <199509260142.SAA06510@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 18:42:33 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509260053.UAA14129@healer.com> from "Coranth Gryphon" at Sep 25, 95 08:53:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1371 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Functionally, I can union mount my script directory over a read-only > > template directory to add my local scripts. > > OK. But I really doubt this is something the average person is going > to attempt. You're right. The average person is going to use the Windows95 that was loaded on his system by his dealer. > > How do I union two files? > > Have a basic file, and a local file which is called aftter the basic file. Unacceptable for replacing things like mail daemons if something in the basic file relies on having an smtp server present. > No, you've got me there, you can't easily mix lines from two > different files to get an arbitrary order. > > But this falls into my very-small-fraction of people category. > I really can't conceive of it being a general case to want two > unique sets of start ups that need to be interspesed, in a generic > manner, on the fly. I think this is the conceptual problem. These are not two unique sets of startups. These are complementary sets of startups, one of which should not be modified by virtue of it being part of the default distribution and therefore a sore point at upgrade time if it *is* modified, or which may be on read-only media (CDROM or NFS R/O mount). 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 Sep 25 18:53:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03767 for hackers-outgoing; Mon, 25 Sep 1995 18:53:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03762 for ; Mon, 25 Sep 1995 18:53:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06533; Mon, 25 Sep 1995 18:49:26 -0700 From: Terry Lambert Message-Id: <199509260149.SAA06533@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Mon, 25 Sep 1995 18:49:26 -0700 (MST) Cc: kelly@fsl.noaa.gov, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, gryphon@healer.com In-Reply-To: <199509260056.UAA14148@healer.com> from "Coranth Gryphon" at Sep 25, 95 08:56:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1523 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Unless /etc is read-only and the only method you have to add your own > > stuff is union mounts (additional directory entries). > > In which case, you've set up a very unique configuration, where > you cannot change "motd", cannot edit password files, change mail > aliases, add new hosts to DNS, ... The motd should be in var. Local passwords not in the NIS database or user IDs needed for boot should be in var. Mail aliases should be handled by the mail exchanger host; those that are local to the local machine should be in the users' personal alias database. or they should be in var. DNS server/caching databases should be in var. A client DNS configuration is not subject to change by the client. > These types of changes are at least as common, if not a lot more so, > than adding packages. Only because we have local system information in the wrong damn place, which is why we don't have the ability to upgrade in the first place (upgrade/addition-of-options is what started this whole thread). If the /etc/rc file was completely data-driven, it wouldn't need to be modified. If it didn't need to be modified, then upgrade would not be a problem (you'd just overwrite the thing). If configuration data lived in its own place, you'd update everything but that place, and you'd be upgraded (you'd overwrite all of /etc). An upgrade is a typical user operation. 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 Sep 25 19:28:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA05097 for hackers-outgoing; Mon, 25 Sep 1995 19:28:23 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05086 for ; Mon, 25 Sep 1995 19:28:10 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id TAA14346; Mon, 25 Sep 1995 19:27:06 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29636; Mon, 25 Sep 1995 19:32:44 -0700 Date: Mon, 25 Sep 1995 19:32:44 -0700 Message-Id: <9509260232.AA29636@asimov.volant.org> To: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > And hard links are even more useful than symlinks. With hard links, |> > you can easily determine how many states are using a given script |> > simply by checking the number of links to the master copy. |> ... |> > Right. One directory per state, and one directory for the cannonical |> > location of the scripts. |> |> Same problem. I've just seen two many times when keeping multiple |> copies of something has led to problems. They aren't multiple copies, they are multiple links to a single copy. I generally agree that having multiple copies or multiple locations can lead to problems; but in this case I believe that the advantages far outweigh the possible difficulties. |> > My problem with run levels is that if I want a state which does not |> > correspond to any of the standard levels, it will probably need to |> > go inbetween two of the standard ones. (E.g. multi-user, with full |> |> Same problem occurs with states - you have to pick the one closest |> to what you want and No, I can easily create my own state using the next available state number. Since there's no implied level-ordering of the states, which number I choose is purely arbitrary. |> > as levels, I'd have to re-number the levels to insert my new state. |> |> Granted, that is a problem. We could solve most of it by allocating |> a half-way state that is unused at each point a "local". Gack. First, one 'local' isn't enough. Second, the new states may not actually fit between any of the existing states. (E.g., another contractor I know wants a single-user-with-networking state.) |> > If the implementation supports states, it is easy to provide levels. |> > If it only supports levels, using it to get distinct states is going |> > to be pretty tough. |> |> Yep, you're right. That's the biggest drawback of levels. |> |> It quickly becomes a matter of - how much flexibility is really going |> to be used how often. If it's twice the work for twice the functionality, |> it's worth it. If it's twice the work to make +5% people happy, then |> it's questionable. If twice the work makes ten people happy, then it's not. But it isn't twice the work. It's barely any more work at all. |> > |> Yep. Alternately, the "cron" script can take an argument of |> > |> "multi-user" or "network" and do the right thing. |> |> > Cron shouldn't need to know. And doing that limits the possible cron |> > actions choosable from the different states. |> |> Cron doesn't know. The script that runs starts/runs/creates/whatever |> the crontab entry knows. Ok, the script invoking the per-service scripts shouldn't need to know that cron takes a different parameter than other scripts, and a parameter based on the state being entered. The SVr4/Solaris2/etc. technique is the simplest and most powerful mechanism proposed to date. Let's not let a hatred for SysV keep us from adopting one of the things they did -very- well. |> |> in summary, my druthers are: |> |> > one directory for all start and stop scripts |> |> > explicit invocation order, a list |> |> > one name per script regardless of run-state/level |> |> > (no links hard or soft) |> |> |> |> > One master directory for start/stop/restart scripts. |> > One directory per run state, with hardlinks to above. |> > Invocation order dictated by digits in script name. |> |> As I said in my response to Terry, it quickly becomes religious |> discussion of which is better, numbered scripts or control files. |> |> > --- NO SCRIPT EDITING !!! ---- |> |> We are not talking about script editing. We are talking about adding |> a line to a control file, versus adding a line to a directory. How does 'adding a line' differ from 'editing' ? Control file -vs- script is a minor point compared to the fact of installation scripts editing shared system control files. |> > I cannot possibly overemphasize the advantages of a system which |> > avoids the need to ever automatically edit any file. This avoidance |> > is the single biggest advantage of the SVr4 model. |> |> And one of it's single biggest confusions. I prefer BSD variants |> over SysV variants BECAUSE of design decisions like this. |> A lot of other people probably do as well. If this really confuses you that much, perhaps you aren't well suited to systems administration. Personally, I'd far rather have the tiny bit of potential confusion than the huge potential for damage. |> If you want SysV, use Linux. If you want FreeBSD to get some new |> flexibility (based upon concepts from anywhere else) - GREAT. |> |> But don't say "SysV is doing it so we should"! Don't say "SysV is doing it so we shouldn't"! I really think you are letting your hatred for SystemV color your judgement here. Sit back and pretend that this mechanism was not invented by SysV. Pretend that we are inventing it here for the first time. Would you really be so adamantly against it? (You don't have to answer publicly - just think about it for yourself.) |> At this point, we have two distinct camps - those who want to see |> the {S|K}NNfoo scripts in "rc?.d" with a copy in "init.d" subdir. |> In other words "SysV". Would it help if we struck out "SysV" and substituted "Solaris2", or do you hate that as well? |> And those of us who want one directory ("init.d") and a control |> file to specify what gets run when. In other words, a hybrid. Sounds like less of an improvement over the current system than Windows95 was over Windows 3.1. |> Neither camp is going to convince the other. So someone who can make |> the decision of which direction to head in should do so, and let |> us get down to doing the best implementation of whichever that we can, |> rather than debating it for another three months, and then kludging |> something together in a hurry. |> |> Or, if we want to put a little more work in, we can do both and |> make everyone happy. We have to define the commonalities (one |> script per subsys/package/component, a copy in "init.d") and a |> fixed interface so that the two different startup "descriptions" |> can both use the underlying mechanism. What this means is that |> both camps will write versions, and make sure they work together. Easily done. 'Inittab' and init.d become the 'required' part of the system, with a control file or rc?.d subdirs and rc? scripts as the 'optional' parts. |> But we'll end up with something that is simply fantastic, |> and will suit both styles. That's a lot tougher. The biggest problem being to make the package installation scripts able to handle the necessary updates for both techniques. (And without turning that into another maintainance nightmare or Rube Goldberg system.) |> If we go with control files, or with the do-it-both-ways system, |> count me in as willing to do a large chunk of it. And if we go with states, rc?.d subdirs, etc., I'll certainly contribute whatever I can. -Pat From owner-freebsd-hackers Mon Sep 25 19:49:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA06331 for hackers-outgoing; Mon, 25 Sep 1995 19:49:06 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA06316 for ; Mon, 25 Sep 1995 19:49:01 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id TAA14955; Mon, 25 Sep 1995 19:47:37 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29658; Mon, 25 Sep 1995 19:53:15 -0700 Date: Mon, 25 Sep 1995 19:53:15 -0700 Message-Id: <9509260253.AA29658@asimov.volant.org> To: terry@lambert.org, gryphon@healer.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> From: Terry Lambert |> >>> Ah, but can you guarantee that the install script that inserts a |> >>> few new lines is putting them in the right place? |> > |> >+> Can you guarantee that the install script is going to get the numbering |> >+> right if we go with implicit order based upon script name? |> |> > Yes, actually. By using a sparse numeric order designator at the front |> > of the name to enforce ordering by strict lexical (numeric) order. Like |> > numbering your lines by 10 or 100 in a BASIC program. |> |> Like it adds to the end of the file. Or adds to the first (or fourth or ...) |> line after its dependancy. If it can find the dependancy. And doesn't mistake something else for it. Which basicly means it will work fine in the lab and fail miserably in the real world. I have yet to see an automatic editing system which was robust in the face of manual editing of the target file. Particularly when the manual editing is being done by less experienced sysadmins that might not know about the peculiarities of the automatic system... |> > +> Or worse, is every install going to check to make sure that no other |> > +> scripts exists which use that order number? |> |> > No. Because the number is not the only designator. By definition, |> > collisions in order designation are "don't care". This is because if |> |> Again, you can always append to the file if it is a "don't care", |> unless we are allowing additions that MUST come before other things |> that already exist in the startup sequence. I can think of it happening, |> though I'd like to see ANY automated sequence deal gracefully with it. |> And if it does, the same logic can be applied to the file edit. It's a matter of how simply the logic can be applied. With the numbered file technique, it is generally a simple matter to nail down the sparse sequence points that are likely to be significant (NFS started, etc.) Once that has been done, the install scripts can be written with a priori knowlege and hard-coded sequence numbers. In the file editing case, the installation script must be able to recognize the proper insertion point by examining the file at run time. (And if that doesn't scare you, think about scripts trying to automatically -remove- services from the script. If you still aren't scared, you haven't been a sysadmin for long enough.) |> It really boils down to perference of style, and... Well, if you want to consider safety a point of style... |> > +> I think these are a LOT more dangerous. File order is explicit |> > +> and simple. Anything else is headaches. |> |> > You are not expected to manually edit the data. If you want to, fine: |> > you deserve headaches. The point is to make it easy for the tools, not |> |> It always comes down to a person trying to figure it out when something |> is wrong. I'd rather spend a little more time making the tools smarter, |> so that a person has an easier time of it, than making the tools stupid, |> and hoping the person is smart enought to work around that. |> |> That's the whole point of everything we're doing. Give the average |> person on the street a system that they can understand and maintain. |> Personally, I'd rather me (the designer/programmer) spend the time to |> make their lives easier, since that generates a larger customer/user base. Great plan. But in this situation, it suffers badly from diminishing returns. You are talking about implementing a complex installation and removal system to allow for a run-time system which only appears simpler. I predict that your installation system will -never- be a solid, safe, easy-to-configure-and-use mechanism; because it will have to be too complex. |> Make things so that only long-time sys-admins with a serious understanding |> of OS concepts can debug this, and such free OS's will die. Actually, I find the SysV/Solaris2 technique -easier- to understand and work with. |> > +> Yes, this relies upon implicit order (whatever "find" returns), which I |> > +> really don't like. But I couldn't see any other option, and if you |> |> > fairly simple: pick a number after the number of the packages you depend |> > on, but low enough that other packages may depend on you without |> > overflowing the lexical name space. I'd suggest 3 digits rather |> > than 2 as a guard |> |> Or use file order, in which case your numbering limit is maximum number |> of lines in the file. Again, it quickly becomes a religious battle of |> which people prefer - numbered scripts or a control file. No, it isn't a purely religious battle over preferences - it is a very real battle over safety-and-simplicity -vs- perceived-simplicity and tradition. |> Personally, I like the control file. I can print it out, and know |> exactly what will run in what order. |> |> You like numbered scripts, you can print out a directory listing, |> and know exactly what will run in what order. |> |> Functionally, they are the same. Issues for the automation are similar |> in most cases (getting the ordering right, dependancies, collisions). |> |> You way requires sym-linked sub-dirs to control the order, mine still |> holds to the same master file. The danger of mine is that packages |> need to modify the master file, the danger of yours is that packages |> need to make sure they put the right files and links in the right places. And I submit that my dangers are significantly less severe than yours. |> > The second best concept [SysV] had was run levels/states to allow staged |> > "run-up" and "run-down". |> |> I still like linear run-levels, rather than arbitrary states (and think the |> former would be a LOT easier to implement). Now we're closer to a religious issue :-) (And I think the implementation difference is minor.) -Pat From owner-freebsd-hackers Mon Sep 25 20:14:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07514 for hackers-outgoing; Mon, 25 Sep 1995 20:14:54 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07500 for ; Mon, 25 Sep 1995 20:14:29 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id XAA14582; Mon, 25 Sep 1995 23:16:25 -0400 Date: Mon, 25 Sep 1995 23:16:25 -0400 From: Coranth Gryphon Message-Id: <199509260316.XAA14582@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > +> In which case, you've set up a very unique configuration, where > +> you cannot change "motd", cannot edit password files, change mail > +> aliases, add new hosts to DNS, ... > DNS server/caching databases should be in var. A client DNS configuration > is not subject to change by the client. Unless you happen to be running as your domain primary, which a LOT of people do. But then again, why bother keeping track of any data, just let each machine announce itself and configure everything dynamically, seems to work for MS-Windows. > The motd should be in var. > Local passwords not in the NIS database or user IDs needed for boot > should be in var. > Mail aliases should be handled by the mail exchanger host; those that > are local to the local machine should be in the users' personal alias > database. or they should be in var. Ok, so you want to rewrite the entire BSD configuration system, and take anything that might change out of /etc. Fine. I give up. You want to change everything, go ahead. It's not worth trying to fine a compromise when you want a read-only system configuration. > +> These types of changes are at least as common, if not a lot more so, > +> than adding packages. > Only because we have local system information in the wrong damn place, > which is why we don't have the ability to upgrade in the first place > (upgrade/addition-of-options is what started this whole thread). No, the problem is that traditionally, these things went into /etc since that was the configuration directory. You don't want it to be the configuration directory, you want it to be a static system configuration that comes on CD and doesn't change. > An upgrade is a typical user operation. How often? Once every 3-4 months? Do we really want to rewrite everything around /etc being read-only and change every existing configuration utility and script, so that we can go through the entire conversation all over again when the directory is named /var/config? The nice thing about /var right now is that everything there (with a very few exceptions which have already been discussed) is volatile. It can be blown away and replaced with no problem, other than loss of history. Now, it would entail a complete reconfiguration. If you want to rewrite everything go ahead. Just be prepared for the few thousand people being real confused that /etc/passwd is now /var/config/local/passwd. On the other hand, if people want to take a working system (what we have now) and add a bit of flexibilty and functionality to it, let me know so I can help. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 20:15:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA07547 for hackers-outgoing; Mon, 25 Sep 1995 20:15:02 -0700 Received: from quirk.com (root@quirk.com [198.82.204.56]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA07531 for ; Mon, 25 Sep 1995 20:14:58 -0700 Received: (from cstruble@localhost) by quirk.com (8.6.11/8.6.9) id XAA04532 for freebsd-hackers@freebsd.org; Mon, 25 Sep 1995 23:15:00 -0400 Message-Id: <199509260315.XAA04532@quirk.com> Subject: Objective C To: freebsd-hackers@freebsd.org Date: Mon, 25 Sep 1995 23:14:58 -0400 (EDT) From: cstruble@vt.edu Reply-To: cstruble@vt.edu X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 974 Sender: owner-hackers@freebsd.org Precedence: bulk Well, I saw a discussion a while ago, but it seemed without resolution. I'm very interested in getting Objective C working on FreeBSD, but so far have been unable to get anywhere. I compiled gcc 2.7.0 and everything seemed to compile fine. I then tried to build libobjects-0.1.14 and the test programs. All the test programs fail with a core dump (floating point exception) in libobjc.a, the Objective C runtime library. It seems to be a problem with __builtin_return(), but my compiler knowledge is a bit lacking so I can't figure out exactly what is wrong. Has anyone gotten any Objective C programs to work on FreeBSD? If so, what magic incantations do I have to perform to get them to run? See ya later, Craig -- Craig Struble - Grad Student, Consultant, | World's most versatile C program Student ACM Co-President, Virginia Tech | (*nix version) Email - cstruble@vt.edu | URL - http://acm.vt.edu/~cstruble/ | #include "/dev/tty" From owner-freebsd-hackers Mon Sep 25 20:41:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA08794 for hackers-outgoing; Mon, 25 Sep 1995 20:41:28 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA08777 for ; Mon, 25 Sep 1995 20:41:12 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id XAA14628; Mon, 25 Sep 1995 23:43:33 -0400 Date: Mon, 25 Sep 1995 23:43:33 -0400 From: Coranth Gryphon Message-Id: <199509260343.XAA14628@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: patl@asimov.volant.org > I generally agree that having multiple copies or multiple locations > can lead to problems; but in this case I believe that the advantages > far outweigh the possible difficulties. That's where we differ. I don't see any advantage to it. > Gack. First, one 'local' isn't enough. Second, the new states may > not actually fit between any of the existing states. (E.g., another > contractor I know wants a single-user-with-networking state.) > > No, I can easily create my own state using the next available state > number. Since there's no implied level-ordering of the states, which > number I choose is purely arbitrary. It's a question of how much flexibility is going to be commonly used vs. how much effort it take to implement each increase in flexibility. But I agree that run-states are worth the effort. It gets us the most for only a medium increase in difficulty. > The SVr4/Solaris2/etc. technique is the simplest and most powerful > mechanism proposed to date. Let's not let a hatred for SysV keep > us from adopting one of the things they did -very- well. No it is not the simplest. And that it was done "very well" is entirely debatable. As I said, it comes down to a religious argument. I don't like it, you do. > |> We are not talking about script editing. We are talking about adding > |> a line to a control file, versus adding a line to a directory. > How does 'adding a line' differ from 'editing' ? Control file -vs- > script is a minor point compared to the fact of installation scripts > editing shared system control files. Each sub-system has it's own script. A control file determines what gets run when. Or each sub-system has it's own script, and directory ordering in a sym-linked tree determines which gets run when. > |> And one of it's single biggest confusions. I prefer BSD variants > |> over SysV variants BECAUSE of design decisions like this. > |> A lot of other people probably do as well. > If this really confuses you that much, perhaps you aren't well suited > to systems administration. Personally, I'd far rather have the tiny > bit of potential confusion than the huge potential for damage. It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN. Personal opinion, which is a matter of a lot of experience. I've been doing unix system and programming admin for about 10 years. And I like the BSD way over the SysV way. > Don't say "SysV is doing it so we shouldn't"! I'm not saying not to do it because someone else is, I'm saying not to do because I consider it a bad design and most examples of it bad implementations of that bad design. > I really think you are letting your hatred for SystemV color your > judgement here. Sit back and pretend that this mechanism was not I don't reject SysV style ways of doing things because they come from SysV. I reject SysV because it does things those ways. I don't care who invented it. I've looked at it, worked with it, and don't agree with it. It's really that simple. > Pretend that we are inventing it here for the > first time. Would you really be so adamantly against it? (You > don't have to answer publicly - just think about it for yourself.) Would I still be against it? Yes. I was against it the first half-dozen times I had to work with it (and still am after 10 years), and I was against similar designs I've run into on entirely unrelated projects. I prefer to keep configuration information explicit, in a file, not implicit, in a sort order. I prefer to keep one copy of things, not two - even if they are links. |> Or, if we want to put a little more work in, we can do both and |> make everyone happy. We have to define the commonalities (one > Easily done. 'Inittab' and init.d become the 'required' part of the > system, with a control file or rc?.d subdirs and rc? scripts as the > 'optional' parts. The directory which holds everything ("init.d" or whatever it's called) and one-script-per-subsystem (stored there) are the 'required parts'. The two options for ordering determination are the control file ("inittab" or "init.conf" or whatever it's called) and the "rc?.d" directories with sym-links and names based on start/stop and numeric ordering. Details on how to best implement each them become unrelated discussions. Except that anything in common becomes part of the underlying foundation, so that only the differences are implemented in parallel. > |> But we'll end up with something that is simply fantastic, > > That's a lot tougher. The biggest problem being to make the package > installation scripts able to handle the necessary updates for both Each mechanism will have to have a means to automatically add config information. These two will become subroutines of some overall tool (called "pkg_init_setup" or whatever). All packages/ports will call this commong interface, which will determine (by some fixed mechanism) which startup type is in use, and call the correct subroutine. This "dual-natured" system was mentioned by someone as already having been done. And working well for those who use it. Powers that be? Who makes the decision on which (or both) way we go? At this point, it's pick a direction, unless anyone has any other completely different paths to head in? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 20:51:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09322 for hackers-outgoing; Mon, 25 Sep 1995 20:51:54 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA09308 for ; Mon, 25 Sep 1995 20:51:48 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19436 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Mon, 25 Sep 1995 22:47:50 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id WAA27407 for hackers@FreeBSD.ORG; Mon, 25 Sep 1995 22:42:58 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260342.WAA27407@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Mon, 25 Sep 1995 22:42:57 -0500 (CDT) In-Reply-To: <199509251441.KAA12169@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:41:35 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 482 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Ordering guarantees within a single run level/state are hard to provide > > with the single monolithic file model. > Actually, a single file is the easiest to control ordering in. Not if you're adding to it from a script. > Last I checked, line 1 always came before line 2. :-) Yeh, but does "httpd" come before or after "nfsiod"? It's much easier to do "ln -s ../init.d/httpd S95httpd" than to figure out where in the middle of a user-hacked script a command needs to go. From owner-freebsd-hackers Mon Sep 25 20:52:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09343 for hackers-outgoing; Mon, 25 Sep 1995 20:52:03 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id UAA09321 for ; Mon, 25 Sep 1995 20:51:53 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19438 (5.67a/IDA-1.5 for hackers@freebsd.org); Mon, 25 Sep 1995 22:47:55 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id WAA27526 for hackers@freebsd.org; Mon, 25 Sep 1995 22:47:09 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260347.WAA27526@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Mon, 25 Sep 1995 22:47:08 -0500 (CDT) In-Reply-To: <199509251417.KAA12111@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:17:46 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 833 Sender: owner-hackers@freebsd.org Precedence: bulk > 1) Explicit (complex) numbering in the single directory Experience shows that the parenthetical (complex) is just not true. > 2) Mirrors of the "init.d" directory into other directories "rcN.d" > with explicit numbering in those This is nice. > 3) Script to run from that directory to control order. That's where we are now. > 4) Control file. That's identical to #3. > #2 - You get whole directories of symlinks. Yuk. Lots of headaches. A name in a file is a symbolic link, too. Except it's harder to add. > #4 Works very simply. Ports can add one line to a config file, And where pray tell do they add the line? At the end? Then you might as well go back to #1 except now they'll be in random order. And anywhere else just doesn't bear thinking about. > Why complicate things? Dependencies on startup order. From owner-freebsd-hackers Mon Sep 25 20:55:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA09611 for hackers-outgoing; Mon, 25 Sep 1995 20:55:26 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA09604 for ; Mon, 25 Sep 1995 20:55:20 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id VAA12606; Mon, 25 Sep 1995 21:57:20 -0600 Date: Mon, 25 Sep 1995 21:57:20 -0600 From: Nate Williams Message-Id: <199509260357.VAA12606@rocky.sri.MT.net> To: Jean-Marc Zucconi Cc: freebsd-hackers@freebsd.org Subject: Re: f77 (f2c) update In-Reply-To: <9509260134.AA27379@cabri.obs-besancon.fr> References: <9509260134.AA27379@cabri.obs-besancon.fr> Sender: owner-hackers@freebsd.org Precedence: bulk > I have an updated (and working!) version of f2c and the accompanying > libraries. This version fixes many bugs in the compiler. > Will you object to an update of the tree? I certainly wouldn't. Nate From owner-freebsd-hackers Mon Sep 25 21:00:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA09891 for hackers-outgoing; Mon, 25 Sep 1995 21:00:18 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA09876 for ; Mon, 25 Sep 1995 21:00:03 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id AAA14675; Tue, 26 Sep 1995 00:01:05 -0400 Date: Tue, 26 Sep 1995 00:01:05 -0400 From: Coranth Gryphon Message-Id: <199509260401.AAA14675@healer.com> To: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: patl@asimov.volant.org > |> it adds to the end of the file. Or adds to the first (or fourth or ...) > |> line after its dependancy. > If it can find the dependancy. And doesn't mistake something else for it. > Which basicly means it will work fine in the lab and fail miserably in the >real world. I have yet to see an automatic editing system which was robust Anything which can figure out the correct number to use for the script name can figure out where to place itself in a file. If it can't, then it can't and the argument become moot. |> > No. Because the number is not the only designator. By definition, |> > collisions in order designation are "don't care". This is because if |> |> Again, you can always append to the file if it is a "don't care", > It's a matter of how simply the logic can be applied. With the numbered > file technique, it is generally a simple matter to nail down the sparse > sequence points that are likely to be significant (NFS started, etc.) So the numbers also become run levels (being how much we've started running). Great. Back to argument #1. :-) > Once that has been done, the install scripts can be written with a priori > knowlege and hard-coded sequence numbers. In the file editing case, the > installation script must be able to recognize the proper insertion point For 99% of cases, just append to the file. You only need to "find the correct point" if you are inserting into the middle of a process chain. Which will probably be a very rare condition, unless you are replacing one startup command with another, in which case the position is already determined for you. > by examining the file at run time. (And if that doesn't scare you, think > about scripts trying to automatically -remove- services from the script. > If you still aren't scared, you haven't been a sysadmin for long enough.) Granted. Having things remove from a control file requires good solid coding. So does having a script remove a file automatically from the startup directory set, when the name has been permuted with command prefixes (S## or K##). I've worked with both types of systems, and I really have never found one to be more dangerous or less dependable than the other. > |> That's the whole point of everything we're doing. Give the average > |> person on the street a system that they can understand and maintain. > |> Personally, I'd rather me (the designer/programmer) spend the time to > |> make their lives easier, since that generates a larger customer/user base. > Great plan. But in this situation, it suffers badly from diminishing > returns. You are talking about implementing a complex installation > and removal system to allow for a run-time system which only appears If we automate things, we either do it right or we screw up a lot of things. That holds regardless of the automation procedure, or how the underlying layers are implemented. > Actually, I find the SysV/Solaris2 technique -easier- to understand and > work with. As I said, it's a matter of personal preference. |> > +> Yes, this relies upon implicit order (whatever "find" returns), which I |> > +> really don't like. But I couldn't see any other option, and if you |> |> > fairly simple: pick a number after the number of the packages you depend |> > on, but low enough that other packages may depend on you without |> > overflowing the lexical name space. I'd suggest 3 digits rather |> > than 2 as a guard |> |> Or use file order, in which case your numbering limit is maximum number |> of lines in the file. Again, it quickly becomes a religious battle of |> which people prefer - numbered scripts or a control file. > No, it isn't a purely religious battle over preferences - it is a very > real battle over safety-and-simplicity -vs- perceived-simplicity and > tradition. No. It's which you see as simpler and safer vs. which I see as simpler and safer. I've built systems using my methods. They work. They are dependable. I've seen and worked with (but not written) systems that use your (and SysV) method. They work. They are dependable. Both work. They simply do things in different ways. Both make seperate assumptions and take divergent risks. Both are dependable if implemented well. And if they are not implemented well, then we hit an entirely different argument. So we pick one path, and some subset of people become unhappy, or we implement both, and put in extra work (but get good results for it) or we give up on the entire concept, and stay with what we have. Think about this: When the argument comes up, "Which should I use? FreeBSD or Linux?", the answer I invariable see from the core team is "Try them both and decide for yourself". So I say let's implement both, do a great job on both, and see which people like. If they like both, we keep both. If they don't we drop the one that noone likes. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 21:19:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA10697 for hackers-outgoing; Mon, 25 Sep 1995 21:19:38 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA10692 for ; Mon, 25 Sep 1995 21:19:34 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19471 (5.67a/IDA-1.5 for hackers@freebsd.org); Mon, 25 Sep 1995 22:57:55 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id WAA27631 for hackers@freebsd.org; Mon, 25 Sep 1995 22:49:34 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260349.WAA27631@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Mon, 25 Sep 1995 22:49:34 -0500 (CDT) In-Reply-To: <199509251402.KAA12092@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:02:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 536 Sender: owner-hackers@freebsd.org Precedence: bulk > Agreed. I've said it before - symlink are only useful if you > (for some reason) can't put something where it belongs, of if > it really needs to be in two places at one: the latter translates > as "cannot be easily gotten at in the proper place" or "a non-optimal > location is hard-coded in something". Symlinks have *lots* of uses other than that. I use them all the time. For example, I'll install a program as "foocalc.version" and symlink "foocalc" to it. Symlinks are clean, self-documenting, and elegant, if used properly. From owner-freebsd-hackers Mon Sep 25 21:41:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA11121 for hackers-outgoing; Mon, 25 Sep 1995 21:41:18 -0700 Received: from localhost.lightside.com (user32.lightside.com [198.81.209.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA11116 for ; Mon, 25 Sep 1995 21:41:14 -0700 Received: (from jehamby@localhost) by localhost.lightside.com (8.6.12/8.6.9) id VAA00702; Mon, 25 Sep 1995 21:40:49 -0700 Date: Mon, 25 Sep 1995 21:40:25 -0700 (PDT) From: Jake Hamby X-Sender: jehamby@localhost To: Coranth Gryphon cc: patl@asimov.volant.org, terry@lambert.org, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts In-Reply-To: <199509260401.AAA14675@healer.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Tue, 26 Sep 1995, Coranth Gryphon wrote: > From: patl@asimov.volant.org > > > Actually, I find the SysV/Solaris2 technique -easier- to understand and > > work with. > > As I said, it's a matter of personal preference. This is the first time I've responded to this LONG thread, and it'll probably be the last, so I'll say what I have to say, and keep quiet for the rest of the bickering. When I first saw the SVR4 model on a Solaris box, it was SO confusing; I thought it was needlessly complex and difficult to comprehend. But when I first saw the BSD startup scripts I thought they were very disorganized and difficult to customize (and as many people have pointed out, almost impossible for a script to properly customize without goofing something up). BTW, my first Unix administration experience was a Slackware Linux box (System V inittab but BSD-ish startup scripts). As I learned more about both paradigms, I came to appreciate the SVR4 model more and more. And the fact that you don't have to write more than a few lines of shell script to run the S## and K## scripts in the proper order makes it painless to implement. As has been mentioned, the most significant advantage is that the existing pkg_add facilities can add startup scripts just like any other file; without ANY special handling code, and without even the possibility of destroying an important "control file" that the entire system depends on. In fact, this weekend I'll try to whip up a full /etc/rc?.d - style boot sequence and upload it to incoming. Then instead of bickering both camps can try it out, and the "control file" camp can try to come up with something better. Enough with the petty SysV/BSD religious wars and hypothetical scenarios, we need to get some actual example scripts out there to work with. > When the argument comes up, "Which should I use? FreeBSD or Linux?", > the answer I invariable see from the core team is "Try them both > and decide for yourself". So I say let's implement both, do a great > job on both, and see which people like. > > If they like both, we keep both. If they don't we drop the one that > noone likes. > > -coranth > I appreciate your enthusiasm for pushing your idea, and I agree that we should try out both implementations, but NOT in an official FreeBSD release. Supporting two different kinds of startup scripts is a nightmarish proposal. In fact, I don't think we should even push for these scripts in -current until the majority has agreed on a single paradigm, whatever it is. And, whatever we choose, it should be a good enough implementation that the minority will not be totally turned off from FreeBSD! :-) So lets get hacking, and may the best paradigm win! ------------------------------------------------------------------------------ Jake Hamby | E-Mail: jehamby@lightside.com Student, Cal Poly University, Pomona | System Administrator, JPL ------------------------------------------------------------------------------ From owner-freebsd-hackers Mon Sep 25 21:49:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA11238 for hackers-outgoing; Mon, 25 Sep 1995 21:49:55 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA11233 for ; Mon, 25 Sep 1995 21:49:52 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19769 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Mon, 25 Sep 1995 23:47:46 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id XAA28684 for hackers@FreeBSD.ORG; Mon, 25 Sep 1995 23:43:20 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260443.XAA28684@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Mon, 25 Sep 1995 23:43:19 -0500 (CDT) In-Reply-To: <199509252152.RAA13441@healer.com> from "Coranth Gryphon" at Sep 25, 95 05:52:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 918 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > --- NO SCRIPT EDITING !!! ---- > We are not talking about script editing. We are talking about adding > a line to a control file, versus adding a line to a directory. That *is* script editing. > If you want SysV, use Linux. I want the best system I can. I don't care if you call it System V or BSD or Linux or NT. Just give me as solid and clean an underpinning for the system (and the UNIX model is the best of that I know), and the best tools on top of that. > If you want FreeBSD to get some new > flexibility (based upon concepts from anywhere else) - GREAT. > But don't say "SysV is doing it so we should"! NOBODY is saying that. What they're saying is "it's working in System V, so don't just dismiss it". There's lots of stuff in System V that doesn't work (lp, for example :-P), and we can learn from that too. But if you want something that's *really* a hybrid, see the message I sent to Terry... From owner-freebsd-hackers Mon Sep 25 21:50:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA11280 for hackers-outgoing; Mon, 25 Sep 1995 21:50:06 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA11275 for ; Mon, 25 Sep 1995 21:50:03 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19700 (5.67a/IDA-1.5 for hackers@freebsd.org); Mon, 25 Sep 1995 23:36:53 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id WAA27756 for gryphon@healer.com; Mon, 25 Sep 1995 22:58:51 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260358.WAA27756@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Mon, 25 Sep 1995 22:58:50 -0500 (CDT) In-Reply-To: <199509251657.MAA12655@healer.com> from "Coranth Gryphon" at Sep 25, 95 12:57:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1942 Sender: owner-hackers@freebsd.org Precedence: bulk > Can you guarantee that the install script is going to get the numbering > right if we go with implicit order based upon script name? In general, yes. There are really only a few big things they need to be super-picky about, and they are usually standard system components (like sendmail or nfs). > Or worse, is > every install going to check to make sure that no other scripts exists which > use that order number? It is not necessary that they do so. Package-name is already unique. > I think these are a LOT more dangerous. File order is explicit and simple. And impossible to manage. > Anything else is headaches. Why don't you go look at a System V box before blindly asserting this? If it was full of headaches I wouldn't have been using it and converting other systems to use it for the past 10 years. > And yes, I know that SysV does it, and that is works fine for whoever. > I don't like SysV. Specifically, I don't like this "feature" of SysV. Pity. It's one of the features of System V that are actually *useful*. > It boils down to that. A few other people have said it, and I'll say it too. > I don't want FreeBSD to become a SysV-clone. That's what Linux is for. I smell the scent of NIH. > If people want changes to the startup mechanism, to incorporate the best > concepts from SysV, that's fine. It's call improving. Which is what we're doing. > But throwing out the entire "rc" script concept, and going with (pick an > implemention, any mutant implementation) SysV-clone I consider bad. Nobody is talking about *cloning* System V. > Will you volunteer the same for your version? Including a re-write of the > "daily/weekly" stuff that reallly should use the same mechanism? Yes. IF it will get used, and not shouted out by someone who's got a System V phobia. The last project I did for FreeBSD got shunted aside, so I'm not willing to dive in on another one without some expectation that it'll get used. From owner-freebsd-hackers Mon Sep 25 21:50:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA11321 for hackers-outgoing; Mon, 25 Sep 1995 21:50:35 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA11313 for ; Mon, 25 Sep 1995 21:50:32 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA19730 (5.67a/IDA-1.5); Mon, 25 Sep 1995 23:42:11 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id XAA28276; Mon, 25 Sep 1995 23:27:45 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260427.XAA28276@bonkers.taronga.com> Subject: Re: ports startup scripts To: terry@lambert.org (Terry Lambert) Date: Mon, 25 Sep 1995 23:27:44 -0500 (CDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199509251847.LAA05564@phaeton.artisoft.com> from "Terry Lambert" at Sep 25, 95 11:47:11 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3035 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I'd suggest 3 digits rather than 2 as a guard > against overflow, though I expect the lead digit to remain 0 for a long > time (if not forever). You mean "the trailing digit", right? Let's look at all the things that a package (not just a /cdrom/packages/... package, but any software component) needs to get right to install... 1. periodic cleanup scripts. Cron does this pretty well, except that you need to give each package its own user-id. 2. startup/shutdown scripts. The System V model does this quite well. 3. tcp/ip port assignment. This one is sticky. It's safe to append to /etc/services, but not so safe to extract them. 4. inetd-driven services. Same problem as /etc/services. 5. user and group ids, for things like news. User-ids are hard to add. Group ids are harder. A tool to do this would be helpful. 6. setting up spool directories. You don't want these to be under /usr/local. 7. setting up syslog entries. See 3, 4, 5. 8. documentation. This one we actually have under control for man pages. info files are more of a problem because you really want them to be hooked into the root. html can be handled by a directory of files or cgi-bin. 9. device drivers System V had this working pretty well. BSD is relaly pretty horrible here. How do you add stuff to MAKEDEV? /sys/i386/conf/*? 10. ... (/etc/daily???) There's a couple of basic ways to address this. You can have one directory per package, with specially named files in them (/var/db/pkg could be a start for this), or you can have multiple directories with a file in each named after the package... System V does that. It works pretty well for each individual directory, but not overall. Here's what I propose: For each package, create a directory under /etc/package. In this directory, you have the following files: startup.XXX shutdown.XXX crontab.userid makedev config passwd group ttys inetd.conf services syslog install remove There is also an /etc/package/_base. After installing a package you use these files (from /etc/package/*) to recreate: /etc/rc.local /etc/shutdown.local /var/cron/tabs/* /dev/MAKEDEV /sys/i386/conf/LINT /sys/i386/conf/GENERIC /etc/passwd (for uid<1000) /etc/passwd.master (for uid<1000) /etc/group /etc/ttys /etc/inetd.conf /etc/syslog.conf /etc/services This lets the BSD people use the files they're familiar with, but the files the system uses are secondary... they're rebuilt from packages. As an optimization, you can compare the date of the files to the dates of the /etc/package/* files, and only recreate them if there are newer files (this can be easily done with an automatically generated makefile). Most packages don't add user-ids. That's good, because recrunching the password index file can be expensive. This would work better than the current scheme, and better than System V, and doesn't need symlinks. *And* the existing package scheme works with it... From owner-freebsd-hackers Mon Sep 25 21:57:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA11424 for hackers-outgoing; Mon, 25 Sep 1995 21:57:48 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA11419 for ; Mon, 25 Sep 1995 21:57:27 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id BAA15381; Tue, 26 Sep 1995 01:00:13 -0400 Date: Tue, 26 Sep 1995 01:00:13 -0400 From: Coranth Gryphon Message-Id: <199509260500.BAA15381@healer.com> To: hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: peter@taronga.com (Peter da Silva) > > > Ordering guarantees within a single run level/state are hard to provide > +> Actually, a single file is the easiest to control ordering in. > Not if you're adding to it from a script. Three cases: (1) by hand (2) a GUI admin tool (3) a package install script 1 is easy. Humans parse things. 2 is easy. The GUI controls the file writing in all cases 3 is not very difficult in an of itself. It calls a command tool that uses the same library subroutine that the GUI calls to edit the file. The problem comes with dependancies. Which can be either addition information from the package, or guessed at (by any of the above). Personally, I can conceive of no reason not to make them explicit information contained in the package. So the package install script is never editing the file itself, it is calling something which does. And I really can't see a difference between correctly using a tool to add a line to a file, and correctly using a tool (the file system) to add a numbered script to a directory. Either you use it correctly or not, either it's written correctly or not. If not, you're in a world of hurt either way. > Yeh, but does "httpd" come before or after "nfsiod"? > It's much easier to do "ln -s ../init.d/httpd S95httpd" than to figure out > where in the middle of a user-hacked script a command needs to go. I don't know. Personally, since httpd is stand-alone, I'd put it after anything else that might have things depending on it (like file system daemons). But whoever picked the number 95 sure knows... Back to my three cases. Again, if you can figure out the number, you can figure out what it is dependent upon. If you can't you can't. Most packages are not going to be dependant on many things. And, at a quick look, I can't see any that would have things dependent upon then (we're talking on startup, not install). Granted, the sub-dir method handles run-states a little easier. But I barely see the point of that over run-levels anyway. It really comes down to which way you like to work, and which you feel more confortable relying upon. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 22:04:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA11538 for hackers-outgoing; Mon, 25 Sep 1995 22:04:10 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA11532 for ; Mon, 25 Sep 1995 22:04:04 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id BAA15489; Tue, 26 Sep 1995 01:06:46 -0400 Date: Tue, 26 Sep 1995 01:06:46 -0400 From: Coranth Gryphon Message-Id: <199509260506.BAA15489@healer.com> To: hackers@freebsd.org, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Tue Sep 26 00:47:55 1995 Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Mon, 25 Sep 1995 22:49:34 -0500 (CDT) In-Reply-To: <199509251402.KAA12092@healer.com> from "Coranth Gryphon" at Sep 25, 95 10:02:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 536 Sender: owner-hackers@freebsd.org Precedence: bulk From: peter@taronga.com (Peter da Silva) > it really needs to be in two places at one: the latter translates > as (1) "cannot be easily gotten at in the proper place" or (2) "a > non-optimal location is hard-coded in something". > For example, I'll install a program as "foocalc.version" and symlink > "foocalc" to it. "foocalc.version" is not easy to rememeber, "foocalc" is. Hence my category 1 case. > Symlinks have *lots* of uses other than that. I use them all the time. > Symlinks are clean, self-documenting, and elegant, if used properly. Agreed. I just don't think it is a good idea to design a mechanism around depending upon then. Because that means you are designing it to need the file in two places at once. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 22:10:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA11667 for hackers-outgoing; Mon, 25 Sep 1995 22:10:40 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA11658 for ; Mon, 25 Sep 1995 22:10:35 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id GAA02651 ; Tue, 26 Sep 1995 06:09:44 +0100 To: Jake Hamby cc: hackers@freebsd.org Subject: Re: ports startup scripts In-reply-to: Your message of "Mon, 25 Sep 1995 21:40:25 PDT." Date: Tue, 26 Sep 1995 06:09:42 +0100 Message-ID: <2649.812092182@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@freebsd.org Precedence: bulk In message , Jake Hamby write s: >This is the first time I've responded to this LONG thread, and it'll >probably be the last, so I'll say what I have to say, and keep quiet for >the rest of the bickering. Same for me. I've skipped over a lot of this thread, for several reasons (mainly that this is a religous issue and that you won't even find more than a handful of people agreeing on the good points of the SVR4 model, let alone what FreeBSD should do). >When I first saw the SVR4 model on a Solaris box, it was SO confusing; I >thought it was needlessly complex and difficult to comprehend. But when I >first saw the BSD startup scripts I thought they were very disorganized >and difficult to customize (and as many people have pointed out, almost >impossible for a script to properly customize without goofing something >up). As someone who has ``grown up'' around BSD derrivatives, I still scratch my head when asked to work on a Solaris box. I still maintain that neither solution is practical for what we need. The whole point of this system being implimented on FreeBSD is to allow ports and packages easy hooks into the system startup scripts. There are several problems to be addressed (hopefully in a calm and practical fashion. Who am I trying to kid? :-) ) The key to this system working is that you just plop a file in a certain directory, which will be run when the system is next booted (or shutdown - WHATEVER). This leads to several problems that I can see: 1) Who issues these script ID numbers? We cannot let people go claiming their own at random, as they *WILL* clash (even if we let them loose on a number domain with 6 significant digits!) 2) Who is responsible for ensuring that they are in the correct order? (e.g. something which loads a LKM is run *AFTER* the script to mount /usr is run). This could potentially be nasty, as the dependancy tree WILL vary over time (and even from machine to machine). 3) How will we cope with local alterations (e.g. someone running locally developed s/w which is only for local use)? Do we leave large gaps in the numbering to allow for local hacks? Am I missing something basic here? >I appreciate your enthusiasm for pushing your idea, and I agree that we >should try out both implementations, but NOT in an official FreeBSD >release. Supporting two different kinds of startup scripts is a >nightmarish proposal. In fact, I don't think we should even push for >these scripts in -current until the majority has agreed on a single >paradigm, whatever it is. And, whatever we choose, it should be a good >enough implementation that the minority will not be totally turned off >from FreeBSD! :-) So lets get hacking, and may the best paradigm win! You've just consigned your proposal to the junk heap. Getting a majority of people on -hackers to agree on anything is a major battle on ANY subject, and on this one (where issues are religous and discussions, err, ``heated'') I'd guess that it's near impossible. As for what is the ``best paradigm'', who knows. I don't think I've caught wind of it during these discussions yet. Gary From owner-freebsd-hackers Mon Sep 25 22:19:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA11927 for hackers-outgoing; Mon, 25 Sep 1995 22:19:12 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA11921 for ; Mon, 25 Sep 1995 22:19:06 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id WAA19414; Mon, 25 Sep 1995 22:18:00 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29884; Mon, 25 Sep 1995 22:23:37 -0700 Date: Mon, 25 Sep 1995 22:23:37 -0700 Message-Id: <9509260523.AA29884@asimov.volant.org> To: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> From: patl@asimov.volant.org |> > I generally agree that having multiple copies or multiple locations |> > can lead to problems; but in this case I believe that the advantages |> > far outweigh the possible difficulties. |> |> That's where we differ. I don't see any advantage to it. I can. And I don't seem to be alone. |> > Gack. First, one 'local' isn't enough. Second, the new states may |> > not actually fit between any of the existing states. (E.g., another |> > contractor I know wants a single-user-with-networking state.) |> > |> > No, I can easily create my own state using the next available state |> > number. Since there's no implied level-ordering of the states, which |> > number I choose is purely arbitrary. |> |> It's a question of how much flexibility is going to be commonly used vs. |> how much effort it take to implement each increase in flexibility. Sorry, I don't buy the 'commonly used' argument. I could retire if I had a dollar for every time I've cursed some anonymous engineer for building something with gratituous limitations because he refused to look beyond his own concept of how it was to be used, and thereby prevented me from using it slightly differently. I do agree that it is necessary to balance implementation effort against increase in generality and flexability. But don't try to estimate how many people will actually use the additional power. If there's one thing I've learned in twenty three years as a systems level software engineer, it is that it is impossible to imagine all of the ligitimate ways that people will want to use your product; and that you can be considered an engineering god if you just stay out of their way... |> But I agree that run-states are worth the effort. It gets us the most |> for only a medium increase in difficulty. Wow, a point of agreement! :-) |> > The SVr4/Solaris2/etc. technique is the simplest and most powerful |> > mechanism proposed to date. Let's not let a hatred for SysV keep |> > us from adopting one of the things they did -very- well. |> |> No it is not the simplest. And that it was done "very well" is entirely |> debatable. As I said, it comes down to a religious argument. It is the simplest mechanism that provides equivalent power. |> I don't like it, you do. I'll happily abandon it if I'm presented with a better solution. But loss of functionality simply to reduce the number of i-nodes used doesn't strike me as better. |> > |> We are not talking about script editing. We are talking about adding |> > |> a line to a control file, versus adding a line to a directory. |> |> > How does 'adding a line' differ from 'editing' ? Control file -vs- |> > script is a minor point compared to the fact of installation scripts |> > editing shared system control files. |> |> Each sub-system has it's own script. A control file determines what |> gets run when. Or each sub-system has it's own script, and directory |> ordering in a sym-linked tree determines which gets run when. Right. And it is orders-of-magnititude safer to add a file to a directory than to automatically insert a line at the right place in a control file. |> It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN. |> Personal opinion, which is a matter of a lot of experience. I've been |> doing unix system and programming admin for about 10 years. And I like |> the BSD way over the SysV way. But it isn't 100% lousy. Some parts, like the init scripts, are the best solution so far. |> > Don't say "SysV is doing it so we shouldn't"! |> |> I'm not saying not to do it because someone else is, I'm saying |> not to do because I consider it a bad design and most examples |> of it bad implementations of that bad design. |> |> > I really think you are letting your hatred for SystemV color your |> > judgement here. Sit back and pretend that this mechanism was not |> |> I don't reject SysV style ways of doing things because they come |> from SysV. I reject SysV because it does things those ways. |> |> I don't care who invented it. I've looked at it, worked with it, |> and don't agree with it. It's really that simple. Hmmmm. That's not the impression you leave from some of your other arguments. |> > Pretend that we are inventing it here for the |> > first time. Would you really be so adamantly against it? (You |> > don't have to answer publicly - just think about it for yourself.) |> |> Would I still be against it? Yes. I was against it the first half-dozen |> times I had to work with it (and still am after 10 years), and I was |> against similar designs I've run into on entirely unrelated projects. Ok, I'll accept that you have a long-standing dislike for the method. |> I prefer to keep configuration information explicit, in a file, |> not implicit, in a sort order. I just don't see any big difference in explicitness between a control file and a file naming convention; especially when the filenames have something as obvious as two digits in the first three positions. |> I prefer to keep one copy of things, not two - even if they are links. So do I. But I'm willing to recognize when the extra link is worth it. In this case, it improves clarity and power. To me, that's a clear win. Especially since your method duplicates the information about what is to be done - there is the script, and the entry in the control file. This leaves open the possibility that one will exist without the other. (Ok, it's likely to be a pretty obvious problem. But anyone who might be confused by 'implicit' file sort order is likely to have problems noticing that they've gotten out of sync.) |> The two options for ordering determination are the control file ("inittab" |> or "init.conf" or whatever it's called) and the "rc?.d" directories with |> sym-links and names based on start/stop and numeric ordering. I think we want an inittab in either case. The difference is in how many entries it is expected to have, and whether it is likely to be modified at each site. We also want the individual service scripts to be the identical for both methods. |> Details on how to best implement each them become unrelated discussions. |> Except that anything in common becomes part of the underlying foundation, |> so that only the differences are implemented in parallel. It would be nice if there were enough cross-discussion that a standard setup for one method could be automatically generated from the other; just to make life -much- easier for the folks putting together system releases. I suspect that it would be easier to generate control files from the rc?.d setups than the other way around; but that would depend a lot on exactly what went into the control files. |> > |> But we'll end up with something that is simply fantastic, |> > |> > That's a lot tougher. The biggest problem being to make the package |> > installation scripts able to handle the necessary updates for both |> |> Each mechanism will have to have a means to automatically add config |> information. These two will become subroutines of some overall tool |> (called "pkg_init_setup" or whatever). More complication for people doing ports; but probably not outrageously so. |> > |> it adds to the end of the file. Or adds to the first (or |> > |> fourth or ...) line after its dependancy. |> |> > If it can find the dependancy. And doesn't mistake something else for it. |> > Which basicly means it will work fine in the lab and fail miserably in the |> >real world. I have yet to see an automatic editing system which was robust |> |> Anything which can figure out the correct number to use for the script |> name can figure out where to place itself in a file. If it can't, then |> it can't and the argument become moot. Bzzzzttttt. Wrong. The sequence number can be static - built in when the package was built. It is the same for all systems. The file editing must be done dynamically at installation time, by examining and modifying a file that is likely to be different at each site. |> |> > No. Because the number is not the only designator. By definition, |> |> > collisions in order designation are "don't care". This is because if |> |> |> |> Again, you can always append to the file if it is a "don't care", |> |> > It's a matter of how simply the logic can be applied. With the numbered |> > file technique, it is generally a simple matter to nail down the sparse |> > sequence points that are likely to be significant (NFS started, etc.) |> |> So the numbers also become run levels (being how much we've started |> running). Great. Back to argument #1. :-) I suppose you might think of them that way; but you'd probably be in the minority. They are significant points within the sequence for a given state. Points that other services are likely to be dependant upon. You could go with levels instead of states, and make each of these significant points a separate level. But you don't want that many levels, and you'd have to re-number if a new one were ever added. (Or identified from among the services that weren't prereq's for anything else when the system was first layed out.) |> > Once that has been done, the install scripts can be written with a priori |> > knowlege and hard-coded sequence numbers. In the file editing case, the |> > installation script must be able to recognize the proper insertion point |> |> For 99% of cases, just append to the file. You only need to "find the |> correct point" if you are inserting into the middle of a process chain. |> Which will probably be a very rare condition, unless you are replacing |> one startup command with another, in which case the position is |> already determined for you. You're thinking in a box again. Do it this way, and I guarantee that somebody will curse the makers of that decision for getting in the way of what they need to do. |> > by examining the file at run time. (And if that doesn't scare you, think |> > about scripts trying to automatically -remove- services from the script. |> > If you still aren't scared, you haven't been a sysadmin for long enough.) |> |> Granted. Having things remove from a control file requires good |> solid coding. Which you trust every maker of a package to do... (And it can still lose if the lines to be recognized have been hand-editted for any reason.) |> So does having a script remove a file automatically from the startup |> directory set, when the name has been permuted with command prefixes |> (S## or K##). The S## and K## prefixes aren't really that much of a modification. And for the more paranoid, check the i-node number on the canonical file in init.d (which hasn't been renamed), and delete the rc?.d/* files with the same i-node number. (Yet another advantage of the init.d and hard links method.) |> I've worked with both types of systems, and I really have never found |> one to be more dangerous or less dependable than the other. I don't know whether to offer congratulations or condolances... |> If we automate things, we either do it right or we screw up a lot of things. |> That holds regardless of the automation procedure, or how the underlying |> layers are implemented. No, it can work right -almost- all of the time. Which makes it all the worse when it fails. |> No. It's which you see as simpler and safer vs. which I see as simpler |> and safer. Are you claiming to believe that having an install script edit a file is safer than having it simply copy a file into a directory? -Pat From owner-freebsd-hackers Mon Sep 25 22:20:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA12000 for hackers-outgoing; Mon, 25 Sep 1995 22:20:17 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA11993 for ; Mon, 25 Sep 1995 22:20:15 -0700 Received: from geli.clusternet (rcarter.vip.best.com [204.156.137.2]) by blob.best.net (8.6.12/8.6.5) with ESMTP id WAA24232; Mon, 25 Sep 1995 22:19:58 -0700 Received: (from rcarter@localhost) by geli.clusternet (8.6.12/8.6.9) id WAA09097; Mon, 25 Sep 1995 22:17:21 -0700 Date: Mon, 25 Sep 1995 22:17:21 -0700 From: "Russell L. Carter" Message-Id: <199509260517.WAA09097@geli.clusternet> To: jmz@cabri.obs-besancon.fr, nate@rocky.sri.MT.net Subject: Re: f77 (f2c) update Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk I'd really like this to go... Russell From owner-freebsd-hackers Mon Sep 25 22:21:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA12070 for hackers-outgoing; Mon, 25 Sep 1995 22:21:01 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA12063 for ; Mon, 25 Sep 1995 22:20:56 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA20013 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 26 Sep 1995 00:18:51 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id AAA29177 for hackers@FreeBSD.ORG; Tue, 26 Sep 1995 00:08:25 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260508.AAA29177@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 00:08:24 -0500 (CDT) In-Reply-To: <199509260343.XAA14628@healer.com> from "Coranth Gryphon" at Sep 25, 95 11:43:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 693 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN. > Personal opinion, which is a matter of a lot of experience. I've been > doing unix system and programming admin for about 10 years. And I like > the BSD way over the SysV way. Argument from authority? I've been doing it for 15 years, including working on the 4.1C and 4.2 BSD distributions, and I *hate* anything that depends on editing config files safely. The only system I've seen that has worked with autoedited files... and this will really make you cringe... is Microsoft Windows. Their config files actually have the hooks to do it right. Of course they don't have concurrency problems, at least until NT. From owner-freebsd-hackers Mon Sep 25 22:27:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA12423 for hackers-outgoing; Mon, 25 Sep 1995 22:27:11 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA12416 for ; Mon, 25 Sep 1995 22:27:03 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id BAA15575; Tue, 26 Sep 1995 01:29:50 -0400 Date: Tue, 26 Sep 1995 01:29:50 -0400 From: Coranth Gryphon Message-Id: <199509260529.BAA15575@healer.com> To: hackers@freebsd.org, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk Pause. Smile. Regardless of how vehement I get about points, understand that I do value other people's opinions, nor do I consdier there only one way of every doing something. Disclaimer having been made... From: peter@taronga.com (Peter da Silva) > In general, yes. There are really only a few big things they need to be > super-picky about, and they are usually standard system components (like > sendmail or nfs). And for just about all the packages (I just took a tour through my 2.0.5 CD /packages/All), the order they start up in does not matter, as long as they start after the standard system components of the appropriate level. It's these we have to worry about. And anything replacing them goes in at the same place. > +> Anything else is headaches. > Why don't you go look at a System V box before blindly asserting this? If > it was full of headaches I wouldn't have been using it and converting other > systems to use it for the past 10 years. Been there, done that. For about 10 years. And left that for BSD. Personal preference. > I smell the scent of NIH. Nope. I don't like the style. Haven't liked it for any implementation of any software (of any type). I simply do not like implicit control sequence (outside of a forward chaining expert system) nor do I like multiple locations for a single file ("init.d" and "rc?.d"). > +> Will you volunteer the same for your version? Including a re-write of the > +> "daily/weekly" stuff that reallly should use the same mechanism? > Yes. IF it will get used, and not shouted out by someone who's got a SysV > phobia. The last project I did for FreeBSD got shunted aside, so I'm > not willing to dive in on another one without some expectation that it'll > get used. I'm with you on this point. Which is why I'm trying to get a consensus agreement on which direction to head in (even if the answer is both) before I put any coding effort into it. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 22:42:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA12766 for hackers-outgoing; Mon, 25 Sep 1995 22:42:51 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA12761 for ; Mon, 25 Sep 1995 22:42:47 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id AAA04042; Tue, 26 Sep 1995 00:41:18 -0500 Message-Id: <199509260541.AAA04042@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Gary Palmer cc: hackers@freebsd.org Subject: Re: ports startup scripts In-reply-to: Your message of "Tue, 26 Sep 1995 06:09:42 BST." <2649.812092182@palmer.demon.co.uk> Reply-To: jdl@chromatic.com Clarity-Index: just a thought Threat-Level: timidly stepping into the battle Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Tue, 26 Sep 1995 00:41:18 -0500 From: Jon Loeliger Sender: owner-hackers@freebsd.org Precedence: bulk Boldly stepping into the fray, Gary Palmer scribbled: > >When I first saw the SVR4 model on a Solaris box, it was SO confusing; I > >thought it was needlessly complex and difficult to comprehend. But when I Ditto, HP/UX. Not certain and could be wrong here, but I think HP/UX might have opted away from the S/K variants and went towards the single script for both roles. > 1) Who issues these script ID numbers? We cannot let people go > claiming their own at random, as they *WILL* clash (even if we let > them loose on a number domain with 6 significant digits!) > > 2) Who is responsible for ensuring that they are in the correct order? > (e.g. something which loads a LKM is run *AFTER* the script to > mount /usr is run). This could potentially be nasty, as the > dependancy tree WILL vary over time (and even from machine to > machine). > > 3) How will we cope with local alterations (e.g. someone running > locally developed s/w which is only for local use)? Do we leave > large gaps in the numbering to allow for local hacks? Well, I think these issues point to the more generalized problem of simply representing the "dependency graph". All of the file number schemes and the single control file schemes are implementations of the general concepts of linearizing a dependency graph. Can we have a more abstract representation of that dependency graph? Can each package state "ordering information" based on either some absolute package/script references or some virtualization of concepts? Each dependency has its script or script-fragment somewhere. Then, either at like, install or boot time (ick) a topological sort is done on the graph and the script/script-fragment is linearly ordered and executed. The algorithm is data driven based on package parts supplied during the install and a well-defined although not necessarily unique ordering can be determined. There are issues here still, like, how do you state dependencies against things that have yet to be invented? I think that's why fictitious or virtual nodes may be needed in the graph too. They can essentially arbitrarily represent the "levels" or "states" in the graph where certain properties are available ("NFS", "LAN", "WAN", "Single User"). Tip-toeing back out of the warzone, jdl From owner-freebsd-hackers Mon Sep 25 22:52:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA12936 for hackers-outgoing; Mon, 25 Sep 1995 22:52:27 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA12929 for ; Mon, 25 Sep 1995 22:52:20 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id WAA20392; Mon, 25 Sep 1995 22:50:48 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29927; Mon, 25 Sep 1995 22:56:27 -0700 Date: Mon, 25 Sep 1995 22:56:27 -0700 Message-Id: <9509260556.AA29927@asimov.volant.org> To: hackers@FreeBSD.ORG, peter@taronga.com, gryphon@healer.com Subject: Re: ports startup scripts X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> From: peter@taronga.com (Peter da Silva) |> > > > Ordering guarantees within a single run level/state are hard |> > > > to provide |> > +> Actually, a single file is the easiest to control ordering in. |> |> > Not if you're adding to it from a script. |> |> Three cases: (1) by hand (2) a GUI admin tool (3) a package install script |> |> 1 is easy. Humans parse things. Only if the human has enough experience with the service and its dependancies to know where it can safely go... |> 2 is easy. The GUI controls the file writing in all cases If you think this would be a popular decision, talk to anyone who has fought with Solaris2's AdminTool over serial port or printer setup. |> 3 is not very difficult in an of itself. It calls a command tool that uses |> the same library subroutine that the GUI calls to edit the file. And suffers from the same problems; but without the fallback of being able to assume an interactive session where it can ask questions if it's having problems. |> The problem comes with dependancies. Which can be either addition |> information from the package, or guessed at (by any of the above). |> Personally, I can conceive of no reason not to make them explicit |> information contained in the package. Which means that the dependancy can never appearance - i.e. if I have a service which is dependant on having having the automounter running, I can't replace amd with whizzod. Furthermore, your dependancies will be on specific services, not a class of service. (E.g., you will be dependant on 'nfsd started', not on 'all remote file system servers started'. The rc?.d scheme, with identified sequence points, allows for a higher level of abstraction. |> So the package install script is never editing the file itself, |> it is calling something which does. |> |> And I really can't see a difference between correctly using a tool to add |> a line to a file, and correctly using a tool (the file system) to add a |> numbered script to a directory. Either you use it correctly or not, either |> it's written correctly or not. If not, you're in a world of hurt either |> way. Two differences. The first is the complexity and safety of the tool. The second is that the 'file system tool' already exists, and is widely used elsewhere in the system for a variety of purposes; a startup script editing tool would be a new, special-purpose tool. |> > Yeh, but does "httpd" come before or after "nfsiod"? |> > It's much easier to do "ln -s ../init.d/httpd S95httpd" than to figure out |> > where in the middle of a user-hacked script a command needs to go. |> |> I don't know. Personally, since httpd is stand-alone, I'd put it after |> anything else that might have things depending on it (like file system |> daemons). And I'd put it before the PPP links to the outside world... |> But whoever picked the number 95 sure knows... |> Back to my three cases. In your case #1, the person doing the install needed to know. In your cases #2 and #3 it is harder to manually modify them for some site-specific reason. (Ok, the modification itself probably isn't easier, but there's the ripple effect through any other services that are dependant upon it. In the rc?.d system, they stay in the same place, in the control file system, they probably move. Which is desired is purely case-specific. |> Again, if you can figure out the number, you can figure out what |> it is dependent upon. If you can't you can't. The point is who has to do it and when. Figuring out the (default) file number is done once when the package is created. (Probably not even changed for new revs of the software.) Modifying control files must be done on a per-system basis for each install. -Pat From owner-freebsd-hackers Mon Sep 25 22:54:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13023 for hackers-outgoing; Mon, 25 Sep 1995 22:54:02 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA13013 for ; Mon, 25 Sep 1995 22:53:59 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id WAA08945; Mon, 25 Sep 1995 22:52:57 -0700 From: Julian Elischer Message-Id: <199509260552.WAA08945@ref.tfs.com> Subject: Re: ports startup scripts To: patl@asimov.volant.org Date: Mon, 25 Sep 1995 22:52:56 -0700 (PDT) Cc: terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <9509260253.AA29658@asimov.volant.org> from "patl@asimov.volant.org" at Sep 25, 95 07:53:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 656 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk The thing about the old Sunos system (/etc/rc) was that every time yu added or subtracted a package you contributed to the entropy in that file.. things got shuffled etc. with the sysV approach you keep the details hidden in the files and the directory is an overview.. I'm sure we can do something similar to both.. the OSF systems (OSF on a PC) I run here use the SYSV approach. It's not bad. slightly complex but it's good having the symbolic links in /sbin/rc3.d pointing to /sbin/init.d it means you can delete the symlink if you don't want it and the directory gets cleaner.. it's easy to se what's going on at a glance. and it's easy to undo.. From owner-freebsd-hackers Mon Sep 25 22:57:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13190 for hackers-outgoing; Mon, 25 Sep 1995 22:57:15 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id WAA13184 for ; Mon, 25 Sep 1995 22:57:10 -0700 Received: from puffin.pelican.com by pelican.com with smtp (Smail3.1.28.1 #5) id m0sxT0u-000K2mC; Mon, 25 Sep 95 22:57 WET DST Received: by puffin.pelican.com (Smail3.1.29.1 #9) id m0sxT0t-0000ReC; Mon, 25 Sep 95 22:57 PDT Message-Id: Date: Mon, 25 Sep 95 22:57 PDT From: pete@puffin.pelican.com (Pete Carah) To: hackers@freebsd.org Subject: Re: multiple mail messages In-Reply-To: <199509242106.OAA03837@phaeton.artisoft.com> Sender: owner-hackers@freebsd.org Precedence: bulk In article <199509242106.OAA03837@phaeton.artisoft.com> Terry writes: >I've sometimes wondered if it's worthwhile to hack the mail tools for a >message id field to be respected by majorodomo when handling mail from >someone on the basis of crossposts. >I've also wondered about changing the header rewrite to be more elm >friendly. The elm program has "r(eply)" and "g(roup reply", and the >way the headers come in from the mailing lists means you can "r" to the >original sender or "g" to the mailing lists. ..... >One soloution would be to have majordomo delete duplicate targets from >the to line. That is, if it goes to multiple lists, then send it once >to the recipients that are on multiple lists. > >This would require a n:m map of actual recipient lists and an i:j map >to lists based on a message id field. It's questionable whether this >is realistic, given the processing requirements. It is a somewhat harder problem than the netnews one but not much. I'll admit that even here with only 3 sites being fed and 50-100mb/day of news my history file is >40mb (but it works comfortably with a full-time 14.4k link to the net and another single 14.4k for uucp). Does the sum of all these lists approach 10mb/day? (and what is the average message length? in netnews not counting the pictures groups it is very close to 2K.) I feed all these lists into newsgroups here so even if I get extra copies (from lists) I don't see them :-) (and I look at mail first so any personal replies I got can be ignored from trn's thread menu later when I look there.) That way I get subject grouping (though 'references' isn't preserved so I don't get good threading) ... >Finally, this would once again break elm, since duplicate message would >be distributed to a single list by list order of the recipient, and the >use of the elm "filter" program would not guarantee proper list ordering. > >For instance, a crosspost to current/questions/hackers that "belonged" >on questions would go to hackers only for the hackers+questions-list >members, current for the current+hackers+questions-list and the >current+questions-list and the current-list members, etc. The way I have the newsgroups worked out here I'd get all of them but then the message-id dups would eliminate all but the first. The crossposts would disappear here too, unless mail2news was smart enough to generate a crosspost newsgroups: line on the first message :-( Are there enough directly-connected or even well-connected uucp sites that a news feed of all these groups would make sense? (I use freebsd.questions, etc here for local names, for example). I could certainly handle redistributing it in the Southern Calif area from a T1-connected site (not here, though it wouldn't be *that* hard even here if done as news) (said T1 site is a pair of ISPs using fbsd for (almost) all of their servers... (and I'm also set up to mail locally from news if it makes sense; I already do this to get stuff to a couple of dos hosts from the earthquakes news groups.) A news distribution could even be done in parallel with mail if the gateway were careful enough to never change msg ids... (Wildcat and fido aren't so nice :-( -- Pete From owner-freebsd-hackers Mon Sep 25 23:02:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA13304 for hackers-outgoing; Mon, 25 Sep 1995 23:02:57 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA13298 for ; Mon, 25 Sep 1995 23:02:53 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id XAA20725; Mon, 25 Sep 1995 23:01:44 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA29960; Mon, 25 Sep 1995 23:07:22 -0700 Date: Mon, 25 Sep 1995 23:07:22 -0700 Message-Id: <9509260607.AA29960@asimov.volant.org> To: jehamby@lightside.com, gary@palmer.demon.co.uk Subject: Re: ports startup scripts Cc: hackers@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> As someone who has ``grown up'' around BSD derrivatives, I still |> scratch my head when asked to work on a Solaris box. Solaris2 actually has some pretty nice things, once you get past the fact that they are different. I found it was much easier to understand and appreciate Solaris2 if I pretended that it was the first unix system I had come across so that I could look at it for its own merits instead of for the differences from SunOS4/BSD/... |> 1) Who issues these script ID numbers? We cannot let people go |> claiming their own at random, as they *WILL* clash (even if we let |> them loose on a number domain with 6 significant digits!) Of course we can. The script names aren't just an ID number, they are of the form [SK]##mumble, where '##' is the ID number, and 'mumble' is the service name. It doesn't matter if two services have the same ID number, the name will keep them unique. (And we document that the execution order for scripts with the same number is 'deterministic but not defined'.) |> 2) Who is responsible for ensuring that they are in the correct order? |> (e.g. something which loads a LKM is run *AFTER* the script to |> mount /usr is run). This could potentially be nasty, as the |> dependancy tree WILL vary over time (and even from machine to |> machine). That's why you use sparse numbering, and define significant sequence points within the runlevel. (A sequence point is a number by which all services within some abstract category have been started.) |> 3) How will we cope with local alterations (e.g. someone running |> locally developed s/w which is only for local use)? Do we leave |> large gaps in the numbering to allow for local hacks? Yep, exactly. And you document the sequence points in a per-state README file in the rc?.d directory. If you have access to a late-version Solaris2 box (say 2.4 or later), take a good look at how they did it. -Pat From owner-freebsd-hackers Mon Sep 25 23:05:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA13380 for hackers-outgoing; Mon, 25 Sep 1995 23:05:23 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA13374 for ; Mon, 25 Sep 1995 23:05:21 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id XAA09028; Mon, 25 Sep 1995 23:05:05 -0700 From: Julian Elischer Message-Id: <199509260605.XAA09028@ref.tfs.com> Subject: Re: ports startup scripts To: peter@taronga.com (Peter da Silva) Date: Mon, 25 Sep 1995 23:05:04 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199509260347.WAA27526@bonkers.taronga.com> from "Peter da Silva" at Sep 25, 95 10:47:08 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1328 Sender: owner-hackers@freebsd.org Precedence: bulk > > > 1) Explicit (complex) numbering in the single directory > > Experience shows that the parenthetical (complex) is just not true. > > > 2) Mirrors of the "init.d" directory into other directories "rcN.d" > > with explicit numbering in those > > This is nice. > > > 3) Script to run from that directory to control order. > > That's where we are now. > > > 4) Control file. > > That's identical to #3. > > > #2 - You get whole directories of symlinks. Yuk. Lots of headaches. > > A name in a file is a symbolic link, too. Except it's harder to add. > > > #4 Works very simply. Ports can add one line to a config file, > > And where pray tell do they add the line? At the end? Then you might as > well go back to #1 except now they'll be in random order. And anywhere > else just doesn't bear thinking about. > > > Why complicate things? > > Dependencies on startup order. > use Make to start the system each module supplies a file that is included into the master makefile (which is generated..) echo "# Hi there.. This is Eddy your Shipboard Computer " >/tmp/boot.mk for i in /init.mk/* do echo ".include $i" >>/tmp/boot.mk done make -k -f /tmp/boot.mk :) -------------------------------- cat net.mk net: ifconfig .... nsfclient: net nfsiod -n 4 heh heh From owner-freebsd-hackers Mon Sep 25 23:10:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA13547 for hackers-outgoing; Mon, 25 Sep 1995 23:10:35 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id XAA13541 for ; Mon, 25 Sep 1995 23:10:32 -0700 Received: from puffin.pelican.com by pelican.com with smtp (Smail3.1.28.1 #5) id m0sxTDq-000K2pC; Mon, 25 Sep 95 23:10 WET DST Received: by puffin.pelican.com (Smail3.1.29.1 #9) id m0sxTDq-0000ReC; Mon, 25 Sep 95 23:10 PDT Message-Id: Date: Mon, 25 Sep 95 23:10 PDT From: pete@puffin.pelican.com (Pete Carah) To: hackers@freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: Sender: owner-hackers@freebsd.org Precedence: bulk In a note, Olof writes: >Cool! :-) Do they run FreeBSD at work, or just for themselves? ... >The question is probably wether the FreeBSD-market is big enough for an >own distribution or not. But there seems to be quite a few WWW-sites >running FreeBSD. Let's hope they aren't too few. :) The first answer is that there are a *lot* more linux sites than freebsd ones. linux is a bit less standardized, though... As to web servers, I run 2 at 2 ISPs for a total of 6 or 7 domains now (using the apache virtual-host trick with ifconfig alias). One of them is signing up folks weekly so I wonder how many aliases ifconfig is good for? They are both 32mb P5's that also run INN. So far they aren't overloaded and I suspect that I can't overload them even with both the web and INN on a single T1 feed (though one is getting another T1 pretty quick). (These sites aren't yet very popular but...) I don't know how many more web sites are freebsd-powered. I need to get the 'powered by freebsd' logo to tack on to some of these pages if it's allowed :-) -- Pete From owner-freebsd-hackers Mon Sep 25 23:11:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA13662 for hackers-outgoing; Mon, 25 Sep 1995 23:11:42 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA13656 for ; Mon, 25 Sep 1995 23:11:39 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id XAA00529 for ; Mon, 25 Sep 1995 23:11:36 -0700 Message-Id: <199509260611.XAA00529@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freefall.FreeBSD.org Subject: anyone got swIPe for FreeBSD? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Sep 1995 23:11:35 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk Tnks, Amancio From owner-freebsd-hackers Mon Sep 25 23:29:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA15498 for hackers-outgoing; Mon, 25 Sep 1995 23:29:31 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA15445 for ; Mon, 25 Sep 1995 23:29:03 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id CAA15855; Tue, 26 Sep 1995 02:31:31 -0400 Date: Tue, 26 Sep 1995 02:31:31 -0400 From: Coranth Gryphon Message-Id: <199509260631.CAA15855@healer.com> To: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: patl@asimov.volant.org > Coranth wrote: > |> It's a question of how much flexibility is going to be commonly used vs. > |> how much effort it take to implement each increase in flexibility. > Sorry, I don't buy the 'commonly used' argument. I could retire if I > had a dollar for every time I've cursed some anonymous engineer for > building something with gratituous limitations because he refused to More than granted :-) > |> But I agree that run-states are worth the effort. It gets us the most > |> for only a medium increase in difficulty. > Wow, a point of agreement! :-) I am willing to back down on things that are concrete points. Points made, points granted :-) The "my way is better/prettier/swoopier than yours" is an different type of argument (preference). And one I don't see either side winning. > [SysV method] is the simplest mechanism that provides equivalent power. I can't see any more power from a directory listing proving control order vs. a control file providing that order. They both have their plusses and minuses. > I'll happily abandon it if I'm presented with a better solution. But > loss of functionality simply to reduce the number of i-nodes used doesn't OK. Now we can actually cover some coherent points, that do not relate to personal preference in style. I say they have equivalent functionality. The only counter argument made so far is Terry's which talks about Union-FileSystem mounting to overlay files into the /etc/rc?.d directories (which makes me shudder at the thought). What functionality does the "rc?.d" sym-linked subdirs method gain over the control file model? > |> Each sub-system has it's own script. A control file determines what > |> gets run when. Or each sub-system has it's own script, and directory > |> ordering in a sym-linked tree determines which gets run when. > Right. And it is orders-of-magnititude safer to add a file to a directory > than to automatically insert a line at the right place in a control file. Ok. Something that appears to have been lost in one of my mail messages. I am not talking about the package install script editing the file itself. I am talking about it calling a command utility (written as part of the setup mechanism) which will do the editing. That reduces the risk by an order of magnitude, since the util knows about the format, and know what is and is not safe to do. All it needs to be told are dependances to take into account. > |> I don't care who invented it. I've looked at it, worked with it, > |> and don't agree with it. It's really that simple. > That's not the impression you leave from some of your other arguments. Then I'm sorry for not being clearer earlier. Everything in my life is build around a few simple concepts. First, that there are always more than one way to do something. Second, that just because you don't like one part of something, don't let that affect your views on other parts. Corrallary, if you like something, be careful about assuming you'll like all of it. Third, if it works, then it is right. Corallary, if it doesn't work, it's wrong, replace it. Finally, re-evaluate everything constantly, you might have missed something the first few times. At every point in this debate, I have re-examined the usefulness and aesthetics of what you (and others) have presented, as objectively as I can. Sometimes I came to different conclusions than in the past, but only if new information was added to the evaluation. > I just don't see any big difference in explicitness between a control > file and a file naming convention; especially when the filenames have > something as obvious as two digits in the first three positions. It's a matter of personal preference. |> I prefer to keep one copy of things, not two - even if they are links. > > So do I. But I'm willing to recognize when the extra link is worth it. > In this case, it improves clarity and power. To me, that's a clear win. That's the style difference. Subdir listing vs control files. I'm willing to be convinced. What does one gain over the other? > Especially since your method duplicates the information about what > is to be done - there is the script, and the entry in the control file. Granted. But I actually consider that a feature. The control file tell what has to be done, the scripts do it. > This leaves open the possibility that one will exist without > the other. (Ok, it's likely to be a pretty obvious problem. But Same problem in either version. If it is not in the control file (or the rc?.d subdir), it doesn't get run. If it is not an existing script, you get an error on startup. > I think we want an inittab in either case. The difference is in how many > entries it is expected to have, and whether it is likely to be modified > at each site. OK. But doesn't the "inittab" and "rc?.d" provide the same redundant information that you diskliked in the control file method? What does the "inittab" your proposing gain over just the "rc?.d" directories with numbers dictating script order? > We also want the individual service scripts to be the identical for > both methods. Definately. |> Details on how to best implement each them become unrelated discussions. |> Except that anything in common becomes part of the underlying foundation, |> so that only the differences are implemented in parallel. > It would be nice if there were enough cross-discussion that a standard > setup for one method could be automatically generated from the other; Definately. Two ways to do it. Either both are generated from a common database, or we have a translation tool that converts from one to the other. > releases. I suspect that it would be easier to generate control files > from the rc?.d setups than the other way around; but that would depend Yep. Going from subdirs to control file is easy, going the other way is harder since I do not keep track of explicit number, just relative order. > |> Each mechanism will have to have a means to automatically add config > |> information. These two will become subroutines of some overall tool > |> (called "pkg_init_setup" or whatever). > More complication for people doing ports; but probably not outrageously so. Actually, I see it as simpler :-) With this common tool, all they have to do is execute the utility and give it the relevant dependancy info (if any). It knows about everything else. Thus the packages and ports only need to know how to call it, and we can implement any later install/startup mechanism and only need to change this one utility. > |> Anything which can figure out the correct number to use for the script > |> name can figure out where to place itself in a file. If it can't, then > |> it can't and the argument become moot. > The sequence number can be static - built in when > the package was built. It is the same for all systems. The file editing > must be done dynamically at installation time, by examining and modifying > a file that is likely to be different at each site. Urk. OK, I misunderstood where the numbers are coming from. I assumed that the package would determine the numbers at the local system. That adds a lot to the shoulder of the ports/packages coordinator, but does solve all the problems with numbering sequences. Ok. We have another basic question here: I am hanging onto less information than you are, in that I am only keeping track of relative ordering, while you are keeping track of specific numbers. I can't see anything I'm loosing in not having the explicit numbers, aside from ease of translation back to your system. Am I missing something? |> So the numbers also become run levels (being how much we've started |> running). Great. Back to argument #1. :-) > I suppose you might think of them that way; but you'd probably be in the > minority. They are significant points within the sequence for a given > state. Points that other services are likely to be dependant upon. You That's what I consider run-levels: plateaus where a certain amount if system functionality is enabled. Anything else is what sets of additional things (mounted filesystems, daemons, subsystems) are run after that point. But the discrete points I don't think are likely to change. And we should agree on what goes into each, so that we remain compatible between the two implementations. > could go with levels instead of states, and make each of these significant > points a separate level. But you don't want that many levels, and you'd > have to re-number if a new one were ever added. (Or identified from No :-) You've got me convinced to go with run-states instead of levels, so I'll stay clear of this train... > |> correct point" if you are inserting into the middle of a process chain. > |> Which will probably be a very rare condition, unless you are replacing > |> one startup command with another, in which case the position is > |> already determined for you. > You're thinking in a box again. Do it this way, and I guarantee that > somebody will curse the makers of that decision for getting in the way Ok. I don't see how. Either it depends upon nothing (thus no problem), depends upon something with nothing depending upon it (again, simple), replaces something directly (still simple), or goes into the middle of a dependency chain. (which case requires most of the design sweat) I can't see any other case in an ordered system. |> Granted. Having things remove from a control file requires good |> solid coding. >Which you trust every maker of a package to do... (And it can still That's what the command util is for. All the package maker does is call that tool. > lose if the lines to be recognized have been hand-editted for any reason.) Granted. But a person with an editor will always be able to screw up an working configuration. What we have to do is make it such that they have no reason to hand-edit any files. |> If we automate things, we either do it right or we screw up a lot of things. |> That holds regardless of the automation procedure, or how the underlying |> layers are implemented. > No, it can work right -almost- all of the time. Which makes it all the > worse when it fails. Granted. The dangers come in two places - ports/packages that do not follow the setup requirements, and sysadmins editing things by hand. Or very complex packages, that require lots of system modifications to work. And finding ways to do that automatically. But those other modifications don't change regardless of which startup method we use. The question is: is there any fool-proof method, anywhere? Or do we just do the best we can, design to eliminate as many problems as we can forsee, and fix the others when they come up? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Mon Sep 25 23:40:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16092 for hackers-outgoing; Mon, 25 Sep 1995 23:40:11 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16087 for ; Mon, 25 Sep 1995 23:40:08 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id XAA09131; Mon, 25 Sep 1995 23:38:24 -0700 From: Julian Elischer Message-Id: <199509260638.XAA09131@ref.tfs.com> Subject: Re: ports startup scripts To: gary@palmer.demon.co.uk (Gary Palmer) Date: Mon, 25 Sep 1995 23:38:24 -0700 (PDT) Cc: jehamby@lightside.com, hackers@freebsd.org In-Reply-To: <2649.812092182@palmer.demon.co.uk> from "Gary Palmer" at Sep 26, 95 06:09:42 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3252 Sender: owner-hackers@freebsd.org Precedence: bulk > > In message , Jake Hamby write > s: > > As someone who has ``grown up'' around BSD derrivatives, I still > scratch my head when asked to work on a Solaris box. The sysV system is easy to understand once you realise that all it is is haveing a different rc file for each level SO if you want to go to level 3 you run rc3 simple.. that's all there is to it.. in rc3 you see f [ -d /sbin/rc3.d ]; then for f in /sbin/rc3.d/S* do if [ -s $f ]; then /sbin/sh $f start fi done fi now exactly how much work does that take to figure out..? It's simple.. it's elegant and it's DIFFICULT TO FUCK UP!! S01mountufs@ S03savecore@ S05paging@ S10recpasswd@ S20inet@ S21rc.project@ S22xns@ S30syslog@ S35named@ S40nfsmount@ S45preserve@ S50rmtmpfiles@ S52streams@ S55nfs@ S56amd@ S60sendmail@ S65inetd@ S66supfilesrv@ S67cron@ S68motd@ S69writesrv@ S70lpd@ S74uucp@ S75acct@ S85enlogin@ I'd prefer 3 digits.. it get's a bit crowded in palces with 2 It's So SIMPLE to see the order, and SO SIMPLE TO CHANGE I used to run my old 386BSD box with this (stolen straight from OSF1) (the next box across) it made adding packages so much simpler, and removing them was safe.. there was no chance of accidentally removing one line too many.. Even if we don't use Run levels, I still think we should addopt this scheme we can always tailor it with experience.. (add slightly different versions), add a /usr/local/init directory or whatever.. but let's get a start! most people acknowledge that having people editing /etc/rc is asking for problems.. > > There are several problems to be addressed (hopefully in a calm and > practical fashion. Who am I trying to kid? :-) ) The key to this > system working is that you just plop a file in a certain directory, > which will be run when the system is next booted (or shutdown - > WHATEVER). This leads to several problems that I can see: > > 1) Who issues these script ID numbers? We cannot let people go > claiming their own at random, as they *WILL* clash (even if we let > them loose on a number domain with 6 significant digits!) so what ? if they clash the get run at around the same time.. (dependig on alpha order) they will have put themselves after anything that they need to depend on.. that's all that matters! > > 2) Who is responsible for ensuring that they are in the correct order? > (e.g. something which loads a LKM is run *AFTER* the script to > mount /usr is run). This could potentially be nasty, as the > dependancy tree WILL vary over time (and even from machine to > machine). As SYSTEM items are in KNOWN POSITIONS in the sequence (e.g. starting the network is at 20 above,) then if you need neworking, any number above 20 will do.. > > 3) How will we cope with local alterations (e.g. someone running > locally developed s/w which is only for local use)? Do we leave > large gaps in the numbering to allow for local hacks? not so hard.. you'are unlikely to be dependent on something locally derived.. the rc.project entry above is a local addition. > > Am I missing something basic here? yes, the fact that it's basic > julian From owner-freebsd-hackers Tue Sep 26 00:00:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA17029 for hackers-outgoing; Tue, 26 Sep 1995 00:00:41 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA17004 for ; Tue, 26 Sep 1995 00:00:28 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id DAA15938; Tue, 26 Sep 1995 03:03:07 -0400 Date: Tue, 26 Sep 1995 03:03:07 -0400 From: Coranth Gryphon Message-Id: <199509260703.DAA15938@healer.com> To: peter@taronga.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Tue Sep 26 01:31:47 1995 Subject: Re: ports startup scripts To: terry@lambert.org (Terry Lambert) Date: Mon, 25 Sep 1995 23:27:44 -0500 (CDT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199509251847.LAA05564@phaeton.artisoft.com> from "Terry Lambert" at Sep 25, 95 11:47:11 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3035 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: peter@taronga.com (Peter da Silva) > Let's look at all the things that a package needs to get right to install... > 1. periodic cleanup scripts. > Cron does this pretty well, except that you need to give > each package its own user-id. Neither proposed startup handles this directly. It can be handled trivially if we can use the existing granularity and the new "daily/weekly" mechanism. > 2. startup/shutdown scripts. Either proposed method covers this. See other debate :-) > 3. tcp/ip port assignment. > This one is sticky. It's safe to append to /etc/services, > but not so safe to extract them. Granted. I'd actually like to see that as a seperate little command utility. With options to say "check for conflicts" or "ignore conflicts" or "prompt if conflicts" (just like "cp"). > 4. inetd-driven services. > Same problem as /etc/services. Since anything putting an entry into inetd probably has to add an entry into services, I'd make it part of the same (above #3) util. > 5. user and group ids, for things like news. > User-ids are hard to add. Group ids are harder. A > tool to do this would be helpful. We have "adduser" which just needs to be made a little smarter; or actually a tailored version which is a little dumber for doing non-user UIDs (like ftp, news, ...). > 6. setting up spool directories. > You don't want these to be under /usr/local. "mkdir /var/spool/NAME" ? > 7. setting up syslog entries. > See 3, 4, 5. Yep. Again, looks like the job for a new command tool. Why do I keep proposing new little command tools? So that people are not editing these files by hand. We end up with the same mechanism as password file (chpass, passwd, chsh, ...). > 9. device drivers Out of my range of expertise, so I won't offer advice. > 10. ... (/etc/daily???) Look at the new daily/weekly version. It's control file based (well, shrug, that's the way I like to build things :-) and pretty flexible. > There's a couple of basic ways to address this. You can have one directory > per package, with specially named files in them (/var/db/pkg could be a Actually, I agree with the concept some one came up with to move the DB info (ie. what packages are installed) to /usr/local/db as it is one of the few non-volatile things in /var. > Here's what I propose: > For each package, create a directory under /etc/package. Do we really need to keep this information after the package is installed? Well, yeah, for uninstall purposes. Grrfff. > After installing a package you use these files (from /etc/package/*) > to recreate: > /etc/rc.local > /etc/shutdown.local Whatever startup/shutdown model we go with... > /var/cron/tabs/* Another non-volatile thing that should be moved out of /var So /etc/cron/... > /dev/MAKEDEV > /sys/i386/conf/LINT These never need to be undone, unless you care about left-over clutter. But with the new-install rate (average 2 new releases a year) I don't think it'll be a problem. > /sys/i386/conf/GENERIC But then it's not GENERIC. Besides, just how much are we willing to automate the install process? I think there comes a point (and kernel rebuilding should be on the other side of that line) where we either do everything for them, or tell them how to do it an let them do it themselves. A lot of other operatins sytems (SCO comes to mind) has the "package_add" super util that does everything, including kernel rebuilds. If we want to do that automated, make it one big intelligent tool (even if most of what it does it call all the little tools we already built above :-) > /etc/passwd (for uid<1000) > /etc/passwd.master (for uid<1000) "adduser" and "deluser" should be sufficient, with little or no modification, except as mentioned above. > /etc/group Always wondered why there weren't equivalent tools for the groups file. > /etc/inetd.conf > /etc/syslog.conf > /etc/services As mentioned above.... > /etc/ttys I guess, for packages that sit an listen on serial lines. But again, unless we go for the "do-everything" util, how much do we want to automate? > This would work better than the current scheme, and better than > System V, and doesn't need symlinks. *And* the existing package scheme > works with it... Ok. We never edit the original master file. Just rebuild the startup list from the packages (like "whatis" is rebuild from the manpages). That's neat. > This lets the BSD people use the files they're familiar with, but > the files the system uses are secondary... they're rebuilt from packages. Actually, we can implement either the control file mechanism or the rcN.d subdir mechanism on top of this cleanly, since either is now just generated information... Ya think? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 00:03:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA17623 for hackers-outgoing; Tue, 26 Sep 1995 00:03:18 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA17612 for ; Tue, 26 Sep 1995 00:03:16 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id AAA09174; Tue, 26 Sep 1995 00:02:23 -0700 From: Julian Elischer Message-Id: <199509260702.AAA09174@ref.tfs.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 00:02:23 -0700 (PDT) Cc: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com, hackers@FreeBSD.ORG In-Reply-To: <199509260631.CAA15855@healer.com> from "Coranth Gryphon" at Sep 26, 95 02:31:31 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2661 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I can't see any more power from a directory listing proving control > order vs. a control file providing that order. > > They both have their plusses and minuses. > > What functionality does the "rc?.d" sym-linked subdirs method gain over > the control file model? directory editing operations are designed to be atomic to an item editing a file is a much more complex operation, particularly INSERTING something into the right place, assuming that you have no human doing it.. (not saying impossible, but ln -s ../sbin/init.d/foobar S56foobar is a LOT simpler to impliment than a program that runs through a file looking for the correct place to insert things.. The only other simple way of doing it would be: echo "S56 foobar" >> startfile and on startup.. files=`sort > > |> Each sub-system has it's own script. A control file determines what > > |> gets run when. Or each sub-system has it's own script, and directory > > |> ordering in a sym-linked tree determines which gets run when. > > > Right. And it is orders-of-magnititude safer to add a file to a directory > > than to automatically insert a line at the right place in a control file. boy was this ever correct > > Ok. Something that appears to have been lost in one of my mail messages. > I am not talking about the package install script editing the file > itself. I am talking about it calling a command utility (written > as part of the setup mechanism) which will do the editing. great until someone edits it by hand during an emergency.. "I had to do it to get the system up" > I think a slightly simpified version is SIMPLER than the BSD system once you think about adding packages > > > I think we want an inittab in either case. The difference is in how many > > entries it is expected to have, and whether it is likely to be modified > > at each site. > > OK. But doesn't the "inittab" and "rc?.d" provide the same redundant > information that you diskliked in the control file method? I seen inittab annd init.d as two ORTHOGONAL items.. you can have init.d even with only one run-level inittab is just a generalisation of /etc/ttys, (or put another way, /etc/ttys is a crippled inittab. > > What does the "inittab" your proposing gain over just the "rc?.d" > directories with numbers dictating script order? the two are orthogonal issues. we can discuss tehm separatly! > > > We also want the individual service scripts to be the identical for > > both methods. > > Definately. YES > > From owner-freebsd-hackers Tue Sep 26 00:09:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18825 for hackers-outgoing; Tue, 26 Sep 1995 00:09:06 -0700 Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA18760 for ; Tue, 26 Sep 1995 00:08:49 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <10751-0@bunyip.cc.uq.oz.au>; Tue, 26 Sep 1995 17:08:13 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA23622 for ; Tue, 26 Sep 1995 17:13:14 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA06814 for ; Tue, 26 Sep 1995 07:15:42 GMT Message-Id: <199509260715.HAA06814@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.2 7/18/95 To: hackers@freebsd.org Subject: Garden's Point Modula2 for FreeBSD! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Sep 1995 17:15:41 +1000 From: Stephen Hocking Sender: owner-hackers@freebsd.org Precedence: bulk ------- Forwarded Message Received: from pandora.devetir.qld.gov.au by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA06789 for ; Tue, 26 Sep 1995 07:13:05 GMT Received: from bunyip.cc.uq.oz.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with MHSnet id RAA22966 for sysseh; Tue, 26 Sep 1995 17:00:45 +1000 Received: from typhoon.dstc.qut.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Tue, 26 Sep 1995 16:54:49 +1000 Received: (from majordom@localhost) by typhoon.dstc.qut.edu.au (8.6.12/8.6.10) id QAA20336 for gpm-outgoing; Tue, 26 Sep 1995 16:34:08 +1000 Received: (from lederman@localhost) by typhoon.dstc.qut.edu.au (8.6.12/8.6.10) id QAA20405 for gpm@dstc.qut.edu.au; Tue, 26 Sep 1995 16:34:06 +1000 From: Jeff Ledermann Message-Id: <199509260634.QAA20405@typhoon.dstc.qut.edu.au> Subject: * Announcement * To: gpm@dstc.qut.edu.au Date: Tue, 26 Sep 1995 16:34:06 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3359 Sender: owner-gpm@dstc.qut.edu.au Precedence: bulk Reply-To: gpm@dstc.qut.edu.au Announcing GPM for FreeBSD and new releases for DJGPP and EMX. File locations: ftp.fit.qut.edu.au:/pub/gpm ftp.psg.com:/pub/modula-2/gpm WEB Site: http://www.fit.qut.edu.au/CompSci/PLAS/GPM/ GPM-FreeBSD The FreeBSD version is yet another port of the Linux version of GPM. It is completely compatible with the Linux version in all respects. Refer to the Linux installation and release notes for any version specific information. GPM-Linux I've uploaded a new version "modula-sep95.tar.gz" but it simply consolidates the 4 "fixes", so existing users need not bother getting a new copy. GPM-DJGPP This version was compiled in a DOS window under Windows 95. GPM seems to work perfectly including handling long filenames. GPM-EMX This version was compiled under Warp. GPM works identically as under OS/2 2.1. The ISO I/O libraries are now integrated with the standard libraries as with other versions of GPM. BUG FIXES The "Out of Channels" problem after 50 Close's (RndFile & StreamFile) reported by Joerg Haas (Joerg_Haas@ac3.maus.de) has been fixed. 16-bit subrange comparisons were in some cases producing incorrect code (the compare was the wrong way around) Also an incorrect peephole optimisation was creating an erroneous overflow check which could cause a spurious overflow trap. These problems were reported by Claas Rink (honegger@amtrash.comlink.de) and were fixed in the Linux fix03. (fix04 was required for a bug in fix03) The compiler distributions have been placed into sub-directories by operating environment. The files in each sub-directory are prefixed by the language. Pick up the most recent one unless you have some reason to want an older one. Note that the GPM Oberon-2 distribution requires files from the Modula-2 compiler, so you'll need to down-load the modula- files as well for Oberon. README 13-Jul-95 13:57 9K README.gpmpc 13-Jul-95 13:57 5K SUPPORT.DOC 13-Jul-95 13:57 2K djgpp/ modula-jun95.zip 13-Jul-95 13:59 1.1M modula-sep95.zip 21-Sep-95 10:31 1.2M emx/ modula-may95.zip 13-Jul-95 13:59 846K modula-sep95.zip 20-Sep-95 14:20 793K oberon-may95.zip 13-Jul-95 13:59 393K freeBSD/ modula-sep95.tar.gz 25-Sep-95 14:50 730K gpmpc/ modula-aug95.zip 18-Aug-95 07:49 762K modula-mar95.zip 13-Jul-95 13:59 670K linux/ modula-sep95.tar.gz 21-Sep-95 14:15 691K oberon-apr95-fix01.tar.gz 12-Sep-95 09:39 109K oberon-apr95.tar.gz 13-Jul-95 14:00 362K manuals/ modula.ps.zip 13-Jul-95 14:00 627K modula.tex.zip 13-Jul-95 14:00 276K oberon.ps.zip 13-Jul-95 14:00 225K oberon.tex.zip 13-Jul-95 14:00 100K release-notes/ gpmpc.ps.zip 13-Jul-95 14:01 121K modula.ps.zip 13-Jul-95 14:01 122K modula.tex.zip 13-Jul-95 14:01 45K oberon.ps.zip 13-Jul-95 14:01 22K oberon.tex.zip 13-Jul-95 14:01 2K Enjoy. - --- Jeffrey Ledermann lederman@dstc.qut.edu.au http://www.dstc.qut.edu.au/~lederman/ _--_|\ Faculty of Information Technology / QUT Queensland University of Technology \_.--._/ Box 2434 Brisbane 4001 AUSTRALIA v Ph: +61 7 3864 5337 Fax: +61 7 3864 1282 ------- End of Forwarded Message I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-hackers Tue Sep 26 00:19:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA20912 for hackers-outgoing; Tue, 26 Sep 1995 00:19:44 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA20898 for ; Tue, 26 Sep 1995 00:19:40 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA20744 (5.67a/IDA-1.5 for hackers@freebsd.org); Tue, 26 Sep 1995 02:03:37 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id BAA02006 for hackers@freebsd.org; Tue, 26 Sep 1995 01:20:43 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260620.BAA02006@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Tue, 26 Sep 1995 01:20:43 -0500 (CDT) In-Reply-To: <199509260558.WAA11542@aslan.cdrom.com> from "Justin T. Gibbs" at Sep 25, 95 10:58:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 237 Sender: owner-hackers@freebsd.org Precedence: bulk > Actually, they have an exported API that all programs use to alter the > congifuration info (whether it be in the registry or .ini files). Well, *some* programs use it. Some programs that have Windows and UNIX versions do it by hand. From owner-freebsd-hackers Tue Sep 26 00:25:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA21399 for hackers-outgoing; Tue, 26 Sep 1995 00:25:59 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA21393 for ; Tue, 26 Sep 1995 00:25:53 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id DAA16029; Tue, 26 Sep 1995 03:28:44 -0400 Date: Tue, 26 Sep 1995 03:28:44 -0400 From: Coranth Gryphon Message-Id: <199509260728.DAA16029@healer.com> To: hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Tue Sep 26 02:02:06 1995 From: peter@taronga.com (Peter da Silva) Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 00:08:24 -0500 (CDT) In-Reply-To: <199509260343.XAA14628@healer.com> from "Coranth Gryphon" at Sep 25, 95 11:43:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 693 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > +> It's not that SysV confuses me, it's that I think it is a LOUSY DESIGN. > +> Personal opinion, which is a matter of a lot of experience. I've been > Argument from authority? > I've been doing it for 15 years, including working on the 4.1C and 4.2 BSD > distributions, and I *hate* anything that depends on editing config files No, re-assertion that it ia a matter of personal preference. I'm not telling you what to like or dislike... > The only system I've seen that has worked with autoedited files... and > this will really make you cringe... is Microsoft Windows. Their config Since we are going with what works... :-) Actually, the samba config files have the exact same format as the MS-Windows config files. It is a well-known and simple format. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 00:30:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA21692 for hackers-outgoing; Tue, 26 Sep 1995 00:30:56 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA21681 for ; Tue, 26 Sep 1995 00:30:50 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id DAA16047; Tue, 26 Sep 1995 03:33:42 -0400 Date: Tue, 26 Sep 1995 03:33:42 -0400 From: Coranth Gryphon Message-Id: <199509260733.DAA16047@healer.com> To: jdl@chromatic.com Subject: Re: ports startup scripts Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk From: Jon Loeliger > Well, I think these issues point to the more generalized problem > of simply representing the "dependency graph". All of the file number Yep. The underlying framework is the same, it comes down to how to control sequence. > Can we have a more abstract representation of that dependency graph? > Then, either at like, install or boot time (ick) a topological sort is > done on the graph and the script/script-fragment is linearly ordered Interesting. > The algorithm is data driven based on package parts supplied during > the install and a well-defined although not necessarily unique ordering Solves a lot of the static config issues. > There are issues here still, like, how do you state dependencies against > things that have yet to be invented? I think that's why fictitious or > virtual nodes may be needed in the graph too. They can essentially > arbitrarily represent the "levels" or "states" in the graph where > certain properties are available ("NFS", "LAN", "WAN", "Single User"). Solves the dependencies problems if a specification can be coded. > Tip-toeing back out of the warzone, Nope, get back in here :-) This sounds like a really good idea. So, how would you go about implementing such a dependency graph? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 00:37:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA22215 for hackers-outgoing; Tue, 26 Sep 1995 00:37:52 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA22208 for ; Tue, 26 Sep 1995 00:37:40 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id DAA16072; Tue, 26 Sep 1995 03:40:18 -0400 Date: Tue, 26 Sep 1995 03:40:18 -0400 From: Coranth Gryphon Message-Id: <199509260740.DAA16072@healer.com> To: julian@ref.tfs.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk From: Julian Elischer > use Make to start the system I like this idea. It also solves the dependency problem. Can a make file 'include' be set to take in anything with a given extension (a la ".INCLUDE *.startup.mk")? > echo "# Hi there.. This is Eddy your Shipboard Computer " >/tmp/boot.mk > for i in /init.mk/* > do > echo ".include $i" >>/tmp/boot.mk > done > make -k -f /tmp/boot.mk Or we just go back to the control file concept (:-), but have it be a makefile, so depenencies are simple (and no longer file order specific). -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 00:44:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA22511 for hackers-outgoing; Tue, 26 Sep 1995 00:44:57 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA22506 for ; Tue, 26 Sep 1995 00:44:54 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id AAA16225; Tue, 26 Sep 1995 00:44:43 -0700 Date: Tue, 26 Sep 1995 00:44:43 -0700 Message-Id: <199509260744.AAA16225@silvia.HIP.Berkeley.EDU> To: jdl@chromatic.com CC: hackers@freebsd.org In-reply-to: <199509260541.AAA04042@chrome.jdl.com> (message from Jon Loeliger on Tue, 26 Sep 1995 00:41:18 -0500) Subject: Re: ports startup scripts From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk I thought I was completely lost in this discussion, until this article hit me like a lightning bolt.... * From: Jon Loeliger * Well, I think these issues point to the more generalized problem * of simply representing the "dependency graph". All of the file number * schemes and the single control file schemes are implementations of * the general concepts of linearizing a dependency graph. Yes, *dependency graphs*! This was what we were all arguing about! And the Unix way of handling dependency graphs are...yes, "make"! Can it get any simpler than an /etc/rc.d/Makefile?!? :) Ok, so who's going to write bsd.rc.mk? (Me? :) Satoshi From owner-freebsd-hackers Tue Sep 26 00:49:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA22712 for hackers-outgoing; Tue, 26 Sep 1995 00:49:57 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id AAA22702 for ; Tue, 26 Sep 1995 00:49:50 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA20997 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 26 Sep 1995 02:49:09 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id CAA03239 for hackers@FreeBSD.ORG; Tue, 26 Sep 1995 02:33:46 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509260733.CAA03239@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 02:33:45 -0500 (CDT) In-Reply-To: <199509260703.DAA15938@healer.com> from "Coranth Gryphon" at Sep 26, 95 03:03:07 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2848 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 6. setting up spool directories. > > You don't want these to be under /usr/local. > "mkdir /var/spool/NAME" ? mkdir $SPOOL_PREFIX/$PACKAGE_NAME > Do we really need to keep this information after the package is > installed? Sure. Every time you install a new package. Why? Because you regenerate the whole thing every time, rather than edit it. The *master* copies are in /etc/packages. And you rebuild all these files the same way for the sake of consistency. > Well, yeah, for uninstall purposes. Grrfff. Right. You uninstall by removing the package files, and rebuilding. > But then it's not GENERIC. OK, call it CURRENT. > Besides, just how much are we willing > to automate the install process? I think there comes a point > (and kernel rebuilding should be on the other side of that line) > where we either do everything for them, or tell them how to do > it an let them do it themselves. Kernel rebuilding on System V *is* automatic, and it works. The problem is their packaging is rather higgledypiggledy. Keeping this stuff in a common tree is much nicer. > A lot of other operatins sytems (SCO comes to mind) has the "package_add" > super util that does everything, including kernel rebuilds. If we want to > do that automated, make it one big intelligent tool (even if most of what > it does it call all the little tools we already built above :-) That's the scenario I'm talking about. Except I'm trying to avoid making the tool any smarter than it has to be, because the smarter it is the easier it is to break. It's pretty hard to break "concatenate these files". That's why I don't want to use "adduser". But see below... > > /etc/inetd.conf > > /etc/syslog.conf > > /etc/services > As mentioned above.... How do you upgrade if you never remove anything? What if I remove cern httpd and install apache? > I guess, for packages that sit an listen on serial lines. > But again, unless we go for the "do-everything" util, how > much do we want to automate? As much as we can without having too many special cases. So far I don't think I've got any... oh yes, there's the password file. If it's a special case anyway we can have "adduser" and "deluser" in install and remove. > Actually, we can implement either the control file mechanism or the > rcN.d subdir mechanism on top of this cleanly, since either is now > just generated information... Of course. I don't care if you build the control file from the rcN.d files otherwise. Just so long as it's generated. Generating files from base+extensions is easy. Editing files is hard, especially when they don't have consistent formats. I kinda like the idea of having /etc/rc.mk, run by "make". That way the individual startup files have complete dependency information, *and* if you fuck up and remove something that's dependant it can tell you. From owner-freebsd-hackers Tue Sep 26 02:13:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA27600 for hackers-outgoing; Tue, 26 Sep 1995 02:13:33 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA27592 for ; Tue, 26 Sep 1995 02:13:24 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA21688; Tue, 26 Sep 1995 02:13:18 -0700 To: Peter da Silva cc: hackers@freebsd.org Subject: Re: Problems with packages, and general third party software. In-reply-to: Your message of "Mon, 25 Sep 1995 13:54:21 PDT." <199509252054.NAA21624@freefall.freebsd.org> Date: Tue, 26 Sep 1995 02:13:17 -0700 Message-ID: <21685.812106797@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > One problem with installing things from packages is you don't get any > convenient pointer to how to configure them. For example, if I hadn't > already installed amanda on our system, I'd have no idea what to put > in /etc/inetd.conf and /etc/services. Looking through what the package > installs there's really not enough to install it. I think that packages have to come with smarter installation scripts is all. I'd originally envisioned things that way, but it appears that very few people really use the install scripts for more than whapping perms and asking simplistic questions. Jordan From owner-freebsd-hackers Tue Sep 26 02:14:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA27650 for hackers-outgoing; Tue, 26 Sep 1995 02:14:39 -0700 Received: from risc6.unisa.ac.za (risc6.unisa.ac.za [163.200.97.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA27616 for ; Tue, 26 Sep 1995 02:13:40 -0700 Received: by risc6.unisa.ac.za (AIX 3.2/UCB 5.64/4.03) id AA51193; Tue, 26 Sep 1995 11:12:23 +0200 From: radova@risc6.unisa.ac.za (A. Radovanovic) Message-Id: <9509260912.AA51193@risc6.unisa.ac.za> Subject: SLIP and DNS problem To: hackers@freebsd.org Date: Tue, 26 Sep 1995 11:12:23 +0200 (USAST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 447 Sender: owner-hackers@freebsd.org Precedence: bulk I have 8 modems connected to my BSD system. From time to time, after login, the SLIP client can't get host name resolved, or can't get it resolved on some of the lines. When I reboot the machine everything is OK for some time. It seems that the server doesn't know the client's IP. I think that the DNS works fine - it resolves names, answers ping, ftp, www, telnet,... I'll appreciate it very much if somebody can give me a clue. Regards, Alex From owner-freebsd-hackers Tue Sep 26 02:17:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA27780 for hackers-outgoing; Tue, 26 Sep 1995 02:17:17 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA27775 for ; Tue, 26 Sep 1995 02:17:09 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA21713; Tue, 26 Sep 1995 02:15:47 -0700 To: Matt Thomas cc: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-reply-to: Your message of "Mon, 25 Sep 1995 10:13:56 -0000." <199509251014.KAA06744@whydos.lkg.dec.com> Date: Tue, 26 Sep 1995 02:15:46 -0700 Message-ID: <21711.812106946@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > However BSD/OS 2.0 doesn't have dlopen or dlsym either. From the 2.0 > slicc man page: YIKES! That's what I get for making assumptions, eh? I just figured since they had shared libs.. Oh geeze. I guess I'd better get back to the Netscape folks, thanks! Jordan From owner-freebsd-hackers Tue Sep 26 02:43:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA28406 for hackers-outgoing; Tue, 26 Sep 1995 02:43:00 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA28401 for ; Tue, 26 Sep 1995 02:42:54 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id CAA21836; Tue, 26 Sep 1995 02:41:41 -0700 To: Terry Lambert cc: kelly@fsl.noaa.gov (Sean Kelly), gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts In-reply-to: Your message of "Mon, 25 Sep 1995 15:34:10 PDT." <199509252234.PAA06011@phaeton.artisoft.com> Date: Tue, 26 Sep 1995 02:41:41 -0700 Message-ID: <21833.812108501@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > The UNIX desktop was not "lost", it was "conceded without a fight". (dah de dum) "You say potatoe, I say potato - let's call the whole thing off!" (dah doe dat dee dee root-ta-toot oh yeah! smokin!) Jordan From owner-freebsd-hackers Tue Sep 26 03:00:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA29088 for hackers-outgoing; Tue, 26 Sep 1995 03:00:35 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA29063 for ; Tue, 26 Sep 1995 03:00:07 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id KAA03497 ; Tue, 26 Sep 1995 10:52:01 +0100 To: "Jordan K. Hubbard" cc: hackers@freebsd.org Subject: Re: Problems with packages, and general third party software. In-reply-to: Your message of "Tue, 26 Sep 1995 02:13:17 PDT." <21685.812106797@time.cdrom.com> Date: Tue, 26 Sep 1995 10:52:00 +0100 Message-ID: <3495.812109120@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@freebsd.org Precedence: bulk In message <21685.812106797@time.cdrom.com>, "Jordan K. Hubbard" writes: >I think that packages have to come with smarter installation scripts is >all. I'd originally envisioned things that way, but it appears that >very few people really use the install scripts for more than whapping >perms and asking simplistic questions. AMANDA can be a lot smarter (as the porter, I am well aware that it is not the best possible use of pkg_add), but amanda can not be installed without a lot of config file editing anyhow (disk lists, tape configs, etc). Adding stuff to /etc/services and /etc/inetd.conf is something I'd rather leave to the end user as they are really site-specific (especially with AMANDA where the port number is not assigned but chosen by the site admin) Sure, a quick /bin/sh script could do it, but I don't think I want to do that level of config file munging. If nothing else, I got a call from someone yesterday who had re-run sysinstall to try and write out bteasy again (they had had to re-install Win95 after it had eaten itself), and ended up with an /etc which (to quote them): had a junk /etc/services (it only had ftp in it), and most of the perms were wrong. This sort of stuff makes me want to leave /etc WELL ALONE. Gary From owner-freebsd-hackers Tue Sep 26 03:04:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA29220 for hackers-outgoing; Tue, 26 Sep 1995 03:04:22 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA29214 for ; Tue, 26 Sep 1995 03:04:16 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id DAA21917; Tue, 26 Sep 1995 03:01:55 -0700 To: Terry Lambert cc: kelly@fsl.noaa.gov (Sean Kelly), gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts In-reply-to: Your message of "Mon, 25 Sep 1995 15:34:10 PDT." <199509252234.PAA06011@phaeton.artisoft.com> Date: Tue, 26 Sep 1995 03:01:55 -0700 Message-ID: <21914.812109715@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Jordan is wrong. I was in the meeting in the conference room in Sandy, > Utah when Kanwahl Rheki "gave way" the UNIX destop. > > The UNIX desktop was not "lost", it was "conceded without a fight". By the way, getting perfectly serious here for a moment, I don't particularly think you're right either. The fight was hardly "conceded", It *was* lost, and lost through sheer incompetence! You know how I like to compare the UNIX world to the Three Stooges trying to fix a leaky faucet? Nobody actually works on the faucet throughout the entire episode - they're too wrapped up in seeing who can poke the other the most times in the eye. Well, that's how the UNIX world has looked from an ISV's perspective for a LONG time! Who do you think *writes* the bloody desktop apps? The ISVs. Do you think that we at Lotus, for example, were overjoyed at the prospect of doing entirely separate and laborious ports of NOTES, 1-2-3 and AmiPro to everthing from SunOS to HP/UX? No, we weren't. We were stuck doing 6 different platforms, in fact, all of which were majorly different from one another! It was the polar opposite of fun! And we were the bloody UNIX *experts* of the company! You can only imagine how it looked from everyone else's perspective. The occasional VP would stroll through and see this workgroup filled with literally several million dollars worth of top end HP, IBM and Sun hardware and they'd look at this little engineering group full of very highly paid engineers (we were rare!) and they'd sort of shake their heads and say "you need ALL this stuff to service a market 1/10th the size of OS/2 or Windows?" And we'd say "yup! pretty #%&@*! stupid, ain't it!" Bitter? Oh, not us. We wanted MORE versions of UNIX. Binary compatibility? Heck no! Crazy ideas like that only let us stay home with our families on the weekends! Needless to say, this was not an unusual attitude among the other ISVs who provided you with everything from Framemaker to Adobe Photoshop and THAT is why UNIX lost, yes lost, the desktop market. UNIX was a highly dysfunctional family that fought so long and hard that the children were finally taken away by social services. Jordan From owner-freebsd-hackers Tue Sep 26 03:56:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA00987 for hackers-outgoing; Tue, 26 Sep 1995 03:56:43 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA00982 for ; Tue, 26 Sep 1995 03:56:39 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id DAA20129; Tue, 26 Sep 1995 03:56:37 -0700 Date: Tue, 26 Sep 1995 03:56:37 -0700 Message-Id: <199509261056.DAA20129@silvia.HIP.Berkeley.EDU> To: hackers@freebsd.org In-reply-to: <199509231935.VAA22521@uriah.heep.sax.de> (message from J Wunsch on Sat, 23 Sep 1995 21:35:19 +0200 (MET DST)) Subject: Re: multiple mail messages From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk J writes: * The question has been (erroneously) sent to two lists in parallel in * the first place. Nobody bothered to drop one of the lists from the * Cc. Just in case you all forgot, I was the person who sent out the original message. I posted it to both hackers and ports, and clearly labeled it as such and recommended that ensuing discussion take place in ports. Draw your own conclusions on who is to blame. :) Satoshi From owner-freebsd-hackers Tue Sep 26 04:57:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA02010 for hackers-outgoing; Tue, 26 Sep 1995 04:57:23 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA02005 for ; Tue, 26 Sep 1995 04:57:18 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id MAA08215; Tue, 26 Sep 1995 12:56:33 +0100 Date: Tue, 26 Sep 1995 12:56:32 +0100 (MET) From: Olof Johansson To: hackers@freebsd.org Subject: vgalib for FreeBSD! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hello, A couple of months ago someone mentioned that he/she had ported an old vgalib from linux to FreeBSD. I'd like to know how old that version was, and how much work it'd be to port the latest version. :) Whoever it was, please contact me. -Olof From owner-freebsd-hackers Tue Sep 26 05:10:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA02245 for hackers-outgoing; Tue, 26 Sep 1995 05:10:29 -0700 Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA02131 for ; Tue, 26 Sep 1995 05:08:14 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (134.100.239.2) with smtp id ; Tue, 26 Sep 95 13:06 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-hackers@FreeBSD.ORG id ; Tue, 26 Sep 95 13:06 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA13081; Tue, 26 Sep 95 13:04:17 +0100 Date: Tue, 26 Sep 95 13:04:17 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9509261204.AA13081@wavehh.hanse.de> To: cstruble@vt.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Objective C Newsgroups: hanse-ml.freebsd.hackers References: <199509260315.XAA04532@quirk.com> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In hanse-ml.freebsd.hackers you write: >Well, I saw a discussion a while ago, but it seemed without >resolution. I'm very interested in getting Objective C working on >FreeBSD, but so far have been unable to get anywhere. >I compiled gcc 2.7.0 and everything seemed to compile fine. I then >tried to build libobjects-0.1.14 and the test programs. All the >test programs fail with a core dump (floating point exception) in >libobjc.a, the Objective C runtime library. It seems to be a problem >with __builtin_return(), but my compiler knowledge is a bit lacking >so I can't figure out exactly what is wrong. >Has anyone gotten any Objective C programs to work on FreeBSD? If so, >what magic incantations do I have to perform to get them to run? The problem is that FreeBSD does not use IEEE exceptions. Division by zero etc. (that result in NaN or other special IEEE numbers on other machines) will raise the SIGFPE signal, which by default causes a core dump. Linux has the same problem. You can solve it at Linux using -lieee. NetBSD uses full IEEE semantic as does any workstation I have. I don't know the correct FreeBSD solution, since nothing like -lieee seems to exist. Maybe I overlooked the right way to solve this in FreeBSD. Anyway, in the meantime, to run ObjC programs, you can ignore the signal, ObjC message dispatch works nothingtheless. I don't know why gcc-2.7.0 partly produces exceptions and earlier versions did not. At the beginning of your source file: #ifdef __FreeBSD__ #include #endif /* __FreeBSD__ */ Somewhere: #ifdef __FreeBSD__ void signal_dummy(int nix) {}; #endif /* __FreeBSD__ */ At the beginning of the program, before any ObjC message call: #ifdef __FreeBSD__ signal(SIGFPE,signal_dummy); #endif /* __FreeBSD__ */ Note that FP exception (division by zero etc.) will not longer cause your program to terminate, but will result in "0". Since the corrent behaviour is to produce 'NaN' anyway, I find it unlikely that you'll find a program that worked on FreeBSD and will no longer work with this ignored signal. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer . No NeXTMail, please. Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a private address. At (netless) work programming in data analysis. From owner-freebsd-hackers Tue Sep 26 05:51:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA02859 for hackers-outgoing; Tue, 26 Sep 1995 05:51:46 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA02854 for ; Tue, 26 Sep 1995 05:51:43 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA22545 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 26 Sep 1995 07:43:08 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA08257 for hackers@FreeBSD.ORG; Tue, 26 Sep 1995 07:32:54 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509261232.HAA08257@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 07:32:53 -0500 (CDT) In-Reply-To: <199509260751.DAA16119@healer.com> from "Coranth Gryphon" at Sep 26, 95 03:51:52 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 478 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Granted. We have ease of adding something vs. complexity of the overall > structure. Complexity of the overall structure is identical in both cases. You have a directory containing files and an ordered execution list for those files. > Would you consider it easy to fix if they renumbered all the scripts in > the rc3.d directory? That's a lot less likely than moving things around in a file, since it's easier to do. It's almost impossible to accidentally renumber files. From owner-freebsd-hackers Tue Sep 26 05:51:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA02884 for hackers-outgoing; Tue, 26 Sep 1995 05:51:53 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA02872 for ; Tue, 26 Sep 1995 05:51:50 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA22541 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 26 Sep 1995 07:42:56 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA08127 for hackers@FreeBSD.ORG; Tue, 26 Sep 1995 07:28:25 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509261228.HAA08127@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 07:28:25 -0500 (CDT) In-Reply-To: <199509260728.DAA16029@healer.com> from "Coranth Gryphon" at Sep 26, 95 03:28:44 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 718 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > The only system I've seen that has worked with autoedited files... and > > this will really make you cringe... is Microsoft Windows. Their config > Actually, the samba config files have the exact same format as the > MS-Windows config files. It is a well-known and simple format. Since Samba is designed to interface with Microsoft Windows, that's not surprising. I really hate the conceptual integrity problems in the INI files. NAME = VALUE NAME = NEW-VALUE In every other "language" in computer science this would be equivalent to NAME = NEW-VALUE But because of them discovering after the fact that they needed to sequence events, it may or may not be. This violates the principle of least surprise. From owner-freebsd-hackers Tue Sep 26 06:06:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03264 for hackers-outgoing; Tue, 26 Sep 1995 06:06:09 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAB03255 for ; Tue, 26 Sep 1995 06:06:06 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA06520; Tue, 26 Sep 95 13:06:03 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA14836; Tue, 26 Sep 1995 07:06:01 -0600 Date: Tue, 26 Sep 1995 07:06:01 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509261306.AA14836@emu.fsl.noaa.gov> To: jdl@chromatic.com Cc: gary@palmer.demon.co.uk, hackers@freebsd.org In-Reply-To: <199509260541.AAA04042@chrome.jdl.com> (message from Jon Loeliger on Tue, 26 Sep 1995 00:41:18 -0500) Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "Jon" == Jon Loeliger writes: Jon> Well, I think these issues point to the more generalized Jon> problem of simply representing the "dependency graph". That suggests to me that our startup ought to be driven by make and not sh, then. But then there's the problem of auto-editing Makefiles. Maybe we can auto-edit Imakefiles more safely? -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA When I go, I'm flying Air Bizarre. It's a good airline. You buy a one way round trip ticket. You leave any Monday, and they bring you back the previous Friday... That way you still have the weekend. -- Steven Wright From owner-freebsd-hackers Tue Sep 26 06:16:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03804 for hackers-outgoing; Tue, 26 Sep 1995 06:16:25 -0700 Received: from spot.lodgenet.com (lodgenet.iw.net [204.157.148.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03767 for ; Tue, 26 Sep 1995 06:14:44 -0700 Received: from tserv.lodgenet.com (root@tserv.lodgenet.com [204.124.120.10]) by spot.lodgenet.com (8.6.12/8.6.12) with ESMTP id CAA24004; Tue, 26 Sep 1995 02:52:57 -0500 Received: from jake.lodgenet.com (jake.lodgenet.com [204.124.120.30]) by tserv.lodgenet.com (8.6.12/8.6.12) with ESMTP id IAA16158; Tue, 26 Sep 1995 08:14:44 -0500 Received: from localhost (localhost [127.0.0.1]) by jake.lodgenet.com (8.6.12/8.6.9) with SMTP id IAA15175; Tue, 26 Sep 1995 08:21:08 -0500 Message-Id: <199509261321.IAA15175@jake.lodgenet.com> X-Authentication-Warning: jake.lodgenet.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: hm@altona.hamburg.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: LKM example device driver available In-reply-to: Your message of "Mon, 25 Sep 1995 19:09:09 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Sep 1995 08:21:08 -0500 From: "Eric L. Hernes" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Since i could not find any examples of a LKM device driver i wrote one myself. > > It is a very basic one, it just controls two 7segment displays connected to > a 8255 parallel port (no interrupts), commented and with a postinstall script > to make device files. > I had (have) a c-module which will ld -r with the pcaudio device to make an lkm. There has been some discussion as to where the various pieces should go though. For example it has been argued that the devsw table should go into each and every driver, probably a good idea too, but it means revisiting all drivers. All in all, my example probably isn't good to use as a model, but it does show what needs to be done. I'll put the tarball in my home dir on freefall for a few days... eric. > I think it would be a good thing to put it into /usr/src/share/examples/lkm. > > It is available from wcarchive.cdrom.com in directory pub/FreeBSD/incoming as > led-lkm-driver.tar.gz. > > hellmuth > -- > Hellmuth Michaelis hm@altona.hamburg.com Hamburg, Europe > (A)bort, (R)etry, (I)nstall BSD ? > eric. -- erich@lodgenet.com erich@rrnet.com From owner-freebsd-hackers Tue Sep 26 06:40:38 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA04096 for hackers-outgoing; Tue, 26 Sep 1995 06:40:38 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA04090 for ; Tue, 26 Sep 1995 06:40:28 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA06714; Tue, 26 Sep 95 13:34:42 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA14875; Tue, 26 Sep 1995 07:34:40 -0600 Date: Tue, 26 Sep 1995 07:34:40 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509261334.AA14875@emu.fsl.noaa.gov> To: patl@asimov.volant.org Cc: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com, hackers@freebsd.org In-Reply-To: <9509260523.AA29884@asimov.volant.org> (patl@asimov.volant.org) Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "Pat" == patl writes: Pat> Bzzzzttttt. Wrong. The sequence number can be static - Pat> built in when the package was built. It is the same for all Pat> systems. And thereby requiring anyone who's built a package to register with the czar of sequence numbers to prevent conflicts? I don't like it: If I were a commercial software developer considering doing a FreeBSD port of some tool or other, having to do this is one additional step is one additional headache I'd rather not have. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA Is it weird in here, or is it just me? -- Steven Wright From owner-freebsd-hackers Tue Sep 26 06:42:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA04190 for hackers-outgoing; Tue, 26 Sep 1995 06:42:22 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA04169 for ; Tue, 26 Sep 1995 06:41:58 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id JAA16927; Tue, 26 Sep 1995 09:40:57 -0400 Date: Tue, 26 Sep 1995 09:40:57 -0400 From: Coranth Gryphon Message-Id: <199509261340.JAA16927@healer.com> To: hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: peter@taronga.com (Peter da Silva) > +> Would you consider it easy to fix if they renumbered all the scripts in > +> the rc3.d directory? > That's a lot less likely than moving things around in a file, since it's > easier to do. It's almost impossible to accidentally renumber files. This is pointless. A user with an editor or a command prompt will always be able to screw up an automated system. I won't even try designing one that cannot be screwed up. No operating system out there has anything close to that. So arguments based upon the fact that that a determined sysadmin can screw up the automation process are unresolvable. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 06:42:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA04198 for hackers-outgoing; Tue, 26 Sep 1995 06:42:23 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA04170 for ; Tue, 26 Sep 1995 06:41:58 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id JAA16935; Tue, 26 Sep 1995 09:42:24 -0400 Date: Tue, 26 Sep 1995 09:42:24 -0400 From: Coranth Gryphon Message-Id: <199509261342.JAA16935@healer.com> To: asami@cs.berkeley.edu, jdl@chromatic.com Subject: Re: ports startup scripts Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk From: asami@cs.berkeley.edu (Satoshi Asami) > I thought I was completely lost in this discussion, until this article > hit me like a lightning bolt.... > * From: Jon Loeliger > * of simply representing the "dependency graph". All of the file number > Yes, *dependency graphs*! This was what we were all arguing about! > And the Unix way of handling dependency graphs are...yes, "make"! > Can it get any simpler than an /etc/rc.d/Makefile?!? :) > Ok, so who's going to write bsd.rc.mk? (Me? :) I'll help. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 06:44:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA04309 for hackers-outgoing; Tue, 26 Sep 1995 06:44:14 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA04301 for ; Tue, 26 Sep 1995 06:44:05 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id JAA16953; Tue, 26 Sep 1995 09:45:24 -0400 Date: Tue, 26 Sep 1995 09:45:24 -0400 From: Coranth Gryphon Message-Id: <199509261345.JAA16953@healer.com> To: hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: peter@taronga.com (Peter da Silva) > > > The only system I've seen that has worked with autoedited files... and > > > this will really make you cringe... is Microsoft Windows. Their config > +> Actually, the samba config files have the exact same format as the > +> MS-Windows config files. It is a well-known and simple format. > Since Samba is designed to interface with Microsoft Windows, that's not > surprising. Whatever. I haven't asked Andrew why he chose that format, so I can't comment on his motives. But why is irrelevent, it is a useful format. > I really hate the conceptual integrity problems in the INI files. ... > But because of them discovering after the fact that they needed to sequence > events, it may or may not be. This violates the principle of least surprise. You hate MS's implementation? or the concept of NAME=VALUE in general? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 07:00:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA04764 for hackers-outgoing; Tue, 26 Sep 1995 07:00:43 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA04756 ; Tue, 26 Sep 1995 07:00:38 -0700 Message-Id: <199509261400.HAA04756@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: offe@dawnrazor.campus.luth.se (Olof Johansson) Date: Tue, 26 Sep 1995 07:00:37 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: from "Olof Johansson" at Sep 26, 95 12:56:32 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 750 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Olof Johansson who wrote: > > Hello, > > A couple of months ago someone mentioned that he/she had ported an old > vgalib from linux to FreeBSD. I'd like to know how old that version was, > and how much work it'd be to port the latest version. :) > > Whoever it was, please contact me. Well, I played with it half a year ago or something, but found it ahem "not useful" for what I wanted it to do. If all else fails I can probably find it on tape somewhere (it wasn't that difficult to port, took a couble of hours as I remember). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Tue Sep 26 07:47:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA07360 for hackers-outgoing; Tue, 26 Sep 1995 07:47:51 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA07354 for ; Tue, 26 Sep 1995 07:47:43 -0700 From: marino.ladavac@aut.alcatel.at Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA11462 (5.67b/IDA-1.5 for ); Tue, 26 Sep 1995 15:47:10 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA27256; Tue, 26 Sep 95 15:44:12 +0100 Message-Id: <9509261444.AA27256@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA11050; Tue, 26 Sep 1995 15:47:13 +0100 Subject: Re: Whither wait_t? To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Date: Tue, 26 Sep 95 15:47:13 MET Cc: hackers@freebsd.org In-Reply-To: <199509240739.IAA29753@uriah.heep.sax.de>; from "J Wunsch" at Sep 24, 95 8:39 am Mailer: Elm [revision: 70.85] Sender: owner-hackers@freebsd.org Precedence: bulk > As Jordan K. Hubbard wrote: > > > > Shouldn't it be defined in sys/wait.h? Not in 2.1! :-( > > > > What's our evil friend POSIX say? > Since the man page claims: > STANDARDS > The wait() and waitpid() functions are defined by POSIX; > ...most likely not. What is "wait_t"? Everything in the man page > mentions an int. > (Sorry, 1003.1 is apparently unavailable in electronic form.) Taken from an HP-UX workstation: SYNOPSIS #include pid_t wait(int *stat_loc); pid_t waitpid(pid_t pid, int *stat_loc, int options); pid_t wait3(int *stat_loc, int options, int *reserved); . . . . AUTHOR wait(), waitpid(), and wait3() were developed by HP, AT&T, and the University of California, Berkeley. SEE ALSO Exit conditions ($?) in sh(1), exec(2), exit(2), fork(2), pause(2), ptrace(2), signal(5). STANDARDS CONFORMANCE wait(): AES, SVID2, XPG2, XPG3, XPG4, FIPS 151-2, POSIX.1 waitpid(): AES, XPG3, XPG4, FIPS 151-2, POSIX.1 Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992 ....... We are talking about the thing HP calls stat_loc, aren't we? /Alby > -- > cheers, J"org > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 26 07:54:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA08102 for hackers-outgoing; Tue, 26 Sep 1995 07:54:32 -0700 Received: from Relay1.Austria.EU.net (relay1.Austria.EU.net [192.92.138.47]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA08093 for ; Tue, 26 Sep 1995 07:54:23 -0700 Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA11663 (5.67b/IDA-1.5 for ); Tue, 26 Sep 1995 15:54:17 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA27359; Tue, 26 Sep 95 15:51:19 +0100 Received: by atuhc16 (1.38.193.4/16.2) id AA11070; Tue, 26 Sep 1995 15:54:22 +0100 Received: from atuhc16 with uucp; Tue, 26 Sep 95 15:50:01 Received: from Relay1.Austria.EU.net by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA27341; Tue, 26 Sep 95 15:49:59 +0100 Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net id AA11607 (5.67b/IDA-1.5 for ); Tue, 26 Sep 1995 15:52:24 +0100 Date: Tue, 26 Sep 1995 15:52:24 +0100 From: Mail Delivery Subsystem Message-Id: <199509261452.AA11607@Relay1.Austria.EU.net> To: marino.ladavac@aut.alcatel.at Subject: Returned mail: User unknown Sender: owner-hackers@FreeBSD.org Precedence: bulk ----- Transcript of session follows ----- While talking to freefall.freebsd.org: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown ----- Recipients of this delivery ----- Bounced, cannot deliver: Sent successfully: ----- Unsent message follows ----- Received: from aut.alcatel.at (dnisun.aut.alcatel.at) by Relay1.Austria.EU.net with SMTP id AA11601 (5.67b/IDA-1.5 for ); Tue, 26 Sep 1995 15:52:24 +0100 Received: from atuhc16 by aut.alcatel.at (4.1/SMI-4.1/AAA-1.29/main) id AA27324; Tue, 26 Sep 95 15:49:25 +0100 Message-Id: <9509261449.AA27324@atuhc16.aut.alcatel.at> Received: by atuhc16 (1.38.193.4/16.2) id AA11063; Tue, 26 Sep 1995 15:52:27 +0100 From: marino.ladavac@aut.alcatel.at Subject: Re: Whither wait_t? To: julian@ref.tfs.com (Julian Elischer) Date: Tue, 26 Sep 95 15:52:26 MET Cc: haclers@freebsd.org In-Reply-To: <199509240527.WAA04774@ref.tfs.com>; from "Julian Elischer" at Sep 23, 95 10:27 pm Mailer: Elm [revision: 70.85] > hmm looking at osf/1 > (the closet thing to posix I've ever seen......) > #ifdef _POSIX_SOURCE > /* > * If the user defines _BSD, they are obviously not looking for > * POSIX definitions with respect to wait, so give 'em the BSD > * interface. > * > */ > #ifndef _KERNEL > #ifndef _BSD /* POSIX definition of wait() */ > #ifdef _NO_PROTO > extern pid_t wait(); > #else > extern pid_t wait(int *); > #endif /* _NO_PROTO */ > #endif /* _BSD */ > ..... > #endif /*_POSIX_SOURCE*/ > and further down > /* > * Use of this union is deprecated > */ > union wait > { > but no definition of wait_t > > > > Shouldn't it be defined in sys/wait.h? Not in 2.1! :-( > > > > What's our evil friend POSIX say? > I don't think POSIX has ever heard of wait_t > (BTW what IS it?. it's not in 2.0.5 either..) I could imagine it being a union of an int and a couple of bitfields (one for signal, one for return value, one for Mommy, one for Daddy ...) Apparently, POSIX doesn't know about it. /Alby > > > > Jordan > > From owner-freebsd-hackers Tue Sep 26 08:05:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA08336 for hackers-outgoing; Tue, 26 Sep 1995 08:05:04 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA08325 for ; Tue, 26 Sep 1995 08:04:57 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA08392; Wed, 27 Sep 1995 00:47:34 +1000 Date: Wed, 27 Sep 1995 00:47:34 +1000 From: Bruce Evans Message-Id: <199509261447.AAA08392@godzilla.zeta.org.au> To: cracauer@wavehh.hanse.de, cstruble@vt.edu Subject: Re: Objective C Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>I compiled gcc 2.7.0 and everything seemed to compile fine. I then >>tried to build libobjects-0.1.14 and the test programs. All the >>test programs fail with a core dump (floating point exception) in >>libobjc.a, the Objective C runtime library. It seems to be a problem >>with __builtin_return(), but my compiler knowledge is a bit lacking >>so I can't figure out exactly what is wrong. >... >The problem is that FreeBSD does not use IEEE exceptions. Division >by zero etc. (that result in NaN or other special IEEE numbers on >other machines) will raise the SIGFPE signal, which by default causes >a core dump. I remember reading something about the problem being that invalid code is generated for __builtin_return() when the value being returned is floating point, essentially the same as for the well known bug of not declaring atof(): #include #forget-to-include ... foo = atof("12.34"); /* * Get a SIGFPE near here if you're lucky. The value of `foo' * is garbage and there is one operand full of junk on the * floating point stack. If the compiler attempts to use all * of the 8 operands that are supposed to be free on the FP * stack, then pushing the 8th one will cause an invalid * operand exception and a stack exception. If invalid * operand exceptions are not masked, then a SIGFPE will be * generated on the next non-control FP instruction after * the one that causes the exceptions. */ >Linux has the same problem. You can solve it at Linux using >-lieee. NetBSD uses full IEEE semantic as does any workstation I >have. This works by hiding the bug. There is unfortunately no way to trap stack exceptions except to trap the invalid operand exceptions that occur together with stack exceptions, so masking all IEEE exceptions breaks trapping for stack exceptions (invalid operand exceptions are IEEE but stack exceptions aren't). >I don't know the correct FreeBSD solution, since nothing like -lieee >seems to exist. Maybe I overlooked the right way to solve this in >FreeBSD. See fpsetmask(3). >At the beginning of the program, before any ObjC message call: >#ifdef __FreeBSD__ >signal(SIGFPE,signal_dummy); >#endif /* __FreeBSD__ */ This probably won't work on FreeBSD-2.0.5. It works in FreeBSD 2.0 and in Linux because the trap handler reinitializes the FPU state after saving parts of the old state in (respectively) broken and nonstandard places where debuggers can't find it. FreeBSD-2.0.5 preserves all of the state except for the exception bits. In particular it preserves the stack, so junk on the stack won't go away. Bruce From owner-freebsd-hackers Tue Sep 26 08:39:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09477 for hackers-outgoing; Tue, 26 Sep 1995 08:39:03 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09447 for ; Tue, 26 Sep 1995 08:38:52 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id IAA07899; Tue, 26 Sep 1995 08:37:47 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA00716; Tue, 26 Sep 1995 08:43:28 -0700 Date: Tue, 26 Sep 1995 08:43:28 -0700 Message-Id: <9509261543.AA00716@asimov.volant.org> To: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > [SysV method] is the simplest mechanism that provides equivalent power. |> |> I can't see any more power from a directory listing proving control |> order vs. a control file providing that order. Yep, same level of power. But the directory technique is simpler. It doesn't require complex install-time file modifications, or run-time control file parsing. |> They both have their plusses and minuses. True. So does the current mechanism. I think we are agreed that both proposals weigh in on the plus side compared to the current system. |> > I'll happily abandon it if I'm presented with a better solution. But |> > loss of functionality simply to reduce the number of i-nodes used doesn't |> |> OK. Now we can actually cover some coherent points, that do not |> relate to personal preference in style. |> |> I say they have equivalent functionality. The only counter argument made so |> far is Terry's which talks about Union-FileSystem mounting to overlay files |> into the /etc/rc?.d directories (which makes me shudder at the thought). |> |> What functionality does the "rc?.d" sym-linked subdirs method gain over |> the control file model? I can't think of any significant difference in functionality. But the rc?.d subdirs win on simplicity and (install time) safety. |> > |> Each sub-system has it's own script. A control file determines what |> > |> gets run when. Or each sub-system has it's own script, and directory |> > |> ordering in a sym-linked tree determines which gets run when. |> |> > Right. And it is orders-of-magnititude safer to add a file to a directory |> > than to automatically insert a line at the right place in a control file. |> |> Ok. Something that appears to have been lost in one of my mail messages. |> I am not talking about the package install script editing the file |> itself. I am talking about it calling a command utility (written |> as part of the setup mechanism) which will do the editing. |> |> That reduces the risk by an order of magnitude, since the util knows |> about the format, and know what is and is not safe to do. All it |> needs to be told are dependances to take into account. Ok, you've reduced (but not entirely eliminated) the worry about whether all of the package builders can get the edit right. But at the cost of introducing another complex sysadmin program. |> > |> I don't care who invented it. I've looked at it, worked with it, |> > |> and don't agree with it. It's really that simple. |> |> > That's not the impression you leave from some of your other arguments. |> |> Then I'm sorry for not being clearer earlier. Everything in my life is build |> around a few simple concepts. First, that there are always more than one way |> to do something. Second, that just because you don't like one part of |> something, don't let that affect your views on other parts. Corrallary, |> if you like something, be careful about assuming you'll like all of it. |> Third, if it works, then it is right. Corallary, if it doesn't work, |> it's wrong, replace it. Finally, re-evaluate everything constantly, |> you might have missed something the first few times. Excellent rules. Very similar to mine. But I add a rul zero: Stay Out Of The Way - you can't possibly imaging all of the ways people will want to use your stuff, so don't try. Just make it as general and flexible as you can without sacrificing simplicity and robustness. (One of the things that SVr4, and various standards committies, did that really pissed me off was to make the output of some commands more 'user friendly', and script-hostile. Apparently they've all forgotten about cut(1) and think that scripts and aliases should contain inline awk scripts that are as readable as line noise...) |> > I think we want an inittab in either case. The difference is in how many |> > entries it is expected to have, and whether it is likely to be modified |> > at each site. |> |> OK. But doesn't the "inittab" and "rc?.d" provide the same redundant |> information that you diskliked in the control file method? |> |> What does the "inittab" your proposing gain over just the "rc?.d" |> directories with numbers dictating script order? The inittab has little more than a single line per run state. For each state there will normally be an rc? script that actually runs the rc?.d scripts. There will be no need for a site to ever modify the inittab unless they are adding site-specific runstates. The major gain here is that if the model changes a bit, we don't have to change init, we can just change the rc? scripts. (The theory being that if you break init, there is no way to bring the system up by hand; but if you break an rc? script, you can probably fix it in single user.) Actually, if we go with something resembling the Solaris2 model, the inittab entries control the actions that init takes to any condition it can recognize. The runstate transitions are the most commonly used, but there are also things like handling impending power failure via SIGPWR. Each inittab line is of the form 'id:states:action:process', where id is a unique one or two character identifier, states is a list of the target runstates that the line applies to, action is a keyword telling init how to treat the process [respawn, wait, once, boot, bootwait, powerfail, powerwait, off, ondemand, initdefault, sysinit], and process is a command line to execute. It sounds complicated, but reading the man page makes it more obvious why it's all necessary and useful. |> > |> Each mechanism will have to have a means to automatically add config |> > |> information. These two will become subroutines of some overall tool |> > |> (called "pkg_init_setup" or whatever). |> |> > More complication for people doing ports; but probably not |> > outrageously so. |> |> Actually, I see it as simpler :-) |> |> With this common tool, all they have to do is execute the utility and give |> it the relevant dependancy info (if any). It knows about everything else. |> Thus the packages and ports only need to know how to call it, and we |> can implement any later install/startup mechanism and only need to change |> this one utility. But it assumes that the dependancy info is easily codified in a form that can be automatically handled. That makes it a bit harder to handle arbitrary abstractions. (Like "this has to be after all remote file system clients have been started but before any user-level information servers [HTTP, gopher, etc.]".) If the package developer can figure out how to codify the dependancies, they can pick a sequence number for each standard runstate that should include the service. Don't get me wrong - I love automation. I firmly believe that Computers Were Invented to Make Our Lives Easier. It's just that I seem to frequently find myself needing to do something slightly different then the norm, and often discover that the standard mechanisms won't allow me to do it. That's why I rate generality and flexability so high. |> > |> Anything which can figure out the correct number to use for the script |> > |> name can figure out where to place itself in a file. If it can't, then |> > |> it can't and the argument become moot. |> |> > The sequence number can be static - built in when |> > the package was built. It is the same for all systems. The file editing |> > must be done dynamically at installation time, by examining and modifying |> > a file that is likely to be different at each site. |> |> Urk. OK, I misunderstood where the numbers are coming from. I assumed |> that the package would determine the numbers at the local system. |> |> That adds a lot to the shoulder of the ports/packages coordinator, |> but does solve all the problems with numbering sequences. It isn't really adding much. Most of the work is in identifying the dependancies in the first place. This actually allows some of them to remain abstract. |> Ok. We have another basic question here: I am hanging onto less information |> than you are, in that I am only keeping track of relative ordering, while |> you are keeping track of specific numbers. I can't see anything I'm loosing |> in not having the explicit numbers, aside from ease of translation back to |> your system. Am I missing something? The explicit numbers make it easier to insert new packages in the middle of the sequence. (No need to renumber.) And easier to define fixed abstract sequence points. These aren't issues if the order is automatically generated from a dependancy tree. (But I still think that manual sequencing at package creation time is easier and more robust.) |> |> So the numbers also become run levels (being how much we've started |> |> running). Great. Back to argument #1. :-) |> |> > I suppose you might think of them that way; but you'd probably be in the |> > minority. They are significant points within the sequence for a given |> > state. Points that other services are likely to be dependant upon. You |> |> That's what I consider run-levels: plateaus where a certain amount |> if system functionality is enabled. The difference is subtle, perhaps an example from the Solaris2.4 rc2.d README would help: After the S20 scripts have executed, local file systems are mounted and temporary directories have been cleaned as appropriate. After the S80 scripts have executed, the machine is a fully configured NFS client. NFS file systems have been mounted. The name service (if any) is running. syslogd and cron are running. Here S80 could clearly be considered a run level, but S20 has that extra notation about 'temporary directories have been cleaned...'. This doesn't really correspond to a run level, but is one of the operations of the startup sequence. (Which also points out that the [SK]* scripts don't necessarily each start a service daemon; some of them will do once-per-state-transition operations.) |> Anything else is what sets of additional things (mounted filesystems, |> daemons, subsystems) are run after that point. But the discrete points |> I don't think are likely to change. Certainly not frequently. Additions are more likely than actual changes. (Where an addition is most likely to be nailing down some intermediate step that was already occurring.) |> > You're thinking in a box again. Do it this way, and I guarantee that |> > somebody will curse the makers of that decision for getting in the way |> |> Ok. I don't see how. My point is that you don't have to see how. In fact you probably can't see all of the ways somebody will want to use this. Don't try - just aim for the most flexable, powerful, system you can without sacrificing simplicity or robustness. (Rule number one: Stay Out Of The Way. If I appear to be repeating this frequently, it is because I also remind myself of it frequently...) |> Either it depends upon nothing (thus no problem), |> depends upon something with nothing depending upon it (again, simple), |> replaces something directly (still simple), or goes into the middle |> of a dependency chain. (which case requires most of the design sweat) |> |> I can't see any other case in an ordered system. Right. But I prefer to leave the decision to the human who was building the package in the first place. Humans are good at that sort of decision, when they have all the relevant information; and the package builder should have all that info. (If they don't, how are they going to specify the dependancies for the tool to do it?) |> > lose if the lines to be recognized have been hand-editted for any reason.) |> |> Granted. But a person with an editor will always be able to screw up |> an working configuration. What we have to do is make it such that |> they have no reason to hand-edit any files. There are people who will hand-edit because they don't like the tool, or don't like automated setup modification tools in general; and there will probably be somebody who needs to hand edit because their particular situation is outside the design parameters of the tool. And there are people who will hand-edit because they somehow miss the very existance of the tool. There are people who will hand edit because the Hand of Murphy is Upon Them. Don't try to imagine why, just accept that it will happen. |> |> If we automate things, we either do it right or we screw up a lot |> |> of things. That holds regardless of the automation procedure, or |> |> how the underlying layers are implemented. |> |> > No, it can work right -almost- all of the time. Which makes it all the |> > worse when it fails. |> |> Granted. The dangers come in two places - ports/packages that do not |> follow the setup requirements, and sysadmins editing things by hand. Both will happen in either scheme. The goal is to reduce the occurrances of either, and the potential severity of both problems. In the first case, our best armor is simplicity. I happen to think the rc?.d system is slightly simpler for the package builder than invoking a tool with explicit dependancies; but the win is very small. I also think the rc?.d system reduces the potential for hand-editing by reducing the amount of editing at all. They can change the sequence number on a script; but that should be a very easy potential modification to deal with. A more severe one would be if they change the service name itself. ("I don't like 'httpd', let's call it 'WebServer'.") A re-install would miss the renamed file and fail to remove it. But an equivalent problem exists with a control file; and there is a level of idiocy that we just can't protect against. (Heinlein was fond of writing "Stupidity is nature's only capitol crime." Unfortunately, far to many natural felons avoid punishment...) |> Or very complex packages, that require lots of system modifications |> to work. And finding ways to do that automatically. But those other |> modifications don't change regardless of which startup method we use. |> |> The question is: is there any fool-proof method, anywhere? |> Or do we just do the best we can, design to eliminate as many |> problems as we can forsee, and fix the others when they come up? "You can't make anything foolproof, because fools are so ingenious." (Sorry, forgot who that's attributed to.) So we design to cover as much foolishness as we easily and safely can. But we also recognize the point of diminishing returns and move on to something with a higher payback. -Pat From owner-freebsd-hackers Tue Sep 26 08:40:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09572 for hackers-outgoing; Tue, 26 Sep 1995 08:40:27 -0700 Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09567 for ; Tue, 26 Sep 1995 08:40:22 -0700 Received: from localhost (localhost [127.0.0.1]) by spooky.rwwa.com (8.6.11/8.6.9) with SMTP id LAA27433 for ; Tue, 26 Sep 1995 11:17:10 -0400 Message-Id: <199509261517.LAA27433@spooky.rwwa.com> X-Authentication-Warning: spooky.rwwa.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.3 12/28/94 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Objective C In-reply-to: Your message of "Tue, 26 Sep 1995 13:04:17 BST." <9509261204.AA13081@wavehh.hanse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Sep 1995 11:17:10 -0400 From: Robert Withrow Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Rather than than ignoring the signal, try: #include fpsetround(FP_RN); fpsetmask(0L); ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430 Net: witr@rwwa.COM R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA From owner-freebsd-hackers Tue Sep 26 08:55:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10115 for hackers-outgoing; Tue, 26 Sep 1995 08:55:52 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10110 for ; Tue, 26 Sep 1995 08:55:47 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id IAA08397; Tue, 26 Sep 1995 08:54:28 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA00748; Tue, 26 Sep 1995 09:00:09 -0700 Date: Tue, 26 Sep 1995 09:00:09 -0700 Message-Id: <9509261600.AA00748@asimov.volant.org> To: gryphon@healer.com, hackers@FreeBSD.ORG, peter@taronga.com Subject: Re: ports startup scripts X-Sun-Charset: US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk |> > |> 2 is easy. The GUI controls the file writing in all cases |> |> > If you think this would be a popular decision, talk to anyone who |> > has fought with Solaris2's AdminTool over serial port or printer setup. |> |> I'm not talking about hardware configuration. I am talking about |> what to run when in terms of mouting file-systems and daemons... And I'm talking about "The GUI controls the file writing in all cases." It doesn't matter what file - forcing people to go through the tool won't be popular. (It doesn't matter that it would be better for them. People are perverse that way.) |> |> The problem comes with dependancies. Which can be either addition |> |> > Which means that the dependancy can never alter appearance - i.e. if |> > I have a service which is dependant on having having the automounter |> > running, I can't replace amd with whizzod. |> |> Basically. Or the package (or installer) needs to know enough to know |> if this is a valid substitution. Which they had better know anyway |> if they want it to work. Which is much easier to do if you have abstract sequence points which can be things like 'remote filesystem clients started and mounted'. Then the dependant client doesn't need to know about amd or whizzod at all - only that if there are any remote filesystems, they will already be mounted. |> > Furthermore, your dependancies will be on specific services, not a |> > class of service. (E.g., you will be dependant on 'nfsd started', |> > not on 'all remote file system servers started'. The rc?.d scheme, |> > with identified sequence points, allows for a higher level of abstraction. |> |> We're back to run-levels. Or simply making the dependency on the last |> item in chain. Or if we have a cluster of items, having a marker |> in the control file define the end of the cluster. Or making the entire |> cluster a single startup item. Last item isn't necessarily right. Assume two services, A and B, both dependant on C. The sequence turns out to be C, A, B. Now a third service, D, comes along which is dependant on both A and B. In a last item scheme it will come after B. Which is fine until something happens that reverses the order of A and B (perhaps A becomes dependant upon B) now the sequence will be C, B, D, A; which isn't what you want. Sequence points could be implemented in a control file by having sequence numbers in addition to or in place of order-in-the-file. |> There are lots of options. |> |> |> And I really can't see a difference between correctly using a |> |> tool to add a line to a file, and correctly using a tool (the |> |> file system) to add a numbered script to a directory. Either |> |> you use it correctly or not, either it's written correctly or |> |> not. If not, you're in a world of hurt either way |> |> > Two differences. The first is the complexity and safety of the tool. |> > a startup script |> > editing tool would be a new, special-purpose tool. |> |> Yep. Just a new and special purpose as the startup mechanism itself. So you want to add a new startup mechanism AND a new script install tool. That's still more system complexity than just a new startup mechanism. -Pat From owner-freebsd-hackers Tue Sep 26 09:03:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA10279 for hackers-outgoing; Tue, 26 Sep 1995 09:03:15 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA10274 for ; Tue, 26 Sep 1995 09:03:07 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id JAA08632; Tue, 26 Sep 1995 09:02:00 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA00766; Tue, 26 Sep 1995 09:07:38 -0700 Date: Tue, 26 Sep 1995 09:07:38 -0700 Message-Id: <9509261607.AA00766@asimov.volant.org> To: kelly@fsl.noaa.gov Subject: Re: ports startup scripts Cc: gryphon@healer.com, jmb@kryten.atinc.com, peter@taronga.com, hackers@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> Pat> Bzzzzttttt. Wrong. The sequence number can be static - |> Pat> built in when the package was built. It is the same for all |> Pat> systems. |> |> And thereby requiring anyone who's built a package to register with |> the czar of sequence numbers to prevent conflicts? I don't like it: |> If I were a commercial software developer considering doing a FreeBSD |> port of some tool or other, having to do this is one additional |> step is one additional headache I'd rather not have. No, there are -NO- numbering conflicts. Because the filenames are of the form [SK][0-9][0-9]mumble, where 'mumble' is the name of the service. Id doesn't matter if S87httpd and S87gopherd have the same sequence number, because it doesn't matter which of them is started first. -Pat From owner-freebsd-hackers Tue Sep 26 09:11:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA11526 for hackers-outgoing; Tue, 26 Sep 1995 09:11:30 -0700 Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.97.216]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA11501 for ; Tue, 26 Sep 1995 09:11:23 -0700 Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.6.12/8.6.9) id JAA11270; Tue, 26 Sep 1995 09:12:54 -0700 From: "Steven G. Kargl" Message-Id: <199509261612.JAA11270@troutmask.apl.washington.edu> Subject: Re: f77 (f2c) update To: rcarter@geli.com (Russell L. Carter) Date: Tue, 26 Sep 1995 09:12:54 -0700 (PDT) Cc: jmz@cabri.obs-besancon.fr, nate@rocky.sri.MT.net, freebsd-hackers@freebsd.org In-Reply-To: <199509260517.WAA09097@geli.clusternet> from "Russell L. Carter" at Sep 25, 95 10:17:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 487 Sender: owner-hackers@freebsd.org Precedence: bulk First, yes please update the sources to the latest versions. According to Russell L. Carter: > > I'd really like this to go... > To go where? Into the tree as an upgrade? To have f77 go from the tree (ie., dropped)? You're reply was somewhat vague.... -- Steven G. Kargl | Phone: 206-685-4677 | Applied Physics Lab | Fax: 206-543-6785 | Univ. of Washington |---------------------| 1013 NE 40th St | FreeBSD 2.x-stable | Seattle, WA 98105 |---------------------| From owner-freebsd-hackers Tue Sep 26 11:07:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15746 for hackers-outgoing; Tue, 26 Sep 1995 11:07:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15718 for ; Tue, 26 Sep 1995 11:07:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07924; Tue, 26 Sep 1995 11:03:20 -0700 From: Terry Lambert Message-Id: <199509261803.LAA07924@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 11:03:20 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov In-Reply-To: <199509260316.XAA14582@healer.com> from "Coranth Gryphon" at Sep 25, 95 11:16:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4144 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > DNS server/caching databases should be in var. A client DNS configuration > > is not subject to change by the client. > > Unless you happen to be running as your domain primary, which a LOT of > people do. But then again, why bother keeping track of any data, > just let each machine announce itself and configure everything dynamically, > seems to work for MS-Windows. 1) That's not a client DNS, that's a server DNS. 2) You don't run server DNS's booted diskless, dataless, or off CDROM. > Ok, so you want to rewrite the entire BSD configuration system, and > take anything that might change out of /etc. You're not listening. > Fine. I give up. You want to change everything, go ahead. > It's not worth trying to fine a compromise when you want a read-only > system configuration. I want the *ability* to have a read-only system configuration. A typical configuration would pre-merge the directories, and could merge them to /etc or whatever *you* wanted. > > Only because we have local system information in the wrong damn place, > > which is why we don't have the ability to upgrade in the first place > > (upgrade/addition-of-options is what started this whole thread). > > No, the problem is that traditionally, these things went into /etc > since that was the configuration directory. You don't want it > to be the configuration directory, you want it to be a static system > configuration that comes on CD and doesn't change. I want a CD to be usable as a bootable system, which mean I want some acceptable defaults in /etc. I want to seperate configuration data from the scripts that act on it. The scripts that act on it should not typically be changed by end users. > > An upgrade is a typical user operation. > > How often? Once every 3-4 months? Yes. That's the promised distribution frequency. > Do we really want to rewrite everything around /etc > being read-only and change every existing configuration utility > and script, so that we can go through the entire conversation all > over again when the directory is named /var/config? I don't care what it is named. I think that local password data on an NFS diskless/dataless mount is not mutable data. I included the password data for your benefit. I think that system naming and IP addresses are a function of bootp and DHCP; again, not something that is configured locally. It's perfectly acceptable to have shared configuration data on a read-only partition. It's the people who want to run Lycos servers on diskless systems that have their priorities mixed up. > The nice thing about /var right now is that everything there > (with a very few exceptions which have already been discussed) > is volatile. It can be blown away and replaced with no problem, > other than loss of history. Now, it would entail a complete > reconfiguration. /var or whatever. All I want is a directory that doesn't get touched on an upgrade so that I can drop in a new distribution sans my /home partition and my system configuration data and be up and running. > If you want to rewrite everything go ahead. Just be prepared > for the few thousand people being real confused that /etc/passwd > is now /var/config/local/passwd. You still aren't listening. 8-(. > On the other hand, if people want to take a working system (what > we have now) and add a bit of flexibilty and functionality to it, I want to be able to use diskless and dataless configurations without the possibility of one client screwing it up for all of them. I want to be able to "test drive" the system from a CDROM or from a directory tree on an MS-DOS or Win95 or OS/2 file system without repartitioning my disk on speculation. I want to have a command line admin utility that can be popen'ed by a curses/GUI utility. I want to have a curses/GUI utility. I want to have multiple system administration vi popen of an rsh of the command line utility by the same curses/gui utility. What framework do you suggest for accomplishing these goals? 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 Sep 26 11:15:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16090 for hackers-outgoing; Tue, 26 Sep 1995 11:15:46 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16085 for ; Tue, 26 Sep 1995 11:15:44 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07951; Tue, 26 Sep 1995 11:11:24 -0700 From: Terry Lambert Message-Id: <199509261811.LAA07951@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 11:11:24 -0700 (MST) Cc: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <199509260401.AAA14675@healer.com> from "Coranth Gryphon" at Sep 26, 95 00:01:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1206 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > If it can find the dependancy. And doesn't mistake something else for it. > > Which basicly means it will work fine in the lab and fail miserably in the > >real world. I have yet to see an automatic editing system which was robust > > Anything which can figure out the correct number to use for the script > name can figure out where to place itself in a file. If it can't, then > it can't and the argument become moot. Actually, the numbers are specified by the authors of the package. Presumably, they had all the components they depneded upon installed in order to do their developement and are aware of their own dependencies. > For 99% of cases, just append to the file. You only need to "find the > correct point" if you are inserting into the middle of a process chain. > Which will probably be a very rare condition, unless you are replacing > one startup command with another, in which case the position is > already determined for you. I want to replace the SMTP agent with my own. What is the current agent's name? How did you determine this? 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 Sep 26 11:35:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA16894 for hackers-outgoing; Tue, 26 Sep 1995 11:35:53 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA16889 for ; Tue, 26 Sep 1995 11:35:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08003; Tue, 26 Sep 1995 11:28:49 -0700 From: Terry Lambert Message-Id: <199509261828.LAA08003@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gary@palmer.demon.co.uk (Gary Palmer) Date: Tue, 26 Sep 1995 11:28:49 -0700 (MST) Cc: jehamby@lightside.com, hackers@FreeBSD.ORG In-Reply-To: <2649.812092182@palmer.demon.co.uk> from "Gary Palmer" at Sep 26, 95 06:09:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2043 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > 1) Who issues these script ID numbers? We cannot let people go > claiming their own at random, as they *WILL* clash (even if we let > them loose on a number domain with 6 significant digits!) Since the scripts have a named "tail" to uniquify them, the question is whether a change in order will cause them to fail. I argue that it would not. If I have a script for a component, the only thing I care about is that my component is started *after* the components which I depend upon. I could care less what other components are started when. > 2) Who is responsible for ensuring that they are in the correct order? > (e.g. something which loads a LKM is run *AFTER* the script to > mount /usr is run). This could potentially be nasty, as the > dependancy tree WILL vary over time (and even from machine to > machine). OK. This is a question of administrative fiat for default components, which have to be figured out (as the current rc files do) by the people who build the default system. People who build components dependent on *default* components are responsible for ordering their components after the ones they depend on. > 3) How will we cope with local alterations (e.g. someone running > locally developed s/w which is only for local use)? Do we leave > large gaps in the numbering to allow for local hacks? There's no real need, but it would be a good idea. It's a good idea, not because of add ons, which only care that they are started after the things on which they depend, but because you might want to split the script at some later date, and in so doing, you will want to push the first part before the current location instead of pushing the second part after the current location. By doing this, you maintain the order without disturbing third party packages. This is why I suggested 3 digits, with the final digit 0, instead of the SVR4 2 digits. 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 Sep 26 11:38:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17060 for hackers-outgoing; Tue, 26 Sep 1995 11:38:16 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17053 for ; Tue, 26 Sep 1995 11:38:12 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id TAA11289; Tue, 26 Sep 1995 19:36:14 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509261836.TAA11289@gvr.win.tue.nl> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 26 Sep 1995 19:36:14 +0100 (MET) Cc: gryphon@healer.com, julian@ref.tfs.com, bugs@ns1.win.net, hackers@FreeBSD.ORG, taob@io.org In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Sep 25, 95 10:07:20 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 289 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >And since the first encountered name with that uid is considered "canonical", > >might an alphabetic sorting not screw things up? > > Yes. It screws up things. Passwd automatic sorting IS NOT ALLOWED! > Could you please verify that my patches either do or do not break this? -Guido From owner-freebsd-hackers Tue Sep 26 11:40:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17204 for hackers-outgoing; Tue, 26 Sep 1995 11:40:18 -0700 Received: from paris.ics.uci.edu (mmdf@paris.ics.uci.edu [128.195.1.50]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id LAA17193 for ; Tue, 26 Sep 1995 11:40:12 -0700 Received: from bossanova.ics.uci.edu by paris.ics.uci.edu id aa14487; 26 Sep 95 11:36 PDT To: hackers@freebsd.org Subject: ATAPI and Hitachi IDE CDROM support Date: Tue, 26 Sep 1995 11:31:45 -0700 From: "Brett J. Vickers" Message-ID: <9509261136.aa14487@paris.ics.uci.edu> Sender: owner-hackers@freebsd.org Precedence: bulk I've been trying to get FreeBSD to recognize my Hitachi IDE CDROM drive at bootup, but it fails everytime. I've applied the 1.5 atapi patch to the current kernel. Here's the relevant portion of dmesg: FreeBSD 2.2-CURRENT #: Sun Sep 24 14:07:38 PDT 1995 root@george.ics.uci.edu:/usr/src/sys/compile/GEORGE CPU: 100-MHz Pentium 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 [...] wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1213MB (2485728 sectors), 2466 cyls, 16 heads, 63 S/T, 512 B/S atapi0.1 at 0x1f0: attach called atapi.1 at 0x1f0: identify not ready, status=1 npx0 on motherboard Any suggestions? Brett --- # # GEORGE - config # machine "i386" cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" ident GENERIC maxusers 16 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options ATAPI #Enable ATAPI support for IDE bus config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 #disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 device wcd0 #IDE CDROM # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.1 #options XSERVER # include code for XFree86 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device ed0 at isa? port 0x300 net irq 3 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's From owner-freebsd-hackers Tue Sep 26 11:41:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA17293 for hackers-outgoing; Tue, 26 Sep 1995 11:41:54 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA17287 for ; Tue, 26 Sep 1995 11:41:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08032; Tue, 26 Sep 1995 11:37:25 -0700 From: Terry Lambert Message-Id: <199509261837.LAA08032@phaeton.artisoft.com> Subject: Re: ports startup scripts To: julian@ref.tfs.com (Julian Elischer) Date: Tue, 26 Sep 1995 11:37:25 -0700 (MST) Cc: peter@taronga.com, terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199509260610.XAA09058@ref.tfs.com> from "Julian Elischer" at Sep 25, 95 11:10:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 351 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > TADAAAA!!! > devfs (actually works these days.. I just need to be allowed enough > time to add devfs registration lines to all the drivers YES! 80% of the way to solving some of the big issues, and counting! 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 Sep 26 13:00:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA20001 for hackers-outgoing; Tue, 26 Sep 1995 13:00:09 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA19992 for ; Tue, 26 Sep 1995 13:00:03 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA08069; Tue, 26 Sep 1995 11:48:41 -0700 From: Terry Lambert Message-Id: <199509261848.LAA08069@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 11:48:41 -0700 (MST) Cc: gryphon@healer.com, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com, hackers@FreeBSD.ORG In-Reply-To: <199509260631.CAA15855@healer.com> from "Coranth Gryphon" at Sep 26, 95 02:31:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2057 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I say they have equivalent functionality. The only counter argument made so > far is Terry's which talks about Union-FileSystem mounting to overlay files > into the /etc/rc?.d directories (which makes me shudder at the thought). > > What functionality does the "rc?.d" sym-linked subdirs method gain over > the control file model? The ability to have dataless systems with local file systems mounted after hitting a sufficiently high run level. You get to the NFS client run level, then do your union mounts, and then go to a higher run level. This would benefit both things like a Sybase server and an X boot/font server, which must have local data to server, but share their configuration with identical servers. A lab of 40 X terminals can not rely on one server. DNS rotoring between FTP server also falls into this category, even if I think the DNS rotor soloution is inferior to content addressable routing. > Ok. We have another basic question here: I am hanging onto less information > than you are, in that I am only keeping track of relative ordering, while > you are keeping track of specific numbers. I can't see anything I'm loosing > in not having the explicit numbers, aside from ease of translation back to > your system. Am I missing something? The ordering is only present to *delay* events until after depended-upon events have occurred. To use project management terminology, the amount of slack is irrelevant. We don't care about strictly enforcing order unless it falls into a dependency graph. Then we only care that we are started after who we depend upon. > |> Granted. Having things remove from a control file requires good > |> solid coding. > > >Which you trust every maker of a package to do... (And it can still > > That's what the command util is for. All the package maker does is > call that tool. I agree that you'd want a tool for this, if you wanted this. 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 Tue Sep 26 14:24:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA22944 for hackers-outgoing; Tue, 26 Sep 1995 14:24:46 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA22935 for ; Tue, 26 Sep 1995 14:24:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA08299; Tue, 26 Sep 1995 14:15:29 -0700 From: Terry Lambert Message-Id: <199509262115.OAA08299@phaeton.artisoft.com> Subject: Re: ports startup scripts To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 26 Sep 1995 14:15:29 -0700 (MST) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org In-Reply-To: <21914.812109715@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 03:01:55 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6229 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk [ ... the UNIX destop "battle" ... ] > You know how I like to compare the UNIX world to the Three Stooges > trying to fix a leaky faucet? Nobody actually works on the faucet > throughout the entire episode - they're too wrapped up in seeing who > can poke the other the most times in the eye. Well, that's how the > UNIX world has looked from an ISV's perspective for a LONG time! Who > do you think *writes* the bloody desktop apps? The ISVs. Do you > think that we at Lotus, for example, were overjoyed at the prospect of > doing entirely separate and laborious ports of NOTES, 1-2-3 and AmiPro > to everthing from SunOS to HP/UX? No, we weren't. We were stuck > doing 6 different platforms, in fact, all of which were majorly > different from one another! It was the polar opposite of fun! And we > were the bloody UNIX *experts* of the company! You can only imagine > how it looked from everyone else's perspective. The occasional VP > would stroll through and see this workgroup filled with literally > several million dollars worth of top end HP, IBM and Sun hardware and > they'd look at this little engineering group full of very highly paid > engineers (we were rare!) and they'd sort of shake their heads and say > "you need ALL this stuff to service a market 1/10th the size of OS/2 > or Windows?" And we'd say "yup! pretty #%&@*! stupid, ain't it!" With respect, the porting time required is proportional to the portability of the code. The overhead is realtive to how clean the code base is in the first place. People have complained about obvious aspects of my coding style on points other than the inane "goto" argument. My coding style evolved from 1984 to the present, supporting compiler and system incompatabilities and bugs in C libraries. The point is, that code written in that style compiled and ran on 142 platforms, 121 of them UNIX systems of one bent or another. Without modification. Probably why our async communications software beat out UUCP (which came with UNIX for *free*) by 2:1 in a UNIX World survey. The point here is that it is possible to code portably without worrying about porting issues by adopting code and software architectural styles that are sensitive *by design* to architectural differences (or compiler vagries, like improper handling of bitfields or comma operators or parenthisis or brace placement or inferior preprocessors, etc.). As a small software house, Century Software was able to go in and "port" to a new "UNIX box" in about a day, including running validation suites on product components and cutting two masters with any minor source changes that were necessary for reintegration into the code base. Let me repeat that: one day. In general, this is because system dependencies were limited to reliably present library routines (like tgetent/tgetstr/tgetnum) or encapsulated in a single module common to system types of that derivation (there were 5 sio.c modules for doing serial I/O on BSD+Xenix, SVR3+SVR4, VMS, DOS, and Macintosh, and 4 for handling terminal I/O). The software in question was a terminal emulation package capable of emulating 12 different base terminal types on any UNIX terminal, such that you could hook into a remote system expecting, for instance, a block mode IBM 3101 with your Wyse-50 attached to your UNIX box. It was enough to let you use VMS EDT/LSE/TPU on a Televideo 910. The problems faced by an application program, whose only real system dependency issue is the ability to interact with a tty, are really nothing compared to what was, in effect, system level software (the SVR4 code had to have the capability of pushing and popping the cannonical processing module of the streams stack, and the issues in allocating and deallocating modems, patial open hacks, etc., are really, really complex). Now I agree that Lotus was probably architecturally handicapped because of its DOS origins. Wordperfect was similarly handicapped. The reality of the situation is that these handicaps are entrenched only if it's not possible to roll portability changes back into the mainline code tree. And that problem's political, not technical. But it doesn't take a genius to write portable software. The support issues really boil down to release synchronization, and little else, once you have the portability concerns addressed. That's why I always harp on portability to old compilers: a small shop must borrow machines. > Bitter? Oh, not us. We wanted MORE versions of UNIX. Binary > compatibility? Heck no! Crazy ideas like that only let us stay home > with our families on the weekends! Needless to say, this was not an > unusual attitude among the other ISVs who provided you with everything > from Framemaker to Adobe Photoshop and THAT is why UNIX lost, yes > lost, the desktop market. UNIX was a highly dysfunctional family that > fought so long and hard that the children were finally taken away by > social services. Little help, when social services idea of a functional family unit is 1.6 kids, so they start oiling up their chainsaws. Code developed with restraint on Altos Xenix would run on SCO Xenix, SCO UNIX, ISC UNIX, Cubix and Microport. Code developed with restraint on a DG Aviion would run on DG, ICO, Sanyo, and other 88'open boxes. Code developed with restrain on an NCR Tower XP would run on a Tower 16, a Tower 32, a Sperry 5040, 5050, and 5060 (OEM NCR hardware with a Sperry (later Unisys) UNIX port. Binary compatability isn't nearly as big an issue as other ISV's were complaining about. And it's less of one today, now that Intel is the common hardware platform. And Century Software's products aren't the only ones who followed this model successfully. BBX, a "Business Basic" did the same thing. So did a lot of other vendors. So did Lone Star Software. I have no patience for ISV's whose complaints boil down to a political inability to achieve the correct technical soloution. If they had their way, the common ABI would be Windows .EXE programs and they would never have to port anything anywhere. 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 Sep 26 14:37:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA23449 for hackers-outgoing; Tue, 26 Sep 1995 14:37:09 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA23436 for ; Tue, 26 Sep 1995 14:36:44 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id WAA16158 for hackers@freebsd.org; Tue, 26 Sep 1995 22:36:21 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.11/8.6.12) id WAA00394 for hackers@freebsd.org; Tue, 26 Sep 1995 22:33:32 +0100 From: Andreas Klemm Message-Id: <199509262133.WAA00394@knobel.gun.de> Subject: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: hackers@freebsd.org Date: Tue, 26 Sep 1995 22:33:31 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 668 Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! Someone with a working -stable here ?! Since weeks unable to get a FreeBSD release compiled without that messages like: internal compiler error .... signal 11 ... Started with 2.0.5R ... compiled the stable kernel because of AHA 2940 problems ... and what now ??? How can I help to track down the problem ? Please reply through e-mail ... I'm currently not on the mailing list but subscribed to hackers today ... Andreas /// -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Tue Sep 26 15:10:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA25125 for hackers-outgoing; Tue, 26 Sep 1995 15:10:21 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA25071 for ; Tue, 26 Sep 1995 15:10:07 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id SAA18328; Tue, 26 Sep 1995 18:13:01 -0400 Date: Tue, 26 Sep 1995 18:13:01 -0400 From: Coranth Gryphon Message-Id: <199509262213.SAA18328@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > /var or whatever. All I want is a directory that doesn't get touched > on an upgrade so that I can drop in a new distribution sans my /home > partition and my system configuration data and be up and running. Here we are in agreement. But I think trying to make a read-only configuration is a lot more hassle than it is worth. Coming up with a configuration mechanism that allows us to back up our local changes, drop a new install in, and re-merge the local modifications, I do think is a good idea. > I want to have a command line admin utility that can be popen'ed > by a curses/GUI utility. > I want to have a curses/GUI utility. > > I want to have multiple system administration vi popen of an rsh of > the command line utility by the same curses/gui utility. These I agree with. And I think they are independent of the framework. The best idea I've seen so far is the Makefile concept, which is built from package data (which comes with each package) and from the base configuration. The actualy "rc.N" scripts (or directories) are build using a "mkinitdb" util (just like the whatis database is built from the man pages using "makewhatis"). Local changes can be kept like package data, and init scripts/dirs rebuilt. This is the most flexibiity we can give, and still keep things usable by the majority. > I want to run from a CD or diskless Then the CD (or server) has to have to fixed configuration you want. Period. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 15:20:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26552 for hackers-outgoing; Tue, 26 Sep 1995 15:20:36 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA26541 for ; Tue, 26 Sep 1995 15:20:29 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA28794 (5.67a/IDA-1.5 for hackers@freebsd.org); Tue, 26 Sep 1995 16:56:02 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id PAA20495 for hackers@freebsd.org; Tue, 26 Sep 1995 15:00:45 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509262000.PAA20495@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Tue, 26 Sep 1995 15:00:44 -0500 (CDT) In-Reply-To: <9509261334.AA14875@emu.fsl.noaa.gov> from "Sean Kelly" at Sep 26, 95 07:34:40 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 240 Sender: owner-hackers@freebsd.org Precedence: bulk > And thereby requiring anyone who's built a package to register with > the czar of sequence numbers to prevent conflicts? Why? Conflicts don't impact anyone. If you have the same sequence number you obviously don't care which goes first. From owner-freebsd-hackers Tue Sep 26 15:23:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA26931 for hackers-outgoing; Tue, 26 Sep 1995 15:23:06 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA26910 for ; Tue, 26 Sep 1995 15:22:57 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA28796 (5.67a/IDA-1.5 for hackers@FreeBSD.ORG); Tue, 26 Sep 1995 16:56:09 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id PAA20580 for hackers@FreeBSD.ORG; Tue, 26 Sep 1995 15:04:11 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509262004.PAA20580@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@FreeBSD.ORG Date: Tue, 26 Sep 1995 15:04:11 -0500 (CDT) In-Reply-To: <199509261340.JAA16927@healer.com> from "Coranth Gryphon" at Sep 26, 95 09:40:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1090 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > From: peter@taronga.com (Peter da Silva) > > +> Would you consider it easy to fix if they renumbered all the scripts in > > +> the rc3.d directory? > > That's a lot less likely than moving things around in a file, since it's > > easier to do. It's almost impossible to accidentally renumber files. > This is pointless. A user with an editor or a command prompt will > always be able to screw up an automated system. I won't even > try designing one that cannot be screwed up. No operating system > out there has anything close to that. It used to be possible for root to write to directories. A determined sysadmin no longer has that opportunity to mess the system up. A naive sysadmin is no longer likely to create orphan files with a misdirected "cat". > So arguments based upon the fact that that a determined sysadmin > can screw up the automation process are unresolvable. I can't correlate your phrase "a determined sysadmin" with my use of the word "accidentally". Perhaps you are mistaken in your assumption that I am speaking of protecting the system from deliberate abuse? From owner-freebsd-hackers Tue Sep 26 16:00:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA02489 for hackers-outgoing; Tue, 26 Sep 1995 16:00:27 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA02475 for ; Tue, 26 Sep 1995 16:00:24 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id PAA23962; Tue, 26 Sep 1995 15:56:58 -0700 To: Terry Lambert cc: kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts In-reply-to: Your message of "Tue, 26 Sep 1995 14:15:29 PDT." <199509262115.OAA08299@phaeton.artisoft.com> Date: Tue, 26 Sep 1995 15:56:58 -0700 Message-ID: <23960.812156218@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > With respect, the porting time required is proportional to the portability > of the code. The overhead is realtive to how clean the code base is in > the first place. With equal respect, "porting" a product for any ISV of reasonable size is a fair greater challenge than simply getting the software "running." The product needs to be separately QA'd and tech support needs to understand any issues particular to any given platform (and believe me, even for the same product on multiple platforms the tech support problem gets skewed by local configuration issues). If shipping on a new platform were like a calf roping contest where you're allowed to throw your hands up in victory after the calf's feet are well tangled, no matter now inelegant the knot, well then sure! :-) Jordan From owner-freebsd-hackers Tue Sep 26 16:12:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA04141 for hackers-outgoing; Tue, 26 Sep 1995 16:12:34 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA04136 for ; Tue, 26 Sep 1995 16:12:32 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id QAA10852; Tue, 26 Sep 1995 16:10:31 -0700 From: Julian Elischer Message-Id: <199509262310.QAA10852@ref.tfs.com> Subject: Re: LKM example device driver available To: erich@lodgenet.com (Eric L. Hernes) Date: Tue, 26 Sep 1995 16:10:30 -0700 (PDT) Cc: hm@altona.hamburg.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199509261321.IAA15175@jake.lodgenet.com> from "Eric L. Hernes" at Sep 26, 95 08:21:08 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 592 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > argued that the devsw table should go into each and every driver, > probably a good idea too, but it means revisiting all drivers. I plan on doing this before 2.2 (As I need to visit all the drivers to add devfs registration anyway) +----------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / On assignment | / \ julian@ref.tfs.com +------>x USA \ in a very strange | ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country ! +- X_.---._/ USA+(510) 645-3137(wk) \_/ \\ v From owner-freebsd-hackers Tue Sep 26 16:12:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA04177 for hackers-outgoing; Tue, 26 Sep 1995 16:12:50 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA04163 for ; Tue, 26 Sep 1995 16:12:47 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id QAA10860; Tue, 26 Sep 1995 16:12:19 -0700 From: Julian Elischer Message-Id: <199509262312.QAA10860@ref.tfs.com> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: andreas@knobel.gun.de (Andreas Klemm) Date: Tue, 26 Sep 1995 16:12:18 -0700 (PDT) Cc: hackers@freebsd.org In-Reply-To: <199509262133.WAA00394@knobel.gun.de> from "Andreas Klemm" at Sep 26, 95 10:33:31 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 777 Sender: owner-hackers@freebsd.org Precedence: bulk boot off a 2.0.5 kernel get current sources rebuild kernel > > Hi ! > > Someone with a working -stable here ?! Since weeks unable to > get a FreeBSD release compiled without that messages like: > > internal compiler error .... signal 11 ... > > Started with 2.0.5R ... compiled the stable kernel because of > AHA 2940 problems ... and what now ??? > > How can I help to track down the problem ? > > Please reply through e-mail ... I'm currently not on the mailing list > but subscribed to hackers today ... > > Andreas /// > > -- > $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de > $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de > $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< > From owner-freebsd-hackers Tue Sep 26 16:42:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA07873 for hackers-outgoing; Tue, 26 Sep 1995 16:42:08 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA07860 ; Tue, 26 Sep 1995 16:42:03 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id RAA15898; Tue, 26 Sep 1995 17:44:17 -0600 Date: Tue, 26 Sep 1995 17:44:17 -0600 From: Nate Williams Message-Id: <199509262344.RAA15898@rocky.sri.MT.net> To: hackers@FreeBSD.org CC: bde@FreeBSD.org Subject: Diskslice naming convention? Sender: owner-hackers@FreeBSD.org Precedence: bulk Let me see if what I *think* is true is really true. First of all, B.S. (Before Slice), the naming convention was as follows x = generic device name. # = disk number /dev/ xd#a - root partition xd#b - swap partition xd#c - Entire FreeBSD portion of disk xd#d - Entire disk xd#e - optional additional FreeBSD partitions (/usr, swap, /var, etc...) xd#f - optional additional FreeBSD partitions (/usr, swap, /var, etc...) xd#g - optional additional FreeBSD partitions (/usr, swap, /var, etc...) xd#h - optional additional FreeBSD partitions (/usr, swap, /var, etc...) Note, the root and swap partitions were only special on the first (0th) disk. If the disk wasn't the first disk, they had no specific purpose. Now, with slices we have a completely new scheme. Basically, we have a similar scheme, but with the additions of slices. So, am I right in saying that other than the 'compatability' slice of /dev/xd#a for the root partition, the naming scheme is as follows: X = generic device name. # = disk number Y = slice number (ie; one of the 4 'fdisk' partions') Xd#asY (where 'a' could be any lower-case letter 'a-h') BTW - Are slices named 1-4 or 0-3? Anyway, we create a FreeBSD slice by setting it's ID to 0xA5. Then, we build a disklabel onto this 'slice' which gives us individual partitions on that slice. Are there any 'special' partitions in this disklabel? How would I read the *entire* FreeBSD portion of the slice? How about the entire disk? How do I create a FreeBSD partition which accesses a DOS slice? Is there anything other documentation other than the the 'diskspace.FAQ' and the sources available? Note, sysinstall does a good job of automating all of this, but I'd like to understand how the new naming scheme works. Thanks, Nate From owner-freebsd-hackers Tue Sep 26 16:52:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09336 for hackers-outgoing; Tue, 26 Sep 1995 16:52:06 -0700 Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09320 for ; Tue, 26 Sep 1995 16:52:02 -0700 Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id QAA01175; Tue, 26 Sep 1995 16:51:35 -0700 Date: Tue, 26 Sep 1995 16:51:35 -0700 Message-Id: <199509262351.QAA01175@silvia.HIP.Berkeley.EDU> To: gryphon@healer.com CC: hackers@freebsd.org, pds@freefall.freebsd.org In-reply-to: <199509260102.VAA14193@healer.com> (message from Coranth Gryphon on Mon, 25 Sep 1995 21:02:01 -0400) Subject: Re: Problems with packages, and general third party software. From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk * > And you have to add "operator" to the operator group in /etc/group. I don't * > think we want pkg_add doing this either. Can't we solve this by making the executable setgid-operator instead of setuid-operator? * No, but operator should probably be in the "operator" group anyway, ya think? You're right (I think). I looked into the cvs logs and only found this for master.passwd and group. === revision 1.2 date: 1993/07/19 18:52:51; author: rgrimes; state: Exp; lines: +4 -8 Removed extranious names from master.passwd file, changed root and toor to be in group 0 (was group 10). Changed operator to be in group 20, was 28. === So why wasn't operator moved to group "operator", instead of "staff"? That seems to make more sense to me. Rod, do you remember? Satoshi From owner-freebsd-hackers Tue Sep 26 17:26:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13682 for hackers-outgoing; Tue, 26 Sep 1995 17:26:42 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13667 for ; Tue, 26 Sep 1995 17:26:37 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id RAA03902; Tue, 26 Sep 1995 17:25:17 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id RAA27739; Tue, 26 Sep 1995 17:27:47 -0700 Message-Id: <199509270027.RAA27739@corbin.Root.COM> To: Andreas Klemm cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Tue, 26 Sep 95 22:33:31 BST." <199509262133.WAA00394@knobel.gun.de> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 26 Sep 1995 17:27:46 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >Hi ! > >Someone with a working -stable here ?! Since weeks unable to >get a FreeBSD release compiled without that messages like: > >internal compiler error .... signal 11 ... > >Started with 2.0.5R ... compiled the stable kernel because of >AHA 2940 problems ... and what now ??? > >How can I help to track down the problem ? I don't know what the problem is - all of the test machines that I have -stable on are running perfectly. We're going to have a new snapshot out soon, so perhaps you could use this as a base instead of 2.0.5. Does the above error always happen at the same spot, or is it random? What happens when you type 'make' again after the error? -DG From owner-freebsd-hackers Tue Sep 26 17:28:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA13963 for hackers-outgoing; Tue, 26 Sep 1995 17:28:08 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA13951 for ; Tue, 26 Sep 1995 17:28:06 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA08773; Tue, 26 Sep 1995 17:22:48 -0700 From: Terry Lambert Message-Id: <199509270022.RAA08773@phaeton.artisoft.com> Subject: Re: ports startup scripts To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 26 Sep 1995 17:22:48 -0700 (MST) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org In-Reply-To: <23960.812156218@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 03:56:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3578 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > With respect, the porting time required is proportional to the portability > > of the code. The overhead is realtive to how clean the code base is in > > the first place. > > With equal respect, "porting" a product for any ISV of reasonable size > is a fair greater challenge than simply getting the software > "running." The product needs to be separately QA'd and tech support > needs to understand any issues particular to any given platform (and > believe me, even for the same product on multiple platforms the tech > support problem gets skewed by local configuration issues). The product is QA'd with the validation suite. 2 hours were required for the validation suite, which is interesting, considering POSIX validation takes less time to run. Part of this validation is dumping the manufacturer termcap, ttys, inittab, gettydefs, etc. to tape, as well as any diagnostic information that can be obtained programatically (if the validation suite can't tell a difference on the platform, then the product can't tell a difference on the platform). Noting tape devices, formats, etc. is done by the porting engineer during the validation suite run. The other issues are manufacturer packaged modem and serial cable pinouts, both of which can be had for purchasing (the typical approach). The modem to computer connection is set up with a breakout box between the manufacturer cable and the modem. The modem is only purchased in the case of non-support of the Hayes command set. The system "flavor" (generally SYSV vs. BSD) is the only unique thing required for the support engineer. All other documentation is equivalent. Error reports to the user are not duplicated for different errors and are prefixed with product support database keywords. Don't try to tell me Lotus didn't ship their own termcap. We did, too, but we made sure we worked with the manufacturer packaged hardware and termcap as well, and didn't install ours at all by default. The worst UNIX port we ever did is AIX, and that took 5 days. > If shipping on a new platform were like a calf roping contest where > you're allowed to throw your hands up in victory after the calf's feet > are well tangled, no matter now inelegant the knot, well then sure! :-) I agree that that's not a port. On the other hand, one can not call portable any code that relies on structure packing, byte order, bit fields, comma operators, dynamic scoping of stack variables, varradic functions, or preprocessor primitives like "#if" or "#elif" or the types "const", "void", or "__declspec()", or ANSI prototypes or agregate union initialization, etc. Using any function in manual sections other than (2) is frowned upon as well, unless it's stdio, and even then you have to be careful. The one exception might be directory walking utilities, and then only under BSD and SVR4 (BSD-like directory structures). If you are using any of these things and you expect to support more than a few UNIX platforms with little effort, then you are smoking something. Yes, it's a pain in the ass to set code like this up initially, but it's not as much as a pain in the ass as rewriting the world and calling that a "port" for each new machine. Code that has been rewritten for another platform has not been ported, it's another product. If you are maintaining seperate source trees for different platforms, then you are either crazy or masochistic or both. 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 Sep 26 17:40:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA15803 for hackers-outgoing; Tue, 26 Sep 1995 17:40:31 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA15798 for ; Tue, 26 Sep 1995 17:40:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA08885; Tue, 26 Sep 1995 17:36:00 -0700 From: Terry Lambert Message-Id: <199509270036.RAA08885@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 17:36:00 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@freebsd.org, freebsd-ports@freebs.org, kelly@fsl.noaa.gov In-Reply-To: <199509262213.SAA18328@healer.com> from "Coranth Gryphon" at Sep 26, 95 06:13:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 630 Sender: owner-hackers@freebsd.org Precedence: bulk > From: Terry Lambert > > /var or whatever. All I want is a directory that doesn't get touched > > on an upgrade so that I can drop in a new distribution sans my /home > > partition and my system configuration data and be up and running. > > Here we are in agreement. But I think trying to make a read-only > configuration is a lot more hassle than it is worth. Argument: boot from CDROM to see if you can successfully run the new version on your particular hardware. 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 Sep 26 18:13:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA20026 for hackers-outgoing; Tue, 26 Sep 1995 18:13:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA20006 for ; Tue, 26 Sep 1995 18:13:23 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA24297; Tue, 26 Sep 1995 18:12:39 -0700 To: Terry Lambert cc: kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts In-reply-to: Your message of "Tue, 26 Sep 1995 17:22:48 PDT." <199509270022.RAA08773@phaeton.artisoft.com> Date: Tue, 26 Sep 1995 18:12:39 -0700 Message-ID: <24295.812164359@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > The product is QA'd with the validation suite. 2 hours were required for > the validation suite, which is interesting, considering POSIX validation > takes less time to run. Sorry, this statement simply leads me to believe that you've never worked on anything of significant size or complexity. 2 hours is about how long it took to brief the QA team on how to structure the run at most large ISVs I've worked at! :-) If you got the results back in 3 or 4 days you considered it a rush job. Plus it's an on-going thing. You need to re-QA on *every* point release you might make for that platform. You ever worked in a Crosby method "zero defects" shop? There are *procedures* for all this stuff and checklists to be followed. I don't care how bloody well written the software was, in a lot of cases this is simply *not* a technical problem! It's a problem of "1 platform = 1 overall pain in the butt, always" Multiply this by 6 and you're lucky if you can sit down. No holy grail of software design will save you from going through regression tests as complex as certain types of SDI targetting software, to say nothing of the paperwork. Sorry. You also presuppose an idea world where I have the *choice* of writing god's gift to portable code and aren't simply stuck with porting a large legacy application to all these new platforms. The times where I actually got to write a major shelf application from scratch and according to my standards can be counted on the fingers of a penguin! Usually the scenario is that the Windows weenies get to write it as a Windows app because they only represent about 500 times the revenue you do and the 500 pound gorilla gets to sleep wherever he wants, and you're stuck trying to port it to UNIX. WABI? Don't make me laugh until tears run down my face. Jordan From owner-freebsd-hackers Tue Sep 26 18:21:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21162 for hackers-outgoing; Tue, 26 Sep 1995 18:21:04 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21127 for ; Tue, 26 Sep 1995 18:20:49 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id VAA18934; Tue, 26 Sep 1995 21:23:36 -0400 Date: Tue, 26 Sep 1995 21:23:36 -0400 From: Coranth Gryphon Message-Id: <199509270123.VAA18934@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@freebsd.org Precedence: bulk From: Terry Lambert > From: Coranth Gryphon > +> Here we are in agreement. But I think trying to make a read-only > +> configuration is a lot more hassle than it is worth. > Argument: boot from CDROM to see if you can successfully run the > new version on your particular hardware. Counter: The cdrom, if it contains a live file system, needs to contain a basic configuraton (a sample, if you will). If you go to the extent to make the CDROM bootable, making the sample configuration (sample /etc) a valid one shouldn't be all that tough. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Tue Sep 26 18:22:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21358 for hackers-outgoing; Tue, 26 Sep 1995 18:22:10 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21329 for ; Tue, 26 Sep 1995 18:21:56 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id CAA11376; Wed, 27 Sep 1995 02:21:47 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id CAA12172; Wed, 27 Sep 1995 02:21:47 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA15240; Tue, 26 Sep 1995 21:31:00 +0100 From: J Wunsch Message-Id: <199509262031.VAA15240@uriah.heep.sax.de> Subject: Re: SLIP and DNS problem To: radova@risc6.unisa.ac.za (A. Radovanovic) Date: Tue, 26 Sep 1995 21:30:59 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9509260912.AA51193@risc6.unisa.ac.za> from "A. Radovanovic" at Sep 26, 95 11:12:23 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1569 Sender: owner-hackers@freebsd.org Precedence: bulk As A. Radovanovic wrote: > > I have 8 modems connected to my BSD system. From time to time, after login, > the SLIP client can't get host name resolved, or can't get it resolved on > some of the lines. When I reboot the machine everything is OK for some time. > > It seems that the server doesn't know the client's IP. I think that the DNS > works fine - it resolves names, answers ping, ftp, www, telnet,... > I'll appreciate it very much if somebody can give me a clue. The server must always know the client's IP for SLIP (since it's not negotiated). It rather looks like the infamous "stale clone route" problem. This happens if a line breaks with active connections on it. Subsequent packets arriving for the IP address of the client whose line just broke will not hit any host-specific route, and therefore will be resolved via the default route, usually pointing back to the ethernet. This causes a "clone route" to be allocated for this particular IP host (you can see them with "netstat -ra"), and a subsequent login attempt of the client causes the weird message "File exists" to appear at ifconfig time of the SLIP interface (translate this into: "Route exists"). The only known workaround by now is to delete any potential host route to the intented new host address right before configuring the SLIP interface. It works for sax.sax.de now this way (yes, i've been complaining about this problem before). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 26 18:22:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA21466 for hackers-outgoing; Tue, 26 Sep 1995 18:22:45 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA21451 for ; Tue, 26 Sep 1995 18:22:39 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id CAA11408; Wed, 27 Sep 1995 02:21:59 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id CAA12181; Wed, 27 Sep 1995 02:21:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA15651; Tue, 26 Sep 1995 21:40:53 +0100 From: J Wunsch Message-Id: <199509262040.VAA15651@uriah.heep.sax.de> Subject: Re: vgalib for FreeBSD! To: offe@dawnrazor.campus.luth.se (Olof Johansson) Date: Tue, 26 Sep 1995 21:40:51 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Olof Johansson" at Sep 26, 95 12:56:32 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 425 Sender: owner-hackers@freebsd.org Precedence: bulk As Olof Johansson wrote: > > A couple of months ago someone mentioned that he/she had ported an old > vgalib from linux to FreeBSD. I'd like to know how old that version was, > and how much work it'd be to port the latest version. :) I think somebody is porting it for NetBSD. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue Sep 26 18:30:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA22364 for hackers-outgoing; Tue, 26 Sep 1995 18:30:11 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA22353 for hackers@freefall; Tue, 26 Sep 1995 18:30:09 -0700 Date: Tue, 26 Sep 1995 18:30:09 -0700 From: "Jordan K. Hubbard" Message-Id: <199509270130.SAA22353@freefall.freebsd.org> To: hackers@freefall.FreeBSD.org Subject: 2.1.0-950922-SNAP available for testing on freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Once I hear a couple of "victory!" calls, I'll transfer it to wcarchive (e.g. ftp.freebsd.org) when it will then be "official". Thanks - reports to me please! Jordan From owner-freebsd-hackers Tue Sep 26 18:52:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA24982 for hackers-outgoing; Tue, 26 Sep 1995 18:52:26 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA24977 for ; Tue, 26 Sep 1995 18:52:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA09152; Tue, 26 Sep 1995 18:46:16 -0700 From: Terry Lambert Message-Id: <199509270146.SAA09152@phaeton.artisoft.com> Subject: Re: ports startup scripts To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 26 Sep 1995 18:46:15 -0700 (MST) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org In-Reply-To: <24295.812164359@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 06:12:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5142 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > The product is QA'd with the validation suite. 2 hours were required for > > the validation suite, which is interesting, considering POSIX validation > > takes less time to run. > > Sorry, this statement simply leads me to believe that you've never > worked on anything of significant size or complexity. 2 hours is > about how long it took to brief the QA team on how to structure the > run at most large ISVs I've worked at! :-) If you got the results back > in 3 or 4 days you considered it a rush job. I worked on NetWare for UNIX... it was 3.6 million lines of code. Does that count? How about SVR4.2 ES/MP? Of course, it was only portable to an SVID/POSIX/ANSI environment. I agree that it couldn't be ported easily. On the other hand, Lotus 1-2-3 is not rocket science. Neither is the application level product I've been using as an example. If you don't automate your Q/A process, I can see where it might take humans a long time to validate it. And yes, it takes work to do this, but overall less man hours than you would spend for 3 or more ports to have humans do what the machine should be doing. > Plus it's an on-going thing. You need to re-QA on *every* point > release you might make for that platform. No argument here. > You ever worked in a Crosby method "zero defects" shop? There are > *procedures* for all this stuff and checklists to be followed. Like branch path anaylisis and full code coverage in the validation suite? That's the correct way to automate testing/validation. > I don't care how bloody well written the software was, in a lot of > cases this is simply *not* a technical problem! It's a problem of > "1 platform = 1 overall pain in the butt, always" I always thought it scaled like SMP: the more platforms you add only fractionally increase the problem load. 8-). > Multiply this by 6 and you're lucky if you can sit down. No holy > grail of software design will save you from going through regression > tests as complex as certain types of SDI targetting software, to say > nothing of the paperwork. Sorry. If the code passes regression tests on one platform, you are testing either the compiler or the C libraries if you perform full regression on subsequent platforms. Part of the validation is a branch path test of the libraries do that you know all your uses are covered. A regression test is still useful at this point only if fixing the platform is an option (or if simply not shipping is an option). I have a lot of respect for Lotus's quality -- the best quality, bar none, of a first release. I have no doubt with what you've said about "who owns the problem" that not shipping was an option. I think that's where we diverge. > > You also presuppose an idea world where I have the *choice* of writing > god's gift to portable code and aren't simply stuck with porting a > large legacy application to all these new platforms. The times where > I actually got to write a major shelf application from scratch and > according to my standards can be counted on the fingers of a penguin! 8-). A port is an opportunity for rewrite if your management isn't screwed and the code isn't going to end up as a collection of patches. Again, this is only an option if your portability changes get rolled back into the main line code. Porting a legacy app is not a situation where this happens, since any additional developement on the legacy code is throw-away. But then you are already setting yourself up for failure, since any platform being ported to is a second class citizen. This is a political problem, and one can not draw valid conclusions about platforms from the internal politics of a company. One can only draw conclusions about that particular companies opinion of the platform. > Usually the scenario is that the Windows weenies get to write it as a > Windows app because they only represent about 500 times the revenue > you do and the 500 pound gorilla gets to sleep wherever he wants, > and you're stuck trying to port it to UNIX. WABI? Don't make me laugh > until tears run down my face. >From this argument, one would conclude that the only successful DOS programs are those that were ported from CP/M, since at one time CP/M was wildly more popular than DOS. 8-). It's perfectly valid to not endanger your mainline product for a port. The point is that you are not allowed to make overall design tradeoffs that would penalize a windows version. That does *not* equate with *requiring* a paritcular design, antithetical to portability in general and antithetical to UNIX in particular. Again, we are talking internal company politics: whether you can replace "Mr. Golden Boy"'s code with functionally equivalent but architecturally more portable code, or not. The problem is in the interpretation of "change" as "danger" by people who aren't engineers. All of which speaks to the viability of a particular companies ported product on a given platform, not to the viability of the platform. 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 Sep 26 18:53:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA25049 for hackers-outgoing; Tue, 26 Sep 1995 18:53:18 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA25040 for ; Tue, 26 Sep 1995 18:53:13 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA09163; Tue, 26 Sep 1995 18:48:03 -0700 From: Terry Lambert Message-Id: <199509270148.SAA09163@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Tue, 26 Sep 1995 18:48:02 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@freebsd.org, freebsd-ports@freebs.org, kelly@fsl.noaa.gov In-Reply-To: <199509270123.VAA18934@healer.com> from "Coranth Gryphon" at Sep 26, 95 09:23:36 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 870 Sender: owner-hackers@freebsd.org Precedence: bulk > > From: Coranth Gryphon > > +> Here we are in agreement. But I think trying to make a read-only > > +> configuration is a lot more hassle than it is worth. > > > Argument: boot from CDROM to see if you can successfully run the > > new version on your particular hardware. > > Counter: The cdrom, if it contains a live file system, needs to contain > a basic configuraton (a sample, if you will). > > If you go to the extent to make the CDROM bootable, making the sample > configuration (sample /etc) a valid one shouldn't be all that tough. Counter-counter: IP addreses and default name servers and gateway can not be preconfigured on a CDROM. Therefore the must be in a non-ROM (MFS?) location. 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 Tue Sep 26 22:15:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA13813 for hackers-outgoing; Tue, 26 Sep 1995 22:15:13 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA13776 for ; Tue, 26 Sep 1995 22:14:08 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id PAA11050; Wed, 27 Sep 1995 15:11:15 +1000 From: michael butler Message-Id: <199509270511.PAA11050@asstdc.scgt.oz.au> Subject: Re: SLIP and DNS problem To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 27 Sep 1995 15:11:13 +1000 (EST) Cc: radova@risc6.unisa.ac.za, hackers@freebsd.org In-Reply-To: <199509262031.VAA15240@uriah.heep.sax.de> from "J Wunsch" at Sep 26, 95 09:30:59 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 423 Sender: owner-hackers@freebsd.org Precedence: bulk > It rather looks like the infamous "stale clone route" problem. [ .. ] > The only known workaround by now is to delete any potential host route > to the intented new host address right before configuring the SLIP > interface. It works for sax.sax.de now this way (yes, i've been > complaining about this problem before). .. or to run gated which periodically scans the interfaces and deletes bogus routes, michael From owner-freebsd-hackers Tue Sep 26 22:38:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA14389 for hackers-outgoing; Tue, 26 Sep 1995 22:38:14 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA14384 for ; Tue, 26 Sep 1995 22:38:10 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA13001; Tue, 26 Sep 1995 22:37:36 -0700 Message-Id: <199509270537.WAA13001@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: offe@dawnrazor.campus.luth.se (Olof Johansson), hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-reply-to: Your message of "Tue, 26 Sep 1995 21:40:51 BST." <199509262040.VAA15651@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Sep 1995 22:37:35 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk The biggest problem with the svgalib is its lack of support for svga cards. For instance, the last time that I checked there was no support for S3 cards . I guess a good starting point will be to port whatever is available then include a lot of the XFree86 init and graphic routines. The effort is almost not worth it -- at least from my point and view . I suggest doing a net search for a better package. My 0.2 graphical cents Amancio >>> J Wunsch said: > As Olof Johansson wrote: > > > > A couple of months ago someone mentioned that he/she had ported an old > > vgalib from linux to FreeBSD. I'd like to know how old that version was, > > and how much work it'd be to port the latest version. :) > > I think somebody is porting it for NetBSD. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-hackers Tue Sep 26 23:32:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA15655 for hackers-outgoing; Tue, 26 Sep 1995 23:32:04 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA15638 ; Tue, 26 Sep 1995 23:31:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA08365; Wed, 27 Sep 1995 16:21:41 +1000 Date: Wed, 27 Sep 1995 16:21:41 +1000 From: Bruce Evans Message-Id: <199509270621.QAA08365@godzilla.zeta.org.au> To: hackers@FreeBSD.org, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: bde@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >So, am I right in saying that other than the 'compatability' slice of >/dev/xd#a for the root partition, the naming scheme is as follows: >X = generic device name. ># = disk number >Y = slice number (ie; one of the 4 'fdisk' partions') >Xd#asY (where 'a' could be any lower-case letter 'a-h') No, Y may be any fdisk partition or logical drive, and 'a' follows the slice number. >BTW - Are slices named 1-4 or 0-3? No, slices are named 1-30. >Anyway, we create a FreeBSD slice by setting it's ID to 0xA5. Then, we >build a disklabel onto this 'slice' which gives us individual partitions >on that slice. Are there any 'special' partitions in this disklabel? c. >How would I read the *entire* FreeBSD portion of the slice? How about There is no such thing as a `portion' of a slice. (Would a portion be smaller or larger than a partition? :-).) `dd if=/dev/rxd#sY' or `dd if=/dev/rxd#sYc' reads the entire slice sY. These devices are identical. /dev/MAKEDEV creates both for convenience. The c partition is special whether there is a disklabel describing it or not. If there is a disklabel, the c partition should match the whole slice. >the entire disk? How do I create a FreeBSD partition which accesses a >DOS slice? `dd if=/dev/rxd#' reads the entire disk. /dev/rxd# is a completely different device from /dev/rxd#c. These devices are often confused because disklabel automatically translates from `xd#' to /dev/rxd#c'. You can't create a FreeBSD partition which accesses a DOS slice. Just access the DOS slice directly. >Is there anything other documentation other than the the 'diskspace.FAQ' >and the sources available? Not much. Perhaps there are 100 replices like this in mail archives. Bruce From owner-freebsd-hackers Tue Sep 26 23:48:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA16054 for hackers-outgoing; Tue, 26 Sep 1995 23:48:01 -0700 Received: from chrome.jdl.com (chrome.onramp.net [199.1.166.202]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA16049 for ; Tue, 26 Sep 1995 23:47:58 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.jdl.com (8.6.11/8.6.9) with SMTP id BAA07563; Wed, 27 Sep 1995 01:46:27 -0500 Message-Id: <199509270646.BAA07563@chrome.jdl.com> X-Authentication-Warning: chrome.jdl.com: Host localhost.jdl.com didn't use HELO protocol To: Coranth Gryphon cc: hackers@freebsd.org Subject: Re: ports startup scripts In-reply-to: Your message of "Tue, 26 Sep 1995 03:33:42 EDT." <199509260733.DAA16047@healer.com> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Wed, 27 Sep 1995 01:46:27 -0500 From: Jon Loeliger Sender: owner-hackers@freebsd.org Precedence: bulk Apparently, Coranth Gryphon scribbled: > > There are issues here still, like, how do you state dependencies against > > things that have yet to be invented? I think that's why fictitious or > > virtual nodes may be needed in the graph too. They can essentially > > arbitrarily represent the "levels" or "states" in the graph where > > certain properties are available ("NFS", "LAN", "WAN", "Single User"). > > Solves the dependencies problems if a specification can be coded. Oh, it can be encoded, I'd bet... > > Tip-toeing back out of the warzone, > > Nope, get back in here :-) This sounds like a really good idea. Rats. OK, I'm back... Thanks. Do you think it is worth pursuing? > So, how would you go about implementing such a dependency graph? Well, the obvious one was to use ``make'': Satoshi Asami was inspired to write: > And the Unix way of handling dependency graphs are...yes, "make"! > Can it get any simpler than an /etc/rc.d/Makefile?!? :) This implementation can be done in several variants of which the most promising is likely a set of "include"s. This, if nothing else, would provide a "rapid prototyping" approach that might validate or invalidate the whole approach. Naturally, though, I bet this eventually isn't the right approach. Gut feel says it doesn't handle all the needed cases quite right and will eventually collapse under its own weight. Perhaps a better approach might be to specify a general graph language (nodes and arcs) and have a "scheduler" utility that constructed the equivalent /etc/rc* files at key times. Initially at system install based on normal /etc/rc behaviour, then at each pkg_add, etc. I think the problem would be the "glue" between the parts. All of the "state" information hanging in otherwise global variables in the /etc/rc* files, interrupt and error handling, etc. jdl From owner-freebsd-hackers Wed Sep 27 00:03:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA16471 for hackers-outgoing; Wed, 27 Sep 1995 00:03:50 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA16462 for ; Wed, 27 Sep 1995 00:03:45 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id IAA04972; Wed, 27 Sep 1995 08:03:24 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.11/8.6.12) id IAA00270; Wed, 27 Sep 1995 08:02:32 +0100 From: Andreas Klemm Message-Id: <199509270702.IAA00270@knobel.gun.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: davidg@Root.COM Date: Wed, 27 Sep 1995 08:02:32 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509270027.RAA27739@corbin.Root.COM> from "David Greenman" at Sep 26, 95 05:27:46 pm X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 2748 Sender: owner-hackers@freebsd.org Precedence: bulk > >Hi ! > > > >Someone with a working -stable here ?! Since weeks unable to > >get a FreeBSD release compiled without that messages like: > > > >internal compiler error .... signal 11 ... > > > >Started with 2.0.5R ... compiled the stable kernel because of > >AHA 2940 problems ... and what now ??? > > > >How can I help to track down the problem ? > > I don't know what the problem is - all of the test machines that I have > -stable on are running perfectly. We're going to have a new snapshot out soon, > so perhaps you could use this as a base instead of 2.0.5. > Does the above error always happen at the same spot, or is it random? What > happens when you type 'make' again after the error? This morning I made an interesting experience. The make world stopped building the libraries, because there was a control character in an include file. c++ -pipe -O -nostdinc -I/local/FreeBSD-stable/gnu/lib/libg++/include -I/usr/include -I/local/FreeBSD-stable/gnu/lib/libg++/include -I/usr/include/g++ -I/usr/include -nostdinc++ -c /local/FreeBSD-stable/gnu/lib/libg++/libio/iostream.cc -o iostream.o In file included from /local/FreeBSD-stable/gnu/lib/libg++/include/iostream.h:31, from /local/FreeBSD-stable/gnu/lib/libg++/libio/iostream.cc:31: /local/FreeBSD-stable/gnu/lib/libg++/include/streambuf.h:358: parse error at null character Actually there was a control character in this file. Instead of ( int something there was a ( xnt something ^--- control character I didn't fix that and simply rebooted the machine to see, if there is actually a problem in this file or if this might be another error. And ... to my big surprise ... after rebooting the file was ok !!! So, is this a hardware error or is this an OS error. I really don't know. My kernel is -stable. The rest is 205R. I only compiled and installed some newer maintenance programs from stable, where I thought I makes sense, because of changes in the kernel... systat, mount (to get the noauto flag),... But no library, compiler or assembler. Since I had trouble in the past with SCSI termination I'll make the following experiment ... I'll try a make world with 5 MB/sec synchr. SCSI speed. Then I'll see, if I have still SCSI problems. You remember ?! Term. Term. AHA2940------Quantum Grand Prix-----Toshiba 3601 didn't run and hangs quite often AHA2940------Toshiba 3601-----Quantum Grand Prix runs well so far. Andreas /// -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Wed Sep 27 00:36:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA17586 for hackers-outgoing; Wed, 27 Sep 1995 00:36:18 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA17578 for ; Wed, 27 Sep 1995 00:36:11 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id IAA11353; Wed, 27 Sep 1995 08:31:52 +0100 Message-Id: <199509270731.IAA11353@gilberto.physik.rwth-aachen.de> Subject: Re: vgalib for FreeBSD! To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 27 Sep 1995 08:31:51 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, offe@dawnrazor.campus.luth.se, hackers@freebsd.org In-Reply-To: <199509270537.WAA13001@rah.star-gate.com> from "Amancio Hasty Jr." at Sep 26, 95 10:37:35 pm From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1601 Sender: owner-hackers@freebsd.org Precedence: bulk > > The biggest problem with the svgalib is its lack of support for svga > cards. For instance, the last time that I checked there was no > support for S3 cards . I guess a good starting point will be to > port whatever is available then include a lot of the XFree86 init > and graphic routines. The effort is almost not worth it -- at least > from my point and view . I suggest doing a net search for a better package. I didn't take a look at it yet but I don't regard it such useless if it supports at least the standard vga modes and eventually a 256 color mode. It would be ideal to be incorporated into Jordans new sysinstall stuff to allow for ('better') graphical setup look and feel (a la Win95, ducking and holding hands against ears :-) I dropped the original posting of Olof Johansson. Can someone give the coordinates of the package (vgalib) please once again? If it's GPL'ed it's ruled out as a candidate for graphical install stuff, of course. > > My 0.2 graphical cents > Amancio > > >>> J Wunsch said: > > As Olof Johansson wrote: > > > > > > A couple of months ago someone mentioned that he/she had ported an old > > > vgalib from linux to FreeBSD. I'd like to know how old that version was, > > > and how much work it'd be to port the latest version. :) > > > > I think somebody is porting it for NetBSD. > > > > -- > > cheers, J"org > > > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > > Never trust an operating system you don't have sources for. ;-) > > > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Sep 27 00:41:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA17888 for hackers-outgoing; Wed, 27 Sep 1995 00:41:52 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA17881 for ; Wed, 27 Sep 1995 00:41:47 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id IAA15219; Wed, 27 Sep 1995 08:41:38 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.11/8.6.12) id IAA00240; Wed, 27 Sep 1995 08:40:41 +0100 From: Andreas Klemm Message-Id: <199509270740.IAA00240@knobel.gun.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: davidg@Root.COM Date: Wed, 27 Sep 1995 08:40:41 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509270027.RAA27739@corbin.Root.COM> from "David Greenman" at Sep 26, 95 05:27:46 pm X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 2393 Sender: owner-hackers@freebsd.org Precedence: bulk One additional experience... Now I setup every scsi device in aha2940 controller setup to 5.0 MB/sec. SCSI transfer speed. Went into single user mode made a file system check first after that mount -at ufs (so that root additionally gets rw) and then a make world. The make world stopped earlier then the one with 10MB/sec SCSI bus speed, so I assume, that there isn't the trouble. with 10MB/sec.: -rw-r--r-- 1 root wheel 447178 Sep 27 07:45 /usr/src/world.log Here it was a control character in libg++'s header file, that vanished after rebooting with 5MB/sec.: -rw-r--r-- 1 root wheel 384177 Sep 27 09:20 /usr/src/world.log2 Here it was an internal compiler error... After that internel compiler error I'm not able to compile anything. Even a helloworld.c fails with that message. Signal 10 or 11 ... My hello world simply looks the following, without including stdio ... main(){ printf("Hello\n");} What I forgot to mention is, that my filesystem isn't stable, too. After the first failed make world I did a fsck in single user mode, which reported a DUP in root-fs. It was one of my test kernels, that wasn't active (/kernel.STABLE), I'm booting currently kernel.STABLE2, /kernel is a simple link to kernel.STABLE2. My root fs is a small little fs without much traffic ... but it seems to get trashed sometimes. It isn't the first time, that I get these dups. The preening fsck doesn't report any errors. Only if I do the whole fsck in simgle user mode, then I'll see these errors. Could it be, that the in core images of something will be trashed and that on system shutdown these things are written to fs - fs gets unmounted without problems and the preening fsck on the next reboot thinks, fine, fs was properly unmounted, fs state ok .... ?!?!?! Same with gcc ... might it be the case, that in core images of shared libs in memory get trashed, so that dynamically build programs like the C-Compiler doesn't work anymore, if there is a in core damage of some shared lib in memory ??? What I didn't mention is, that working under X11 generally works ok, longer sessions (many hours) sometimes work ok. But sometimes X simply hangs .... -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Wed Sep 27 00:53:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18296 for hackers-outgoing; Wed, 27 Sep 1995 00:53:35 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18288 for ; Wed, 27 Sep 1995 00:53:24 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id JAA11999; Wed, 27 Sep 1995 09:53:03 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id JAA07983; Wed, 27 Sep 1995 09:53:02 +0200 Message-Id: <199509270753.JAA07983@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: David Greenman cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Wed, 27 Sep 1995 09:53:01 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > >Someone with a working -stable here ?! Since weeks unable to > >get a FreeBSD release compiled without that messages like: > > > >internal compiler error .... signal 11 ... > > > >Started with 2.0.5R ... compiled the stable kernel because of > >AHA 2940 problems ... and what now ??? > > > >How can I help to track down the problem ? I have this problem too. I loaded 2.0.5, loaded the 2.1-stable sources, and as soon as 2.1-stable code is used (during the make world), it falls over. A temporary fix it to copy 2.1-current /usr/libexec/* to this machine. > I don't know what the problem is - all of the test machines that I have > -stable on are running perfectly. We're going to have a new snapshot out soon , > so perhaps you could use this as a base instead of 2.0.5. > Does the above error always happen at the same spot, or is it random? What > happens when you type 'make' again after the error? At the same spot for me. I was suspecting memory/cache problems, so far I have ruled out the cache. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Wed Sep 27 00:53:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA18334 for hackers-outgoing; Wed, 27 Sep 1995 00:53:56 -0700 Received: from donna.cylatech.com (macgyver@cmh-p102.infinet.com [205.133.22.102]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA18314 for ; Wed, 27 Sep 1995 00:53:42 -0700 Received: (from macgyver@localhost) by donna.cylatech.com (8.6.12/8.6.9) id DAA00999 for hackers@freebsd.org; Wed, 27 Sep 1995 03:53:38 -0400 From: Wilson MacGyver Message-Id: <199509270753.DAA00999@donna.cylatech.com> Subject: Re: vgalib for FreeBSD! To: hackers@freebsd.org Date: Wed, 27 Sep 1995 03:53:38 -0400 (EDT) In-Reply-To: <199509270731.IAA11353@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 27, 95 08:31:51 am Reply-To: macgyver@cylatech.com X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1837 Sender: owner-hackers@freebsd.org Precedence: bulk > I didn't take a look at it yet but I don't regard it such useless > if it supports at least the standard vga modes and eventually > a 256 color mode. It would be ideal to be incorporated into Jordans > new sysinstall stuff to allow for ('better') graphical setup > look and feel (a la Win95, ducking and holding hands against ears :-) > > > I dropped the original posting of Olof Johansson. Can someone give the > coordinates of the package (vgalib) please once again? > If it's GPL'ed it's ruled out as a candidate for > graphical install stuff, of course. I don't think it's GPL'ed. ------------------------------------------------------------------------------ Title: svgalib Version: 1.27 Entered-date: 13AUG95 Description: Low-level graphics library that provides VGA and SVGA modes in a console. It is not intended as an alternative to X for apps, but rather a set of tools for things like VGA games, image viewing in modes that X cannot support, etc. Keywords: graphics, VGA, SVGA, library Author: hhanemaa@cs.ruu.nl (Harm Hanemaayer) Maintained-by: Temporarily maintained by eowmob@exp-math.uni-essen.de (Michael Weller) Primary-site: sunsite.unc.edu /pub/Linux/libs/graphics 442K svgalib127.tar.gz Alternate-site: tsx-11.mit.edu /pub/linux/sources/libs 442K svgalib127.tar.gz Platforms: Linux/Intel (too many vgacards to list here); Linux/Alpha (up to now only #9 GXE PCI KNOWN to work, other cards may/should work. Copying-policy: Freely distributable. End -- Wilson MacGyver macgyver@cylatech.com -------------------------------------- Each new story, no matter how many you've written before, is a new, unlimited promise--to yourself. - Nancy Kress From owner-freebsd-hackers Wed Sep 27 01:05:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA18992 for hackers-outgoing; Wed, 27 Sep 1995 01:05:25 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA18971 for ; Wed, 27 Sep 1995 01:05:01 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id KAA12010; Wed, 27 Sep 1995 10:04:47 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id KAA08007; Wed, 27 Sep 1995 10:04:44 +0200 Message-Id: <199509270804.KAA08007@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: Andreas Klemm cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Wed, 27 Sep 1995 10:04:43 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk You are not alone. I have a 486DX4/100/PCI and an adaptec 2940, and I get these the whole time, as well as the signal 11's. I just tried a reboot, ant the files that were corrupted before are now OK???!! They are corrupted in exactly that same sort of way you are reporting. My kernel is stable, the rest is a mix (a lot hand-installed). M > This morning I made an interesting experience. > The make world stopped building the libraries, because there was > a control character in an include file. > > c++ -pipe -O -nostdinc -I/local/FreeBSD-stable/gnu/lib/libg++/include -I/usr /include -I/local/FreeBSD-stable/gnu/lib/libg++/include -I/usr/include/g++ -I /usr/include -nostdinc++ -c /local/FreeBSD-stable/gnu/lib/libg++/libio/iostrea m.cc -o iostream.o > In file included from /local/FreeBSD-stable/gnu/lib/libg++/include/iostream.h :31, > from /local/FreeBSD-stable/gnu/lib/libg++/libio/iostream.cc: 31: > /local/FreeBSD-stable/gnu/lib/libg++/include/streambuf.h:358: parse error at null character > > Actually there was a control character in this file. > Instead of ( int something there was a ( xnt something > ^--- control character > > I didn't fix that and simply rebooted the machine to see, if there > is actually a problem in this file or if this might be another error. > And ... to my big surprise ... after rebooting the file was ok !!! > > So, is this a hardware error or is this an OS error. I really don't > know. My kernel is -stable. The rest is 205R. I only compiled and > installed some newer maintenance programs from stable, where I thought > I makes sense, because of changes in the kernel... systat, mount > (to get the noauto flag),... But no library, compiler or assembler. > > Since I had trouble in the past with SCSI termination I'll make > the following experiment ... I'll try a make world with 5 MB/sec > synchr. SCSI speed. Then I'll see, if I have still SCSI problems. > > You remember ?! > > Term. Term. > AHA2940------Quantum Grand Prix-----Toshiba 3601 > didn't run and hangs quite often > AHA2940------Toshiba 3601-----Quantum Grand Prix > runs well so far. > > Andreas /// > > -- > $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de > $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de > $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD << < -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Wed Sep 27 01:08:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19291 for hackers-outgoing; Wed, 27 Sep 1995 01:08:30 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19261 ; Wed, 27 Sep 1995 01:08:16 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id JAA02637 ; Wed, 27 Sep 1995 09:08:06 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id JAA03816 ; Wed, 27 Sep 1995 09:08:06 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7/keltia-uucp-2.5.1) id IAA27063; Wed, 27 Sep 1995 08:59:06 +0100 (MET) From: Ollivier Robert Message-Id: <199509270759.IAA27063@keltia.freenix.fr> Subject: Re: Diskslice naming convention? To: nate@rocky.sri.MT.net (Nate Williams) Date: Wed, 27 Sep 1995 08:59:05 +0100 (MET) Cc: hackers@FreeBSD.org, bde@FreeBSD.org In-Reply-To: <199509262344.RAA15898@rocky.sri.MT.net> from "Nate Williams" at Sep 26, 95 05:44:17 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1141 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that Nate Williams said: > So, am I right in saying that other than the 'compatability' slice of > /dev/xd#a for the root partition, the naming scheme is as follows: It is not only the root partition. If you have only one FreeBSD slice on a disk, it will use the compatibility slice. > X = generic device name. > # = disk number > Y = slice number (ie; one of the 4 'fdisk' partions') > > Xd#asY (where 'a' could be any lower-case letter 'a-h') Xd#sYa instead. the 'a' is at the end and shows the partition # in the slice Y. > BTW - Are slices named 1-4 or 0-3? 1-4, 0 is the compatibility slice. > Anyway, we create a FreeBSD slice by setting it's ID to 0xA5. Then, we > build a disklabel onto this 'slice' which gives us individual partitions > on that slice. Are there any 'special' partitions in this disklabel? 'c' is special and indicates the whole slice (as 'c' indicated the whole BSD partition in the old scheme). > How would I read the *entire* FreeBSD portion of the slice? How about > the entire disk? How do I create a FreeBSD partition which accesses a > DOS slice? - The FreeBSD portion of a slice is Xd#sY (I think). - The entire disk is Xd#. - FreeBSD partition to access a DOS slice is not possible. A DOS partition will get its own slice (e.g. the sd0s4 slice could be a DOS "partition" -- in DOS terms). I hope I'm right Bruce :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Mon Sep 25 02:02:31 MET 1995 From owner-freebsd-hackers Wed Sep 27 01:22:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19835 for hackers-outgoing; Wed, 27 Sep 1995 01:22:01 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19830 for ; Wed, 27 Sep 1995 01:21:54 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id BAA11660; Wed, 27 Sep 1995 01:20:22 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id BAA00147; Wed, 27 Sep 1995 01:22:54 -0700 Message-Id: <199509270822.BAA00147@corbin.Root.COM> To: Mark Murray cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Wed, 27 Sep 95 09:53:01 +0200." <199509270753.JAA07983@grumble.grondar.za> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 27 Sep 1995 01:22:54 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >> >Someone with a working -stable here ?! Since weeks unable to >> >get a FreeBSD release compiled without that messages like: >> > >> >internal compiler error .... signal 11 ... >> > >> >Started with 2.0.5R ... compiled the stable kernel because of >> >AHA 2940 problems ... and what now ??? >> > >> >How can I help to track down the problem ? > >I have this problem too. I loaded 2.0.5, loaded the 2.1-stable sources, >and as soon as 2.1-stable code is used (during the make world), it falls >over. A temporary fix it to copy 2.1-current /usr/libexec/* to this machine. Please describe your machines in detail...output of dmesg would be a good start. This sounds similar to the bug that was recently fixed in 2.2, but the code in 2.1 is very different and should not be suseptible to this. The VFS cluster code in 2.1 has not changed since 2.0.5. >At the same spot for me. I was suspecting memory/cache problems, so far I >have ruled out the cache. There was one other report about things dieing when one of the shared libraries got out of sync, but after that was fixed the problems went away. If you have the ability to try 2.1-stable on different hardware, but with the same disk drive and binaries, this might help isolate the problem. It might also help if you could install the new 0922 snapshot. -DG From owner-freebsd-hackers Wed Sep 27 01:25:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA19965 for hackers-outgoing; Wed, 27 Sep 1995 01:25:30 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA19958 for ; Wed, 27 Sep 1995 01:25:22 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.12/8.6.5) with ESMTP id BAA12175; Wed, 27 Sep 1995 01:24:01 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id BAA00162; Wed, 27 Sep 1995 01:26:33 -0700 Message-Id: <199509270826.BAA00162@corbin.Root.COM> To: Mark Murray cc: Andreas Klemm , hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Wed, 27 Sep 95 10:04:43 +0200." <199509270804.KAA08007@grumble.grondar.za> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 27 Sep 1995 01:26:33 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >You are not alone. I have a 486DX4/100/PCI and an adaptec 2940, and I get >these the whole time, as well as the signal 11's. I just tried a reboot, >ant the files that were corrupted before are now OK???!! They are corrupted >in exactly that same sort of way you are reporting. > >My kernel is stable, the rest is a mix (a lot hand-installed). Well, this is starting to sound a lot like some type of disk controller/PCI bus problem. Perhaps Justin might have some advice. Is it possible for either of you to borrow a different type of PCI SCSI controller (or any other hardware) to help isolate/diagnose the problem? If there is a software problem, we need to get this troubleshooted as soon as possible. -DG From owner-freebsd-hackers Wed Sep 27 01:35:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA20349 for hackers-outgoing; Wed, 27 Sep 1995 01:35:19 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA20337 ; Wed, 27 Sep 1995 01:35:15 -0700 Message-Id: <199509270835.BAA20337@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: kuku@gilberto.physik.rwth-aachen.de Date: Wed, 27 Sep 1995 01:35:14 -0700 (PDT) Cc: hasty@rah.star-gate.com, joerg_wunsch@uriah.heep.sax.de, offe@dawnrazor.campus.luth.se, hackers@freebsd.org In-Reply-To: <199509270731.IAA11353@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 27, 95 08:31:51 am From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1933 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Christoph Kukulies who wrote: > > > > > The biggest problem with the svgalib is its lack of support for svga > > cards. For instance, the last time that I checked there was no > > support for S3 cards . I guess a good starting point will be to > > port whatever is available then include a lot of the XFree86 init > > and graphic routines. The effort is almost not worth it -- at least > > from my point and view . I suggest doing a net search for a better package. > > I didn't take a look at it yet but I don't regard it such useless > if it supports at least the standard vga modes and eventually > a 256 color mode. It would be ideal to be incorporated into Jordans > new sysinstall stuff to allow for ('better') graphical setup > look and feel (a la Win95, ducking and holding hands against ears :-) Ahem, I have looked at it long ago (allready told Olof), and it could be made to work, again I have the same reservations as Amancio, its not worth it... but what the heck.. I also have to say that syscons does support switching to any graohics mode that a STD. VGA card can handle (640x480x16, 320x200x256 etc) so we have the support, I even have s library for doing this and simple graphics routines (including simple sprite animations) based on my old libdgl (maybe I should call it something with graphics in it). I'd be much inclined to have people use this instead, as IF i find a way to support more modes GENERICALLY in syscons, they will automatically be supported. If there is enough interest I'll bring the lib up to shape and put it in the tree somewhere so we have generic graph support. PS: Most games are written in 320x200x256 anyways, so we could use a couble of native ports :) :) :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 01:36:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA20508 for hackers-outgoing; Wed, 27 Sep 1995 01:36:40 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA20479 for ; Wed, 27 Sep 1995 01:36:21 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id KAA12060; Wed, 27 Sep 1995 10:36:09 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id KAA15591; Wed, 27 Sep 1995 10:36:08 +0200 Message-Id: <199509270836.KAA15591@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Wed, 27 Sep 1995 10:36:08 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > Please describe your machines in detail...output of dmesg would be a good > start. OK - dmesg: FreeBSD 2.1-STABLE #0: Sat Sep 23 12:11:24 1995 root@grudge.grondar.za:/a/src/sys/compile/IAFRICA CPU: i486DX (486-class CPU) real memory = 33554432 (32768K bytes) avail memory = 31465472 (30728K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 5 on isa ed0: address 00:40:f6:20:72:6f, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface Probing for devices on the PCI bus: ahc0 rev 0 int a irq 11 on pci0:13 ahc0: 2940 Single Channel, SCSI Id=7, aic7870, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "HP C3724S 4349" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1149MB (2354660 512 byte sectors) pci0:16: UMC, device=0x8881, class=bridge (host) [no driver assigned] pci0:18: UMC, device=0x886a, class=bridge (isa) [no driver assigned] ...and mu config file: # # IAFRICA -- Internet Africa # machine "i386" cpu "I486_CPU" ident IAFRICA maxusers 16 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options PROCFS #Process filesystem options KERNFS #Process filesystem options KTRACE #kernel tracing options "COMPAT_43" #Compatible with BSD 4.3 options "SCSI_DELAY=5" #Be pessimistic about Joe SCSI device #options BOUNCE_BUFFERS #options UCONSOLE config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 controller ahc0 controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log #pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 2 #Snoop device - to look at pty/vty/etc.. > >At the same spot for me. I was suspecting memory/cache problems, so far I > >have ruled out the cache. > > There was one other report about things dieing when one of the shared > libraries got out of sync, but after that was fixed the problems went away. > If you have the ability to try 2.1-stable on different hardware, but with > the same disk drive and binaries, this might help isolate the problem. I have tried a different SCSI controller - briefly. It seemed to work. > It might also help if you could install the new 0922 snapshot. Difficult. My connection is damn slow. This would take a few days :-( M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Wed Sep 27 01:46:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21310 for hackers-outgoing; Wed, 27 Sep 1995 01:46:24 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA21305 for ; Wed, 27 Sep 1995 01:46:19 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id BAA00794; Wed, 27 Sep 1995 01:45:52 -0700 Message-Id: <199509270845.BAA00794@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Christoph Kukulies cc: hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-reply-to: Your message of "Wed, 27 Sep 1995 08:31:51 BST." <199509270731.IAA11353@gilberto.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Sep 1995 01:45:51 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Well, I just took a quick look at it and again I think is a mess. I would rather cut out the XFree86 low level graphic support and make it into a library than to mess with the so called svgalib. However, if you guys want to go at it have it :) 0.25 cents... Amancio >>> Christoph Kukulies said: > > > > The biggest problem with the svgalib is its lack of support for svga > > cards. For instance, the last time that I checked there was no > > support for S3 cards . I guess a good starting point will be to > > port whatever is available then include a lot of the XFree86 init > > and graphic routines. The effort is almost not worth it -- at least > > from my point and view . I suggest doing a net search for a better packag e. > > I didn't take a look at it yet but I don't regard it such useless > if it supports at least the standard vga modes and eventually > a 256 color mode. It would be ideal to be incorporated into Jordans > new sysinstall stuff to allow for ('better') graphical setup > look and feel (a la Win95, ducking and holding hands against ears :-) > > I dropped the original posting of Olof Johansson. Can someone give the > coordinates of the package (vgalib) please once again? > If it's GPL'ed it's ruled out as a candidate for > graphical install stuff, of course. > > > > > My 0.2 graphical cents > > Amancio > > > > >>> J Wunsch said: > > > As Olof Johansson wrote: > > > > > > > > A couple of months ago someone mentioned that he/she had ported an ol d > > > > vgalib from linux to FreeBSD. I'd like to know how old that version w as, > > > > and how much work it'd be to port the latest version. :) > > > > > > I think somebody is porting it for NetBSD. > > > > > > -- > > > cheers, J"org > > > > > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ > > > Never trust an operating system you don't have sources for. ;-) > > > > > > > > > > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Sep 27 02:07:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA22881 for hackers-outgoing; Wed, 27 Sep 1995 02:07:56 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA22851 for ; Wed, 27 Sep 1995 02:07:40 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id LAA12097; Wed, 27 Sep 1995 11:07:10 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id LAA22148; Wed, 27 Sep 1995 11:07:09 +0200 Message-Id: <199509270907.LAA22148@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Wed, 27 Sep 1995 11:07:08 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > >I have tried a different SCSI controller - briefly. It seemed to work. > > Make sure you enable bounce buffers before you stick that 1542C in. :-) Thanks (wry smile). I got bitten by that first time round. :-) > >Difficult. My connection is damn slow. This would take a few days :-( > > Don't worry about it; I think it is becoming clear that the problem is > related to the 2940. You might try slowing down the SCSI bus to 5Mhz and > see if the problem is helped any by this. Will do, in fact I have a -stable make world running right now. I'll keep you posted. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Wed Sep 27 02:11:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA23158 for hackers-outgoing; Wed, 27 Sep 1995 02:11:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA23137 ; Wed, 27 Sep 1995 02:11:07 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA14492; Wed, 27 Sep 1995 19:10:02 +1000 Date: Wed, 27 Sep 1995 19:10:02 +1000 From: Bruce Evans Message-Id: <199509270910.TAA14492@godzilla.zeta.org.au> To: nate@rocky.sri.MT.net, roberto@keltia.freenix.fr Subject: Re: Diskslice naming convention? Cc: bde@FreeBSD.org, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> BTW - Are slices named 1-4 or 0-3? >1-4, 0 is the compatibility slice. There is no slice named 0. Slice _number_ 0 is the compatibility slice. Slice _number_ 1 is the whole disk. The slices that are _numbered_ 2-31 are _named_ 1-30. Bruce From owner-freebsd-hackers Wed Sep 27 02:20:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA23618 for hackers-outgoing; Wed, 27 Sep 1995 02:20:30 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA23591 ; Wed, 27 Sep 1995 02:20:20 -0700 Message-Id: <199509270920.CAA23591@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 27 Sep 1995 02:20:18 -0700 (PDT) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org In-Reply-To: <199509270845.BAA00794@rah.star-gate.com> from "Amancio Hasty Jr." at Sep 27, 95 01:45:51 am From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1266 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Amancio Hasty Jr. who wrote: > > > Well, I just took a quick look at it and again I think is a mess. I did the exact same thing the last half hour, and I completly agree, its a mess.And really guys I dont se what it gives us it has only very limitted chipset support, so we will get TONS of requests for other architectures, not my ideal way of spending a good time. As I allready stated before, use the generic modes allready supported by syscons, or use X, everything else is goin to be a nightmare on code street. However I'm willing to put some work into a library for doing the generic modes via syscons (In fact I allready have one :) ) > I would rather cut out the XFree86 low level graphic support and > make it into a library than to mess with the so called svgalib. Oh, well why not use X then for purposes that require high res/many colors?? everything else is reinventing the wheel. Besides doing real time graphics in high res isnt going to work anyways on 90% of the PC hardware out there, no matter what implementation we use. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 02:30:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA24183 for hackers-outgoing; Wed, 27 Sep 1995 02:30:23 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA24174 ; Wed, 27 Sep 1995 02:30:15 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id CAA02931; Wed, 27 Sep 1995 02:30:08 -0700 Message-Id: <199509270930.CAA02931@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: sos@freebsd.org cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-reply-to: Your message of "Wed, 27 Sep 1995 02:20:18 PDT." <199509270920.CAA23591@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Sep 1995 02:30:07 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk >>> sos@freebsd.org said: > > Oh, well why not use X then for purposes that require > high res/many colors?? everything else is reinventing the wheel. > Besides doing real time graphics in high res isnt going to work > anyways on 90% of the PC hardware out there, no matter what > implementation we use. Well, there is the slight matter of size with X and a process context switch for a batch of graphic operations or a process context switch per operation if you use Xsync mode --- Not my favorite idea of fast graphics. The reason why I like the XFree86 approach is for the existing support for low level graphic primitives such as line drawing , etc... Now a minimal X installation does not take that much space so we could follow that route for installs from CDs. Thats all folks , I peacefully return to my multimedia stuff :) Happy Hacking! Amancio From owner-freebsd-hackers Wed Sep 27 02:38:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA24829 for hackers-outgoing; Wed, 27 Sep 1995 02:38:41 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA24820 for ; Wed, 27 Sep 1995 02:38:31 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id KAA12409; Wed, 27 Sep 1995 10:36:58 +0100 Date: Wed, 27 Sep 1995 10:36:57 +0100 (MET) From: Olof Johansson To: "Amancio Hasty Jr." cc: Joerg Wunsch , hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-Reply-To: <199509270537.WAA13001@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Tue, 26 Sep 1995, Amancio Hasty Jr. wrote: > The biggest problem with the svgalib is its lack of support for svga > cards. For instance, the last time that I checked there was no > support for S3 cards . I guess a good starting point will be to > port whatever is available then include a lot of the XFree86 init > and graphic routines. The effort is almost not worth it -- at least > from my point and view . I suggest doing a net search for a better package. Since svgalib is the only graphics package for linux (or any other pc-unix) I've seen I don't have too much to compare it with. I think that a fairly easy-ported, not-too-good packages is better than none though. I have an unsupported S3 card myself. :-( (#9 GXE) These are the supported chipsets (from the README, sorry for the long list): VGA and compatibles 320x200x256, and the series of 16-color and non-standard planar 256 color modes supported by VGAlib, as well as 720x348x2. Cirrus Logic GD542x/3x All the modes, including 256 color, 32K/64K color, 16M color (3 bytes per pixel) and 32-bit pixel 16M color modes (5434). Some bitblt functions are supported. The driver doesn't work with mode dumps, but uses a SVGA abstraction with mode timings like the X drivers. Tseng ET4000/ET4000W32(i/p) Derived from VGAlib; not the same register values. ET4000 register values are not compatible; see et4000/README. Make sure the colors are right in hicolor mode; the vgatest program should draw the same color bars for 256 and hicolor modes (the DAC type is defined in et4000.regs or the dynamic registers file). ET4000/W32 based cards usually have an AT&T or Sierra 15025/6 DAC. With recent W32p based cards, you might have some luck with the AT&T DAC type. If the high resolution modes don't work, you can try dumping the registers in DOS using the program in the et4000 directory and putting them in a file (/etc/vga/libvga.et4000 is parsed at runtime if DYNAMIC is defined in config.h). 640x480x256, 800x600x256, 1024x768x256, 640x480x32K, 800x600x32K, 640x480x16M, etc. Reports of ET4000/W32i/p functionality are welcome. There may be a problem with the way the hicolor DAC register is handled; dumped registers may use one of two timing methods, with the value written to the register for a particular DAC for a hicolor mode (in vgahico.c) being correct for just one of the these methods. As a consequence some dumped resolutions may work while others don't. Trident TVGA 8900C/9000 (and possibly also 8800CS/8900A/B) Derived from tvgalib by Toomas Losin. 640x480x256, 800x600x256, 1024x768x256 (I and NI) Might be useful to add 16-color modes (for those equipped with a 512K TVGA9000). Oak Technologies OTI-037/67/77/87 Driver by Christopher Wiles; includes 32K color modes for OTI-087. See README.oak. ATI Mach32 The alpha driver by Michael Weller supports all BIOS-defined modes. However, non-Type 2 DAC's are untested. Check out README.mach32 (and README.config). Do send feedback. S3 The driver is not complete, but should work on a number of cards/RAMDACs, and 6408x480x256 should be work on most card. The best support is for a 801/805 with AT&T20C490-compatible RAMDAC, and S3-864 + SDAC. Clocks and Ramdac lines in config file supported. Clocks should be the same as in XFree86. Supported ramdac IDs: Sierra32K, SDAC, GenDAC, ATT20C490, ATT20C498 Example: Clocks 25.175 28.3 40 70 50 75 36 44.9 0 118 77 31.5 110 65 72 93.5 Ramdac att20c490 ARK Logic ARK1000PV/2000PV Full support, limited RAMDAC support. Only ARK1000PV tested. Supports Clocks and Ramdac lines in config file. From owner-freebsd-hackers Wed Sep 27 03:06:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA26398 for hackers-outgoing; Wed, 27 Sep 1995 03:06:35 -0700 Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA26393 for ; Wed, 27 Sep 1995 03:06:29 -0700 Received: (from vince@localhost) by apollo.COSC.GOV (8.6.11/8.6.9) id DAA05193; Wed, 27 Sep 1995 03:05:36 -0700 Date: Wed, 27 Sep 1995 03:05:35 -0700 (PDT) From: -Vince- To: FreeBSD-hackers@Freefall.FreeBSD.ORG Subject: can't delete chfn Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk I am trying to do a make world with the latest current and somehow it won't overwrite chfn no matter what I do... root@apollo [3:03am][/usr/src/usr.bin/chpass] >> make cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/chpass.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/edit.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/field.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/pw_copy.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb/pw_scan.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/../../usr.sbin/vipw/pw_util.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/table.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/util.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/pw_yp.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -o chpass chpass.o edit.o field.o pw_copy.o pw_scan.o pw_util.o table.o util.o pw_yp.o -lrpcsvc -lcrypt root@apollo [3:03am][/usr/src/usr.bin/chpass] >> make install [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass install -c -s -o root -g bin -m 4555 chpass /usr/bin /usr/bin/chfn -> /usr/bin/chpass rm: /usr/bin/chfn: Operation not permitted *** Error code 1 Stop. root@apollo [3:03am][/usr/src/usr.bin/chpass] >> cd /usr/bin root@apollo [3:03am][/usr/bin] >> dir chfn -r-sr-xr-x 1 root bin 20480 Jul 26 07:57 chfn root@apollo [3:04am][/usr/bin] >> rm chfn override r-sr-xr-x root/bin schg for chfn? y rm: chfn: Operation not permitted root@apollo [3:04am][/usr/bin] >> Anyone have any ideas what I can do so that make world will not quit and update this file with a new one? Thanks for any help in advance! Cheers, -Vince- vince@apollo.COSC.GOV - GUS Mailing Lists Admin UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center Running FreeBSD - Real UN*X for Free! From owner-freebsd-hackers Wed Sep 27 03:31:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA27164 for hackers-outgoing; Wed, 27 Sep 1995 03:31:18 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA27159 ; Wed, 27 Sep 1995 03:31:08 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id LAA12898; Wed, 27 Sep 1995 11:29:47 +0100 Date: Wed, 27 Sep 1995 11:29:46 +0100 (MET) From: Olof Johansson To: sos@freebsd.org cc: "Amancio Hasty Jr." , kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-Reply-To: <199509270920.CAA23591@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Wed, 27 Sep 1995 sos@freebsd.org wrote: > In reply to Amancio Hasty Jr. who wrote: > > > > > > Well, I just took a quick look at it and again I think is a mess. > > I did the exact same thing the last half hour, and I completly > agree, its a mess.And really guys I dont se what it gives us > it has only very limitted chipset support, so we will get > TONS of requests for other architectures, not my ideal way of > spending a good time. > As I allready stated before, use the generic modes allready > supported by syscons, or use X, everything else is goin to be a > nightmare on code street. > However I'm willing to put some work into a library for doing > the generic modes via syscons (In fact I allready have one :) ) Fine. :) I only want a VGA programming package. :-) > Oh, well why not use X then for purposes that require > high res/many colors?? everything else is reinventing the wheel. > Besides doing real time graphics in high res isnt going to work > anyways on 90% of the PC hardware out there, no matter what > implementation we use. High res is a problem, but for low-res usage (say, installation software or whatever) X is sometimes too big. -Olof From owner-freebsd-hackers Wed Sep 27 05:26:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29088 for hackers-outgoing; Wed, 27 Sep 1995 05:26:34 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29079 ; Wed, 27 Sep 1995 05:26:32 -0700 Message-Id: <199509271226.FAA29079@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: offe@dawnrazor.campus.luth.se (Olof Johansson) Date: Wed, 27 Sep 1995 05:26:32 -0700 (PDT) Cc: sos@freebsd.org, hasty@rah.star-gate.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org, jkh@freebsd.org In-Reply-To: from "Olof Johansson" at Sep 27, 95 11:29:46 am From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1571 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Olof Johansson who wrote: > > As I allready stated before, use the generic modes allready > > supported by syscons, or use X, everything else is goin to be a > > nightmare on code street. > > However I'm willing to put some work into a library for doing > > the generic modes via syscons (In fact I allready have one :) ) > > Fine. :) I only want a VGA programming package. :-) > OK, ´give me a couble of days and I'll provide you with a library that allows the std VGA modes to be used, plus some low level primitives to start with. That should get us going, then let me know what functionality is needed and I'll do something about it as we go. > > Oh, well why not use X then for purposes that require > > high res/many colors?? everything else is reinventing the wheel. > > Besides doing real time graphics in high res isnt going to work > > anyways on 90% of the PC hardware out there, no matter what > > implementation we use. > > High res is a problem, but for low-res usage (say, installation software > or whatever) X is sometimes too big. I'd be willing to do (or help doing) a library that has some or all of the libdialog functionality (plus whats needed for graphmode stuff) for implementing this, if someone then will take on the task of making the install/sysadm/whatever tools that we so badly need... (jordan are you listening??) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 05:49:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29487 for hackers-outgoing; Wed, 27 Sep 1995 05:49:59 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA29482 for ; Wed, 27 Sep 1995 05:49:56 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA04985 (5.67a/IDA-1.5 for hackers@freebsd.org); Wed, 27 Sep 1995 07:26:26 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id GAA08951 for asami@cs.berkeley.edu; Wed, 27 Sep 1995 06:28:15 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509271128.GAA08951@bonkers.taronga.com> Subject: Re: Problems with packages, and general third party software. To: hackers@freebsd.org Date: Wed, 27 Sep 1995 06:28:14 -0500 (CDT) In-Reply-To: <199509262351.QAA01175@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Sep 26, 95 04:51:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 216 Sender: owner-hackers@freebsd.org Precedence: bulk > Can't we solve this by making the executable setgid-operator instead > of setuid-operator? Since it's run by "operator" from cron, it doesn't have to be setuid-anything, really, if you have the permissions right. From owner-freebsd-hackers Wed Sep 27 05:51:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29539 for hackers-outgoing; Wed, 27 Sep 1995 05:51:53 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA29530 for ; Wed, 27 Sep 1995 05:51:45 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA05112 (5.67a/IDA-1.5); Wed, 27 Sep 1995 07:46:53 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA10105; Wed, 27 Sep 1995 07:32:24 -0500 Date: Wed, 27 Sep 1995 07:32:24 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509271232.HAA10105@bonkers.taronga.com> To: kelly@fsl.noaa.gov, hackers@freebsd.org Subject: Re: ports startup scripts In-Reply-To: <9509261306.AA14836@emu.fsl.noaa.gov> References: <199509260541.AAA04042@chrome.jdl.com> Organization: Taronga Park BBS Sender: owner-hackers@freebsd.org Precedence: bulk In article <9509261306.AA14836@emu.fsl.noaa.gov>, Sean Kelly wrote: >That suggests to me that our startup ought to be driven by make and >not sh, then. But then there's the problem of auto-editing Makefiles. No, don't auto-*edit* makefiles. Auto-*generate* makefiles. exec 3>&1 exec >/etc/Makefile cat /etc/pkg.d/.base/Makefile start="start:" stop="stop:" for i in /etc/pkg.d/* do pkg=`basename $i` if [ -f $i/start.mk ] then if [ -f $i/start.dep ] then echo "$pkg-start: `cat $i/start.dep`" else echo "$pkg-start:" fi cat $i/start.mk start="$start $pkg-start" fi echo "" if [ -f $i/stop.mk ] then if [ -f $i/stop.dep ] then echo "$pkg-stop: `cat $i/stop.dep`" else echo "$pkg-stop:" fi cat $i/stop.mk stop="$stop $pkg-stop" fi echo "" done echo $start echo $stop exec >&3 exec 3>&- Now you can "cd /etc; make start". >Maybe we can auto-edit Imakefiles more safely? Imake is *evil*. Evil, evil, evil, evil. Using cpp as a general preprocessor works, barely, for X. Don't drive anything else down that path. From owner-freebsd-hackers Wed Sep 27 05:55:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29625 for hackers-outgoing; Wed, 27 Sep 1995 05:55:25 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA29620 for ; Wed, 27 Sep 1995 05:55:19 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id IAA25056; Wed, 27 Sep 1995 08:41:56 -0400 Date: Wed, 27 Sep 1995 08:41:55 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: Andreas Klemm cc: hackers@freebsd.org In-Reply-To: <199509262133.WAA00394@knobel.gun.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Tue, 26 Sep 1995, Andreas Klemm wrote: > Someone with a working -stable here ?! Since weeks unable to > get a FreeBSD release compiled without that messages like: > > internal compiler error .... signal 11 ... i have been doing make world's on stable most nights. the only Error that i encounter is: ===> usr.sbin/rmt ln -s /usr/sbin/rmt /etc/rmt ln: /etc/rmt: File exists *** Error code 1 (ignored) Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Wed Sep 27 06:10:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA29861 for hackers-outgoing; Wed, 27 Sep 1995 06:10:45 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA29856 for ; Wed, 27 Sep 1995 06:10:41 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA14526 for ; Wed, 27 Sep 1995 06:10:37 -0700 To: hackers@freebsd.org Subject: Bulletins for 2.1.0-950922-SNAP: Date: Wed, 27 Sep 1995 06:10:36 -0700 Message-ID: <14524.812207436@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Problem: 4MB machines appear to have overflowed again. Work-around: None. Fix: Must shrink size of GENERIC kernel again. Problem: Using the new (W)rite option in the disklabel editor causes a hang. Work-around: Don't use the Write command from the disklabel editor. Let the final "commit" action write it out. Fix: Will make error checking for "prerequisites" more robust in general. Problem: FTP login failures don't report status. Work-around: Don't have any login failures. :-) Fix: Make FTP setup code more robust. That is all (for now)! Jordan From owner-freebsd-hackers Wed Sep 27 06:23:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA00310 for hackers-outgoing; Wed, 27 Sep 1995 06:23:21 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA00305 ; Wed, 27 Sep 1995 06:23:13 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA14565; Wed, 27 Sep 1995 06:23:06 -0700 To: sos@freebsd.org cc: hasty@rah.star-gate.com (Amancio Hasty Jr.), kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org Subject: Re: vgalib for FreeBSD! In-reply-to: Your message of "Wed, 27 Sep 1995 02:20:18 PDT." <199509270920.CAA23591@freefall.freebsd.org> Date: Wed, 27 Sep 1995 06:23:06 -0700 Message-ID: <14563.812208186@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > However I'm willing to put some work into a library for doing > the generic modes via syscons (In fact I allready have one :) ) Yea! I agree with Amancio that lopping off the bottom half of X would be a really cool general solution, but let's face it - it's also a solution that will likely never happen and is therefore not something I'd like to bet the farm on. Add complexity to the solution and you also add to the calendar ship date! :-) I'd like something that simply gave me basic line graphics in 320x200 resolution or so. Then I could go implement all those cool GUI objects I've been talking about with a dynamic rendering model that allows fall-back to ncurses character graphics rendering in a pinch. Jordan From owner-freebsd-hackers Wed Sep 27 06:35:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA00622 for hackers-outgoing; Wed, 27 Sep 1995 06:35:33 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA00613 ; Wed, 27 Sep 1995 06:35:29 -0700 Message-Id: <199509271335.GAA00613@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 27 Sep 1995 06:35:29 -0700 (PDT) Cc: sos@freebsd.org, hasty@rah.star-gate.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org In-Reply-To: <14563.812208186@time.cdrom.com> from "Jordan K. Hubbard" at Sep 27, 95 06:23:06 am From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1912 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > > > However I'm willing to put some work into a library for doing > > the generic modes via syscons (In fact I allready have one :) ) > > Yea! Ok, I'll go ahead... > I agree with Amancio that lopping off the bottom half of X would be a > really cool general solution, but let's face it - it's also a solution > that will likely never happen and is therefore not something I'd like > to bet the farm on. Add complexity to the solution and you also add > to the calendar ship date! :-) And we would still not support all the chipsets out there :( (My lovely P9100 comes to mind) Using ONLY the std VGA modes is perhaps not new technology, but it works on all platforms (VGA that is).. > I'd like something that simply gave me basic line graphics in 320x200 > resolution or so. Then I could go implement all those cool GUI objects > I've been talking about with a dynamic rendering model that allows > fall-back to ncurses character graphics rendering in a pinch. You got it ! ftp://login.dknet.dk/pub/sos/libdgl.tar.gz This framework even has simple sprite functions, that allows simple animation, plus lines, text, circles..... I'll look at this over the next couble of days, and decide hat else is needed (sure all the other std modes, this old libdgl is harwired for 320x200x256). Then lets put all the GUI stuff on top of this and we would have a really cool interface tool for writing all kinds of little usefull tools with a modern look&feel. It all reminds me of good old MGR, maybe we can steal^H^H^H^H^H borrow some functionality from that (it could even give us a graphics mode console .... now I'll stop fantasising... > > Jordan > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 06:43:24 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA00837 for hackers-outgoing; Wed, 27 Sep 1995 06:43:24 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA00831 for hackers@freefall; Wed, 27 Sep 1995 06:43:23 -0700 Date: Wed, 27 Sep 1995 06:43:23 -0700 From: "Jordan K. Hubbard" Message-Id: <199509271343.GAA00831@freefall.freebsd.org> To: hackers@freefall.FreeBSD.org Subject: Whither XFree86 3.1.2? Sender: owner-hackers@FreeBSD.org Precedence: bulk Was this never released for FreeBSD? I don't see anything in ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. People are asking why 2.1 doesn't appear to be going out with it! :-( Jordan From owner-freebsd-hackers Wed Sep 27 06:50:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01023 for hackers-outgoing; Wed, 27 Sep 1995 06:50:26 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01017 for ; Wed, 27 Sep 1995 06:50:19 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id JAA20564; Wed, 27 Sep 1995 09:53:33 -0400 Date: Wed, 27 Sep 1995 09:53:33 -0400 From: Coranth Gryphon Message-Id: <199509271353.JAA20564@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@freebsd.org Precedence: bulk From: Terry Lambert > +> > From: Coranth Gryphon > +> > +> Here we are in agreement. But I think trying to make a read-only >> + > +> configuration is a lot more hassle than it is worth. > +> > +> > Argument: boot from CDROM to see if you can successfully run the > +> > new version on your particular hardware. > +> > +> If you go to the extent to make the CDROM bootable, making the sample > +> configuration (sample /etc) a valid one shouldn't be all that tough. > Counter-counter: IP addreses and default name servers and gateway > can not be preconfigured on a CDROM. Therefore the must be in a non-ROM > (MFS?) location. Why does the IP information need to be stored on the file-system? The CDRom bootable /etc comes with a script that asks for the IP data (much like the 2.0.5 Sysinstall did) and does the configuration. Once the hostname and ifconfig and routes are done, what needs to be stored? The only reason to store stuff on disk is for permanent configuration. Which is all the more reason I say to NOT have a read-only /etc. If you want a diskless/dataless setup, either rely on bootp/DCHP (as you earlier claimed to want to for this type of thing) or force the user to enter those half-dozen pieces of information (host/domain, route, nameserver, ip-addr, netmask) upon boot-up from the CDRom. That'll give a running (unchangeable) configuration. Somewhere, at some point, you need to make permanent changes to the configuration of a machine, even if it is diskless. With prices for hard-disks down around our ankles, the need for diskless FreeBSD machines is functionally NIL. If someone really wants that setup, they have to configure the remote server anyway, to server the root file-system for that machine. What's so hard about configuring it for each machine? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 06:54:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA01096 for hackers-outgoing; Wed, 27 Sep 1995 06:54:26 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA01090 for ; Wed, 27 Sep 1995 06:54:18 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id JAA20583; Wed, 27 Sep 1995 09:57:26 -0400 Date: Wed, 27 Sep 1995 09:57:26 -0400 From: Coranth Gryphon Message-Id: <199509271357.JAA20583@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk From: Terry Lambert > I want to replace the SMTP agent with my own. What is the current > agent's name? How did you determine this? How is ANY automated procedure going to determine this? And if you just "add a script to the directory" then both will be running. So you have to delete the old daemon, and put the new one in. Either you have an automated means to do this, or you don't. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 07:01:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01230 for hackers-outgoing; Wed, 27 Sep 1995 07:01:12 -0700 Received: from fang.cs.sunyit.edu (fang.cs.sunyit.edu [192.52.220.66]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA01225 for ; Wed, 27 Sep 1995 07:01:08 -0700 Received: (from uttt@localhost) by fang.cs.sunyit.edu (8.6.9/8.6.9) id KAA13023 for hackers@freefall.freebsd.org; Wed, 27 Sep 1995 10:01:06 -0400 Date: Wed, 27 Sep 1995 10:01:06 -0400 From: "Tom T. Tran" Message-Id: <199509271401.KAA13023@fang.cs.sunyit.edu> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hackers@freefall.freebsd.org Subject: Solaris x86 Sender: owner-hackers@FreeBSD.org Precedence: bulk With all the talk of SCO compatability and Linux compatability I was wondering if perhaps Solaris x86 might be on the horizon. I'm curious as to whether or not having the system call wrappers for Linux and SCO bring us any closer to having Solaris x86 binary compatability. -- If you can lead it to water and force it to drink, it isn't a horse. From owner-freebsd-hackers Wed Sep 27 07:15:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01508 for hackers-outgoing; Wed, 27 Sep 1995 07:15:02 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA01497 for ; Wed, 27 Sep 1995 07:14:58 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id HAA18110; Wed, 27 Sep 1995 07:12:55 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA02318; Wed, 27 Sep 1995 07:18:36 -0700 Date: Wed, 27 Sep 1995 07:18:36 -0700 Message-Id: <9509271418.AA02318@asimov.volant.org> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> From: Terry Lambert |> > I want to replace the SMTP agent with my own. What is the current |> > agent's name? How did you determine this? |> |> How is ANY automated procedure going to determine this? |> |> And if you just "add a script to the directory" then both will be running. |> So you have to delete the old daemon, and put the new one in. |> |> Either you have an automated means to do this, or you don't. True. But consider what happens if you then install something that has a startup dependancy on having an SMTP server running. If it is using a fixed sequence number, it doesn't care what the SMTP server is called; it just assumes that any replacement will use the same sequence number as the original. But if you are trying to do install-time dependancy checking, it must somehow be told the new SMTP service name. -Pat From owner-freebsd-hackers Wed Sep 27 07:17:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01653 for hackers-outgoing; Wed, 27 Sep 1995 07:17:40 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01643 ; Wed, 27 Sep 1995 07:17:37 -0700 Message-Id: <199509271417.HAA01643@freefall.freebsd.org> Subject: Re: Solaris x86 To: uttt@fang.cs.sunyit.edu (Tom T. Tran) Date: Wed, 27 Sep 1995 07:17:36 -0700 (PDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509271401.KAA13023@fang.cs.sunyit.edu> from "Tom T. Tran" at Sep 27, 95 10:01:06 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 776 Sender: owner-hackers@FreeBSD.org Precedence: bulk In reply to Tom T. Tran who wrote: > > With all the talk of SCO compatability and Linux compatability I was > wondering if perhaps Solaris x86 might be on the horizon. I'm curious as to > whether or not having the system call wrappers for Linux and SCO bring us > any closer to having Solaris x86 binary compatability. Hmm, I'm not sure exactly what slowlaris resembels most, but I guess its SVR4 like. Do you know what kind of binary format they use ?? I have the codebits for running simple SVR4 ELF binaries from a NCR system, that might be a starting point. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 07:28:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01958 for hackers-outgoing; Wed, 27 Sep 1995 07:28:13 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA01947 for ; Wed, 27 Sep 1995 07:28:04 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA20707; Wed, 27 Sep 1995 10:31:35 -0400 Date: Wed, 27 Sep 1995 10:31:35 -0400 From: Coranth Gryphon Message-Id: <199509271431.KAA20707@healer.com> To: hackers@freebsd.org, kelly@fsl.noaa.gov, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Wed Sep 27 09:18:24 1995 Date: Wed, 27 Sep 1995 07:32:24 -0500 To: kelly@fsl.noaa.gov, hackers@freebsd.org Subject: Re: ports startup scripts In-Reply-To: <9509261306.AA14836@emu.fsl.noaa.gov> References: <199509260541.AAA04042@chrome.jdl.com> Organization: Taronga Park BBS Sender: owner-hackers@freebsd.org Precedence: bulk From: peter@taronga.com (Peter da Silva) Sean Kelly wrote: > >That suggests to me that our startup ought to be driven by make and >No, don't auto-*edit* makefiles. Auto-*generate* makefiles. That gets my vote. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 07:36:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02302 for hackers-outgoing; Wed, 27 Sep 1995 07:36:02 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02297 for ; Wed, 27 Sep 1995 07:35:54 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA20743; Wed, 27 Sep 1995 10:38:39 -0400 Date: Wed, 27 Sep 1995 10:38:39 -0400 From: Coranth Gryphon Message-Id: <199509271438.KAA20743@healer.com> To: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk >From patl@asimov.volant.org Wed Sep 27 10:19:47 1995 Date: Wed, 27 Sep 1995 07:18:36 -0700 To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII From: patl@asimov.volant.org |> Either you have an automated means to do this, or you don't. > True. But consider what happens if you then install something that > has a startup dependancy on having an SMTP server running. If it > is using a fixed sequence number, it doesn't care what the SMTP > server is called; it just assumes that any replacement will use the The makefile concept done a little carefully takes care of this: We have the mail depenendcy be smtp-daemon: sendmail $SENDMAIL_ARGS package: smtp-daemon Now it doesn't care what the smtp-daemon target does, as long as it executes successfully. (This assume compatibility between the two different SMTP daemons for package purposes, but if you don't have that the point is moot anyway). -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 07:44:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02494 for hackers-outgoing; Wed, 27 Sep 1995 07:44:44 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02484 ; Wed, 27 Sep 1995 07:44:37 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA17099; Wed, 27 Sep 1995 08:45:43 -0600 Date: Wed, 27 Sep 1995 08:45:43 -0600 From: Nate Williams Message-Id: <199509271445.IAA17099@rocky.sri.MT.net> To: Bruce Evans Cc: hackers@FreeBSD.org, nate@rocky.sri.MT.net, bde@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509270621.QAA08365@godzilla.zeta.org.au> References: <199509270621.QAA08365@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans writes: > >So, am I right in saying that other than the 'compatability' slice of > >/dev/xd#a for the root partition, the naming scheme is as follows: > > >X = generic device name. > ># = disk number > >Y = slice number (ie; one of the 4 'fdisk' partions') > > >Xd#asY (where 'a' could be any lower-case letter 'a-h') > > No, Y may be any fdisk partition or logical drive, and 'a' follows the > slice number. Whoops, you're right. (of course) Xd#sYa (where 'a' could be any lower-case letter 'a-h'). > >BTW - Are slices named 1-4 or 0-3? > > No, slices are named 1-30. Ok. How do the 'fdisk' slices (of which there can only be 4) relate to the 30 slices available in FreeBSD. Excuse me for using DOS terminology for a minute, but if I understand correctly, we can use 'extended' partitions inside of 'primary' partitions. However, 30/4 isn't a real number, so where does the magic number 30 come from? > >Anyway, we create a FreeBSD slice by setting it's ID to 0xA5. Then, we > >build a disklabel onto this 'slice' which gives us individual partitions > >on that slice. Are there any 'special' partitions in this disklabel? > > c. > > >How would I read the *entire* FreeBSD portion of the slice? How about > > There is no such thing as a `portion' of a slice. (Would a portion be > smaller or larger than a partition? :-).) `dd if=/dev/rxd#sY' or `dd > if=/dev/rxd#sYc' reads the entire slice sY. These devices are > identical. /dev/MAKEDEV creates both for convenience. The c partition > is special whether there is a disklabel describing it or not. If there > is a disklabel, the c partition should match the whole slice. > > >the entire disk? How do I create a FreeBSD partition which accesses a > >DOS slice? > > `dd if=/dev/rxd#' reads the entire disk. /dev/rxd# is a completely > different device from /dev/rxd#c. These devices are often confused > because disklabel automatically translates from `xd#' to /dev/rxd#c'. Ahh, so these are equivalent # dd if=/dev/sd0c of=/dev/null # dd if=/dev/sd0 of=/dev/null (Read the entire slice) Vs. # dd if=/dev/rsd0 of=/dev/null (Read the entire disk) > You can't create a FreeBSD partition which accesses a DOS slice. Just > access the DOS slice directly. Ok. How do I know which slice is the DOS slice? (This get's back to the determination of the numbering scheme 1-30) Nate From owner-freebsd-hackers Wed Sep 27 07:46:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02581 for hackers-outgoing; Wed, 27 Sep 1995 07:46:32 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02573 ; Wed, 27 Sep 1995 07:46:22 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA17104; Wed, 27 Sep 1995 08:47:36 -0600 Date: Wed, 27 Sep 1995 08:47:36 -0600 From: Nate Williams Message-Id: <199509271447.IAA17104@rocky.sri.MT.net> To: Bruce Evans Cc: nate@rocky.sri.MT.net, roberto@keltia.freenix.fr, bde@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509270910.TAA14492@godzilla.zeta.org.au> References: <199509270910.TAA14492@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans writes: > >> BTW - Are slices named 1-4 or 0-3? > > >1-4, 0 is the compatibility slice. > > There is no slice named 0. Slice _number_ 0 is the compatibility slice. > Slice _number_ 1 is the whole disk. The slices that are _numbered_ 2-31 > are _named_ 1-30. Whoa. I'm lost now w/regards to the compatability slice. How exactly is the compatability slice named, and how does it fit into the 'slice' paradigm? Nate From owner-freebsd-hackers Wed Sep 27 07:58:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02902 for hackers-outgoing; Wed, 27 Sep 1995 07:58:10 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02897 ; Wed, 27 Sep 1995 07:57:48 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id QAA04923; Wed, 27 Sep 1995 16:55:27 +0200 From: John Hay Message-Id: <199509271455.QAA04923@zibbi.mikom.csir.co.za> Subject: Re: Whither XFree86 3.1.2? To: jkh@freefall.freebsd.org (Jordan K. Hubbard) Date: Wed, 27 Sep 1995 16:55:26 +0200 (SAT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509271343.GAA00831@freefall.freebsd.org> from "Jordan K. Hubbard" at Sep 27, 95 06:43:23 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 397 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Was this never released for FreeBSD? I don't see anything in > ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. > > People are asking why 2.1 doesn't appear to be going out with it! :-( > > Jordan > I think it was never picked up by ftp.cdrom.com because I found it on ref.tfs.com:/pub/mirrors/XFree86 and on ftp.XFree86.ORG John -- John Hay -- John.Hay@csir.co.za From owner-freebsd-hackers Wed Sep 27 07:59:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA02999 for hackers-outgoing; Wed, 27 Sep 1995 07:59:23 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA02989 for ; Wed, 27 Sep 1995 07:59:18 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA17146; Wed, 27 Sep 1995 09:01:25 -0600 Date: Wed, 27 Sep 1995 09:01:25 -0600 From: Nate Williams Message-Id: <199509271501.JAA17146@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: hackers@freebsd.org Subject: Re: Bulletins for 2.1.0-950922-SNAP: In-Reply-To: <14524.812207436@time.cdrom.com> References: <14524.812207436@time.cdrom.com> Sender: owner-hackers@freebsd.org Precedence: bulk > Problem: 4MB machines appear to have overflowed again. > Work-around: None. > Fix: Must shrink size of GENERIC kernel again. I sent you a patch that will remove the SYSV* options from the kernel. They are never used *during* the install, so you should be able to apply my patch even if you don't like the other things I'm attempting to do w/regards to the dual consoles. Nate From owner-freebsd-hackers Wed Sep 27 08:00:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA03035 for hackers-outgoing; Wed, 27 Sep 1995 08:00:05 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA03030 for ; Wed, 27 Sep 1995 08:00:02 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA04706; Wed, 27 Sep 1995 09:58:55 -0500 From: Joe Greco Message-Id: <199509271458.JAA04706@brasil.moneng.mei.com> Subject: Re: Solaris x86 To: uttt@fang.cs.sunyit.edu (Tom T. Tran) Date: Wed, 27 Sep 1995 09:58:54 -0500 (CDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509271401.KAA13023@fang.cs.sunyit.edu> from "Tom T. Tran" at Sep 27, 95 10:01:06 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org Precedence: bulk > With all the talk of SCO compatability and Linux compatability I was > wondering if perhaps Solaris x86 might be on the horizon. I'm curious as to > whether or not having the system call wrappers for Linux and SCO bring us > any closer to having Solaris x86 binary compatability. FreeBSD does not support a significant number of the "value added" features of Solaris (I don't care to dicker over details but I will just hold up Sun's threads implementation as a great example) - and, to date, the few Solaris applications that I would want to run on FreeBSD tend to require these things. We could, I suppose, shoot to try to support a subset of the functionality.. Fortunately, Sun has done us all a great service by playing the game entirely differently from everyone else :-) Eccccch. The thought of trying to support Solaris binaries gives me the willies. :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Software Engineer, UNIX/Network Hacker, Etc. 414/362-3617 Marquette Electronics, Inc. - R&D - Milwaukee, WI jgreco@mei.com From owner-freebsd-hackers Wed Sep 27 08:00:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA03060 for hackers-outgoing; Wed, 27 Sep 1995 08:00:29 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA03055 ; Wed, 27 Sep 1995 08:00:24 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA17150; Wed, 27 Sep 1995 09:02:39 -0600 Date: Wed, 27 Sep 1995 09:02:39 -0600 From: Nate Williams Message-Id: <199509271502.JAA17150@rocky.sri.MT.net> To: "Jordan K. Hubbard" Cc: hackers@freefall.freebsd.org Subject: Re: Whither XFree86 3.1.2? In-Reply-To: <199509271343.GAA00831@freefall.freebsd.org> References: <199509271343.GAA00831@freefall.freebsd.org> Sender: owner-hackers@FreeBSD.org Precedence: bulk > Was this never released for FreeBSD? I don't see anything in > ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. The mirror script which pulls it from ftp.Xfree86.org didn't pull it down. There *are* binaries there for 3.1.2 which I'm using for 2.0.5. Nate From owner-freebsd-hackers Wed Sep 27 08:14:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA03563 for hackers-outgoing; Wed, 27 Sep 1995 08:14:17 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA03549 ; Wed, 27 Sep 1995 08:14:07 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA28013; Thu, 28 Sep 1995 01:09:52 +1000 Date: Thu, 28 Sep 1995 01:09:52 +1000 From: Bruce Evans Message-Id: <199509271509.BAA28013@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: bde@FreeBSD.org, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >Ok. How do the 'fdisk' slices (of which there can only be 4) relate to >the 30 slices available in FreeBSD. Excuse me for using DOS terminology The `fdisk' slices (primary DOS partitions) are the first 4 of the 30. >for a minute, but if I understand correctly, we can use 'extended' >partitions inside of 'primary' partitions. However, 30/4 isn't a real >number, so where does the magic number 30 come from? Extended partitions aren't inside primary partitions. Each primary partition may be an extended partition. Each extended partition begins with a secondary boot record with a partition table in it. The 4 entries in the partition table may be `logical drives' or extended partitions. Each extended partition begins with a secondary boot record... I decided that 5 bits in the minor number were enough to reserve for the slice number. 2^5 = 32 and 2 slice numbers are special. >> `dd if=/dev/rxd#' reads the entire disk. /dev/rxd# is a completely >> different device from /dev/rxd#c. These devices are often confused >> because disklabel automatically translates from `xd#' to /dev/rxd#c'. >Ahh, so these are equivalent ># dd if=/dev/sd0c of=/dev/null ># dd if=/dev/sd0 of=/dev/null >(Read the entire slice) No, the devices are completely different, as was just explained. >> You can't create a FreeBSD partition which accesses a DOS slice. Just >> access the DOS slice directly. >Ok. How do I know which slice is the DOS slice? (This get's back to >the determination of the numbering scheme 1-30) Look at sysinstall or libdisk/tst01 output for slices labeled as `fat". The numbering corresponds to a particular linearization of the tree of extended partitions so the relative order may vary with the OS. Bruce From owner-freebsd-hackers Wed Sep 27 08:14:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA03575 for hackers-outgoing; Wed, 27 Sep 1995 08:14:20 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA03557 for ; Wed, 27 Sep 1995 08:14:14 -0700 Received: (from jkh@localhost) by time.cdrom.com (8.6.12/8.6.9) id IAA14954 for hackers@freefall; Wed, 27 Sep 1995 08:14:09 -0700 Date: Wed, 27 Sep 1995 08:14:09 -0700 From: "Jordan K. Hubbard" Message-Id: <199509271514.IAA14954@time.cdrom.com> To: hackers@freefall.FreeBSD.org Subject: What the competition'' is up to - just FYI. Sender: owner-hackers@FreeBSD.org Precedence: bulk Path: reason.cdrom.com!nntp-ucb.barrnet.net!agate!howland.reston.ans.net!news.sprintlink.net!sunic!sunic.sunet.se!news.funet.fi!news.helsinki.fi!usenet From: Red Hat Software Newsgroups: comp.os.linux.announce Subject: COMMERCIAL: Red Hat Linux 2.0 available via FTP! 100% ELF! Followup-To: comp.os.linux.misc Date: Wed, 20 Sep 95 12:21:40 GMT Organization: ? Lines: 173 Approved: linux-announce@news.ornl.gov (Lars Wirzenius) Message-ID: NNTP-Posting-Host: kruuna.helsinki.fi Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Red Hat Software is pleased to announce the availability of Red Hat Commercial Linux 2.0 the latest and greatest from the zany folks at Red Hat Software. Come see us at UNIX Expo September 19th through 21st. We will be demoing all our latest stuff. We will also be showing various Red Hat tools running on an Alpha! 1. Introduction Red Hat Software 2. Features (800) 454-5502 3. RPM Packaging System (203) 454-5500 4. FTP Availability info@redhat.com 5. Support and Mailing List http://www.redhat.com 6. CD-ROMs *** Introduction Red Hat Commercial Linux 2.0 (Red Hat 2.0) is a complete rewrite of the acclaimed Red Hat Mother's Day distributions. It is a completely ELF based system -- If you have been putting off the upgrade to ELF, or have been having trouble upgrading a piece at a time, Red Hat 2.0 can save you the trouble. Four installation innovations make Red Hat 2.0 the easiest Linux to install ever. Our new graphical installation mode brings you straight up into X for most of the installation. Our boot disk creation script eases selection of the proper boot disk, and it saves your existing network configuration information and XF86Config so you don't have to configure TCP/IP or X! Our FTP install allows you to install simply by downloading 3 floppy disk images -- the rest is done automatically! And finally, the installation includes seamless support for PCMCIA devices -- install Red Hat 2.0 on your laptop as easily as on your desktop machine! This will be the last Linux system you ever install. The new rpm packaging system is sophisticated enough to allow upgrading to new Red Hat releases without a reinstalling your system - no partitioning, no backing up all your files, no headaches. Also included are all the popular Red Hat graphical control panel utilities that have simplified system administration for Red Hat users for over a year. *** Features . 100% ELF (with a.out compatibility libraries) . powerful RPM packaging system . easy to use GLINT graphical package administration tool . compliant with version 1.2 of the Linux File System Standard . graphical installation (text based install also supported) . FTP installation . integrated seamless PCMCIA support for laptop installs! . important new and upgraded packages: XFree86 3.1.2 Apache httpd server Perl 5 Tcl 7.4 / Tk 4.0 Python 1.2 w/ Tk 4.0 support GCC 2.7.0 Linux kernel 1.2.13 libc 5.0.9 *** RPM Packaging System Red Hat 2.0 is built on an entirely new packaging system called RPM. The rpm system combines features of the Red Hat RPP system and the BOGUS pms and pm systems, and adds many advanced features of its own, including smart config file handling across package upgrades, "shared" file handling, documentation searching support, and package installation via FTP. You can install, uninstall, query, verify, and upgrade individual rpm packages. A new graphical package management tool called GLINT allows you to quickly and easily manage and track your system. Glint is a vast improvement over our previous Linux Installation Manager (LIM) -- it is much faster, displays a hierarchy of packages represented by individual package icons, and has displays progress meters during installation. The source packages include pristine, untouched sources, as well as patches and a control file which defines the building and packaging process. This system was conceived and promoted by the BOGUS distribution development team: Rik Faith, Doug Hoffman, and Kevin Martin. We are releasing rpm under the terms of the GPL and we would like to encourage everyone to use it to package their software. You can get rpm separately from Red Hat 2.0 from any of the official Red Hat FTP mirror sites. *** FTP Availability Red Hat 2.0 is available from the following official Red Hat FTP mirrors. If you would like to mirror Red Hat at your site, please send mail to mirror-list@redhat.com for complete instructions. FTP Site Directory ======== ========= ftp.pht.com /pub/linux/redhat sunsite.unc.edu /pub/Linux/distributions/redhat ftp.cms.uncwil.edu /linux/redhat ftp.wilmington.net /linux/redhat ftp.caldera.com /pub/mirrors/redhat ftp.lasermoon.co.uk /pub/distributions/RedHat ftp.cc.gatech.edu /pub/linux/distributions/redhat uiarchive.cso.uiuc.edu /pub/systems/linux/distributions/redhat For installation instructions, read the RHCL-Installation-HOWTO, which can be found in the docs directory. In short, if you are doing an ftp install, just get the two ramdisk images, and one of the boot disk images and follow your instincts... *** Support and Mailing List On our web site and official Red Hat mirror sites you will find the Red Hat FAQ, which probably answers most of your questions. Check it out! If you purchase a Red Hat CD-ROM product you get 30 days of installation support via email. If you download Red Hat via FTP you will have to get support through the Red Hat mailing list. Everyone who uses Red Hat should be on the list! We use the list as a primary avenue for support, and all our announcements are sent to the list. To subscribe, send mail to listproc@redhat.com with the following in the body of the message: subscribe redhat-list FirstName LastName Want even more support? Get the Red Hat Support Program. It's a full support contract along with a year long Red Hat subscription! See our web site for complete details. *** CD-ROMs available from Red Hat Software For only $49.95, you can get our new 4 CD set! The four CD's include: Red Hat Commercial Linux 2.0 The Red Hat 2.0 Live Filesystem CD A sunsite.unc.edu linux archive A tsx-11.mit.edu linux archive What else do you get for that low-low price? Support! We provide 30 days of installation support, along with many other methods of support. What can you do with the Live Filesystem CD? Plenty. Tired of trying to explain linux to your friends and co-workers? Install it! Well, sort of anyway. By booting two floppies and using a supported CD-ROM drive, you can show off the power of linux and X windows right from the CD. You can also insert a third floppy to be mounted automatically to use for storing files. Quite a nice system. The Red Hat Users Guide is also available. It covers all aspects of installation and administration of your Red Hat system. The Red Hat Retail Division can be reached at: phone: (203) 454-5500 (800) 546-7274 fax: (203) 454-2582 email: info@acc-corp.com www: http://www.acc-corp.com -- Send comp.os.linux.announce submissions to: linux-announce@news.ornl.gov PLEASE remember a short description of the software. From owner-freebsd-hackers Wed Sep 27 08:21:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA03765 for hackers-outgoing; Wed, 27 Sep 1995 08:21:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA03756 ; Wed, 27 Sep 1995 08:21:35 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id BAA28325; Thu, 28 Sep 1995 01:16:23 +1000 Date: Thu, 28 Sep 1995 01:16:23 +1000 From: Bruce Evans Message-Id: <199509271516.BAA28325@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: bde@FreeBSD.org, hackers@FreeBSD.org, roberto@keltia.freenix.fr Sender: owner-hackers@FreeBSD.org Precedence: bulk >> There is no slice named 0. Slice _number_ 0 is the compatibility slice. >> Slice _number_ 1 is the whole disk. The slices that are _numbered_ 2-31 >> are _named_ 1-30. >Whoa. I'm lost now w/regards to the compatability slice. How exactly >is the compatability slice named, and how does it fit into the 'slice' >paradigm? The compatibility slice isn't named, unless you count xd#c (xd#c is the whole of the (logical) drive xd#). It doesn't really fit in with the slice paradigm. You use it when you only have one [FreeBSD] slice on the disk and don't want to think of others. Bruce From owner-freebsd-hackers Wed Sep 27 08:30:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA04045 for hackers-outgoing; Wed, 27 Sep 1995 08:30:05 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA04033 ; Wed, 27 Sep 1995 08:29:57 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA17253; Wed, 27 Sep 1995 09:31:51 -0600 Date: Wed, 27 Sep 1995 09:31:51 -0600 From: Nate Williams Message-Id: <199509271531.JAA17253@rocky.sri.MT.net> To: Bruce Evans Cc: nate@rocky.sri.MT.net, bde@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509271509.BAA28013@godzilla.zeta.org.au> References: <199509271509.BAA28013@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans writes: > >Ok. How do the 'fdisk' slices (of which there can only be 4) relate to > >the 30 slices available in FreeBSD. Excuse me for using DOS terminology > > The `fdisk' slices (primary DOS partitions) are the first 4 of the 30. > > >for a minute, but if I understand correctly, we can use 'extended' > >partitions inside of 'primary' partitions. However, 30/4 isn't a real > >number, so where does the magic number 30 come from? > > Extended partitions aren't inside primary partitions. Each primary partition > may be an extended partition. Ahh, OK. We are using different terminology. I was using the terminology 'extended' partition to represent a DOS drive letter inside of an extended partition. > Each extended partition begins with a > secondary boot record with a partition table in it. The 4 entries in the > partition table may be `logical drives' or extended partitions. Each > extended partition begins with a secondary boot record... So, we have: Entire disk: +------------------+------------------+------------------+------------------+ | | | | | | Slice 1 | Slice 2 | Slice 3 | Slice 4 | | | | | | And possibily (can be divided as many times as necessary) Single slice +-------+-------+---+ | | | | | S 5 | S 6 | 7 | | | | | And the numbering scheme for the slices > 4 is determined by how they fall in the first 4 slices, correct? > I decided that 5 bits in the minor number were enough to reserve for the > slice number. 2^5 = 32 and 2 slice numbers are special. > > >> `dd if=/dev/rxd#' reads the entire disk. /dev/rxd# is a completely > >> different device from /dev/rxd#c. These devices are often confused > >> because disklabel automatically translates from `xd#' to /dev/rxd#c'. > > >Ahh, so these are equivalent > > ># dd if=/dev/sd0c of=/dev/null > ># dd if=/dev/sd0 of=/dev/null > > >(Read the entire slice) > > No, the devices are completely different, as was just explained. As I read the explanation, they are the same (other than the raw vs. block interaction). disklabel automatically translated /dev/sd0 -> /dev/rsd0c # dd if=/dev/sd0 of=/dev/null But if I specifically hard-code in the device # dd if=/dev/sd0c of=/dev/null I should get the same results. > >> You can't create a FreeBSD partition which accesses a DOS slice. Just > >> access the DOS slice directly. > > >Ok. How do I know which slice is the DOS slice? (This get's back to > >the determination of the numbering scheme 1-30) > > Look at sysinstall or libdisk/tst01 output for slices labeled as `fat". > The numbering corresponds to a particular linearization of the tree of > extended partitions so the relative order may vary with the OS. Is there anyway to determine this outside of sysinstall? Nate From owner-freebsd-hackers Wed Sep 27 08:57:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA05133 for hackers-outgoing; Wed, 27 Sep 1995 08:57:28 -0700 Received: from dawnrazor.campus.luth.se (root@dawnrazor.campus.luth.se [130.240.193.73]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA05122 for ; Wed, 27 Sep 1995 08:57:22 -0700 Received: (from offe@localhost) by dawnrazor.campus.luth.se (8.6.11/8.6.9) id QAA02767; Wed, 27 Sep 1995 16:57:06 +0100 Date: Wed, 27 Sep 1995 16:57:05 +0100 (MET) From: Olof Johansson To: sos@FreeBSD.org cc: "Tom T. Tran" , hackers@freefall.freebsd.org Subject: Re: Solaris x86 In-Reply-To: <199509271417.HAA01643@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Wed, 27 Sep 1995 sos@FreeBSD.org wrote: > Hmm, I'm not sure exactly what slowlaris resembels most, but I guess > its SVR4 like. Do you know what kind of binary format they use ?? > I have the codebits for running simple SVR4 ELF binaries from a > NCR system, that might be a starting point. Solaris 2.x is SVR4 (with some Sun-stuff added). It uses ELF format for the binaries. -Olof From owner-freebsd-hackers Wed Sep 27 08:57:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA05197 for hackers-outgoing; Wed, 27 Sep 1995 08:57:51 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA05189 ; Wed, 27 Sep 1995 08:57:49 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id IAA16580; Wed, 27 Sep 1995 08:57:30 -0700 Message-Id: <199509271557.IAA16580@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Nate Williams cc: "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: Whither XFree86 3.1.2? In-reply-to: Your message of "Wed, 27 Sep 1995 09:02:39 MDT." <199509271502.JAA17150@rocky.sri.MT.net> Date: Wed, 27 Sep 1995 08:57:30 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Was this never released for FreeBSD? I don't see anything in >> ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. > >The mirror script which pulls it from ftp.Xfree86.org didn't pull it >down. There *are* binaries there for 3.1.2 which I'm using for 2.0.5. > > >Nate I will look into this later today. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Wed Sep 27 09:01:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA05433 for hackers-outgoing; Wed, 27 Sep 1995 09:01:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA05428 ; Wed, 27 Sep 1995 09:01:04 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id CAA29766; Thu, 28 Sep 1995 02:00:20 +1000 Date: Thu, 28 Sep 1995 02:00:20 +1000 From: Bruce Evans Message-Id: <199509271600.CAA29766@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: bde@FreeBSD.org, hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >So, we have: >Entire disk: >+------------------+------------------+------------------+------------------+ >| | | | | >| Slice 1 | Slice 2 | Slice 3 | Slice 4 | >| | | | | >And possibily (can be divided as many times as necessary) > > Single slice > +-------+-------+---+ > | | | | > | S 5 | S 6 | 7 | > | | | | Yes, except the gaps where the secondary boot records are. >And the numbering scheme for the slices > 4 is determined by how they >fall in the first 4 slices, correct? Recursively. >As I read the explanation, they are the same (other than the raw vs. block interaction). >disklabel automatically translated /dev/sd0 -> /dev/rsd0c Disklabel automatically translates sd0 -> /dev/rsd0c. /dev/sd0 is a completely different device. This should not cause any confusion because /dev/sd0 didn't exist before there were slices, and the disklabel man page never refers to it. It does cause confusion :-(. ># dd if=/dev/sd0 of=/dev/null >But if I specifically hard-code in the device ># dd if=/dev/sd0c of=/dev/null >I should get the same results. No, they are completely different devices. Look at them with ls -l. >> >Ok. How do I know which slice is the DOS slice? (This get's back to >> >the determination of the numbering scheme 1-30) >> >> Look at sysinstall or libdisk/tst01 output for slices labeled as `fat". >> The numbering corresponds to a particular linearization of the tree of >> extended partitions so the relative order may vary with the OS. >Is there anyway to determine this outside of sysinstall? Many. Try od -c /rsd0sY | head -1 | cut -c 24-44 dd if=/dev/rsd0sY | file - # sort of; could be improved Bruce From owner-freebsd-hackers Wed Sep 27 09:15:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA05740 for hackers-outgoing; Wed, 27 Sep 1995 09:15:35 -0700 Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA05732 for ; Wed, 27 Sep 1995 09:15:28 -0700 Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.11/8.6.9) id LAA08324; Wed, 27 Sep 1995 11:14:59 -0500 Date: Wed, 27 Sep 1995 11:14:58 -0500 (EST) From: John Fieber To: hackers@freebsd.org Subject: DOC changes: speak now! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk The make process in /usr/src/share/doc is ugly. If you want details, just look at it. In short, it makes two passes over the tree, each time with a different value of PRINTER. This creates problems for a tree with a mix of document sources. If there are no objections, I will change the default for PRINTER in bsd.doc.mk from ps to ascii since the latter is universally usable while the former is not. Then I will make the toplevel Makefile for the doc tree a standard subdir makefile. This means that only ascii documents will be generated and installed from roff source, with ascii and html being generated and installed for sgml source. Those whe have access to a postscript printer/viewer may manually type `make PRINTER=ps' to generate postscript. Ultimately, bsd.doc.mk should be changed to generate multiple formats in a single pass as bsd.sgml.mk does. The makefiles need to have some internal knowledge of what output formats are possible (or relevant) for the given input. This is necessary because we are dealing with roff, texinfo and sgml documents, and potentially all could exist in the same tree so setting a global output format is problematic. For example, html output is valid for sgml source (and potentially for texinfo), but the make would die on roff documents. If there are any objections, SPEAK NOW. I would like to put these changes in on Friday if there are no objections. -john == jfieber@indiana.edu =========================================== == http://fieber-john.campusview.indiana.edu/~jfieber ============ From owner-freebsd-hackers Wed Sep 27 09:15:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA05754 for hackers-outgoing; Wed, 27 Sep 1995 09:15:40 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA05739 for ; Wed, 27 Sep 1995 09:15:33 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id KAA17447; Wed, 27 Sep 1995 10:16:52 -0600 Date: Wed, 27 Sep 1995 10:16:52 -0600 From: Nate Williams Message-Id: <199509271616.KAA17447@rocky.sri.MT.net> To: Bruce Evans Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509271600.CAA29766@godzilla.zeta.org.au> References: <199509271600.CAA29766@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans writes: [ Graphical representation deleted ] >> Is this right? > > Yes, except the gaps where the secondary boot records are. Right, I'm thinking logically right now and not physically. > >And the numbering scheme for the slices > 4 is determined by how they > >fall in the first 4 slices, correct? > > Recursively. How do you mean? If I have 4 slices inside of the fdisk partition 1, the first slice in fdisk partition 2 would be (5, 6, 7, 8 are in 1) slice 9. Is that what you mean by recursively? > >disklabel automatically translated /dev/sd0 -> /dev/rsd0c > > Disklabel automatically translates sd0 -> /dev/rsd0c. /dev/sd0 is a > completely different device. I'm still lost. I *understand* that /dev/rsd0c and /dev/sd0 are different (one's a block device, the other is a character device), but how *are* they different in what parts of the disk they represent? I do know that rsd0 represents the entire disk as a character device. Does sd0 represent the entire disk as a block device? If so, why does disklabel translate sd0 -> rsd0c? > This should not cause any confusion because /dev/sd0 didn't exist > before there were slices, and the disklabel man page never refers to > it. It does cause confusion :-(. It's obviously causing me great confusion. > ># dd if=/dev/sd0 of=/dev/null > > >But if I specifically hard-code in the device > > ># dd if=/dev/sd0c of=/dev/null > > >I should get the same results. > > No, they are completely different devices. Look at them with ls -l. I know, but do the above commands produce the same results (modulo the block and character device differences). > >Is there anyway to determine [ A DOS slice ] outside of sysinstall? > > Many. Try > > od -c /rsd0sY | head -1 | cut -c 24-44 > dd if=/dev/rsd0sY | file - # sort of; could be improved *grin*. I could do this myself, but this is not recommended for a newbie. Is there an 'fdisk' type of way? Would it be possible to modify/re-write fdisk to recognize these things? If possible, how much work would be required to do it? Nate From owner-freebsd-hackers Wed Sep 27 09:23:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA05960 for hackers-outgoing; Wed, 27 Sep 1995 09:23:42 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA05954 for ; Wed, 27 Sep 1995 09:23:33 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id RAA13429; Wed, 27 Sep 1995 17:23:26 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509271623.RAA13429@gvr.win.tue.nl> Subject: Re: pwd_mkdb speed up patches: please review and comment To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Wed, 27 Sep 1995 17:23:26 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509242023.VAA06416@gvr.win.tue.nl> from "Guido van Rooij" at Sep 24, 95 09:23:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 15462 Sender: owner-hackers@freebsd.org Precedence: bulk Guido van Rooij wrote: > > Underneath are patches that try to touch all passwd related utils as > little as possible while speeding up regular password updates > dramatically. > > I'd like you all to look at them and give comments. > > What it does not solve is speeding up vipw. Chpass, chsh, chfn, passwd, > yppasswd will be quicker: on a 486, 66MHz, a 10.000 line password > file update will be limited by the disk transfer time. In my case > it took 1.5 minute. Now it is 15 seconds. > > This isn't a real solution for the basic problem. But it makes the > current problems with large password files a bit less painfull. > > What I did not do (yet) is change adduser. > After checking my patches I found what ppl were already afraid of: a descrepancy between how the original pwd_mkdb handled multiple users with the same uid. This has been fixed beneath. So getpwuid() now indeed returns the pw struct belonging to the first user in the passwd file with the given uid. What is absolutely *not* handled properly is multiple users with the same username. This is indeed possible with the old scheme. One might argue about how usefull this is, but is was valid. It will still work as expected, because the only tools making use of the improved pwd_mkdb handling are the ones that do a getpwnam() first and thus they automatically end up with the first user in the passwd file with the given username... (I hope this is still making sense). -Guido --- ./usr.bin/passwd/local_passwd.c.orig Sun Nov 6 22:08:19 1994 +++ ./usr.bin/passwd/local_passwd.c Sun Sep 10 20:03:48 1995 @@ -154,7 +154,7 @@ pw->pw_change = 0; pw_copy(pfd, tfd, pw); - if (!pw_mkdb()) + if (!pw_mkdb(uname)) pw_error((char *)NULL, 0, 1); return (0); } --- ./usr.bin/chpass/chpass.c.orig Tue May 30 08:29:36 1995 +++ ./usr.bin/chpass/chpass.c Fri Sep 22 19:42:57 1995 @@ -187,7 +187,7 @@ pw_copy(pfd, tfd, pw); - if (!pw_mkdb()) + if (!pw_mkdb(pw->pw_name)) pw_error((char *)NULL, 0, 1); exit(0); } --- ./usr.sbin/vipw/vipw.c.orig Tue May 30 05:52:55 1995 +++ ./usr.sbin/vipw/vipw.c Sun Sep 10 20:17:53 1995 @@ -96,7 +96,7 @@ warnx("no changes made"); pw_error((char *)NULL, 0, 0); } - if (pw_mkdb()) + if (pw_mkdb((char *)NULL)) break; pw_prompt(); } --- ./usr.sbin/vipw/pw_util.c.orig Tue May 30 05:52:54 1995 +++ ./usr.sbin/vipw/pw_util.c Fri Sep 22 19:39:07 1995 @@ -138,7 +138,8 @@ } int -pw_mkdb() +pw_mkdb(username) +char *username; { int pstat; pid_t pid; @@ -146,7 +147,12 @@ warnx("rebuilding the database..."); (void)fflush(stderr); if (!(pid = vfork())) { - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + if(!username) { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + } else { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, + "-u", username, NULL); + } pw_error(_PATH_PWD_MKDB, 1, 1); } pid = waitpid(pid, &pstat, 0); --- ./usr.sbin/vipw/pw_util.h.orig Thu May 26 07:23:31 1994 +++ ./usr.sbin/vipw/pw_util.h Sun Sep 10 20:04:57 1995 @@ -37,6 +37,6 @@ void pw_error __P((char *, int, int)); void pw_init __P((void)); int pw_lock __P((void)); -int pw_mkdb __P((void)); +int pw_mkdb __P((char *)); void pw_prompt __P((void)); int pw_tmp __P((void)); --- ./usr.sbin/pwd_mkdb/pwd_mkdb.c.orig Tue May 30 05:51:22 1995 +++ ./usr.sbin/pwd_mkdb/pwd_mkdb.c Tue Sep 26 22:45:25 1995 @@ -79,6 +79,7 @@ void cleanup __P((void)); void error __P((char *)); +void cp __P((char *, char *, mode_t mode)); void mv __P((char *, char *)); int scan __P((FILE *, struct passwd *)); void usage __P((void)); @@ -96,10 +97,14 @@ char *p, *t; char buf[MAX(MAXPATHLEN, LINE_MAX * 2)], tbuf[1024]; char buf2[MAXPATHLEN]; + char *username; + struct passwd *pw, *pw2; + u_int method, methoduid; strcpy(prefix, _PATH_PWD); makeold = 0; - while ((ch = getopt(argc, argv, "d:pv")) != EOF) + username = NULL; + while ((ch = getopt(argc, argv, "d:pu:v")) != EOF) switch(ch) { case 'd': strcpy(prefix, optarg); @@ -107,6 +112,9 @@ case 'p': /* create V7 "file.orig" */ makeold = 1; break; + case 'u': /* only update this record */ + username = optarg; + break; case 'v': /* backward compatible */ break; case '?': @@ -141,8 +149,24 @@ /* Open the temporary insecure password database. */ (void)snprintf(buf, sizeof(buf), "%s/%s.tmp", prefix, _MP_DB); - dp = dbopen(buf, - O_RDWR|O_CREAT|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + if(username) { + (void)snprintf(buf2, sizeof(buf2), "%s/%s", prefix, _MP_DB); + cp(buf2, buf, PERM_INSECURE); + dp = dbopen(buf, + O_RDWR|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + pw = getpwnam(username); + pw2 = getpwuid(pw->pw_uid); + if(!strcmp(pw2->pw_name, username)) + methoduid = 0; + else + methoduid = R_NOOVERWRITE; + method = 0; + } else { + dp = dbopen(buf, + O_RDWR|O_CREAT|O_EXCL, PERM_INSECURE, DB_HASH, &openinfo); + method = R_NOOVERWRITE; + methoduid = R_NOOVERWRITE; + } if (dp == NULL) error(buf); clean = FILE_INSECURE; @@ -182,47 +206,49 @@ if(pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') yp_enabled = 1; #define COMPACT(e) t = e; while (*p++ = *t++); - /* Create insecure data. */ - p = buf; - COMPACT(pwd.pw_name); - COMPACT("*"); - memmove(p, &pwd.pw_uid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_gid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_change, sizeof(time_t)); - p += sizeof(time_t); - COMPACT(pwd.pw_class); - COMPACT(pwd.pw_gecos); - COMPACT(pwd.pw_dir); - COMPACT(pwd.pw_shell); - memmove(p, &pwd.pw_expire, sizeof(time_t)); - p += sizeof(time_t); - memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); - p += sizeof pwd.pw_fields; - data.size = p - buf; - - /* Store insecure by name. */ - tbuf[0] = _PW_KEYBYNAME; - len = strlen(pwd.pw_name); - memmove(tbuf + 1, pwd.pw_name, len); - key.size = len + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + if(!username || (strcmp(username, pwd.pw_name) == 0)) { + /* Create insecure data. */ + p = buf; + COMPACT(pwd.pw_name); + COMPACT("*"); + memmove(p, &pwd.pw_uid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_gid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_change, sizeof(time_t)); + p += sizeof(time_t); + COMPACT(pwd.pw_class); + COMPACT(pwd.pw_gecos); + COMPACT(pwd.pw_dir); + COMPACT(pwd.pw_shell); + memmove(p, &pwd.pw_expire, sizeof(time_t)); + p += sizeof(time_t); + memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); + p += sizeof pwd.pw_fields; + data.size = p - buf; + + /* Store insecure by name. */ + tbuf[0] = _PW_KEYBYNAME; + len = strlen(pwd.pw_name); + memmove(tbuf + 1, pwd.pw_name, len); + key.size = len + 1; + if ((dp->put)(dp, &key, &data, method) == -1) + error("put"); - /* Store insecure by number. */ - tbuf[0] = _PW_KEYBYNUM; - memmove(tbuf + 1, &cnt, sizeof(cnt)); - key.size = sizeof(cnt) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + /* Store insecure by number. */ + tbuf[0] = _PW_KEYBYNUM; + memmove(tbuf + 1, &cnt, sizeof(cnt)); + key.size = sizeof(cnt) + 1; + if ((dp->put)(dp, &key, &data, method) == -1) + error("put"); - /* Store insecure by uid. */ - tbuf[0] = _PW_KEYBYUID; - memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); - key.size = sizeof(pwd.pw_uid) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + /* Store insecure by uid. */ + tbuf[0] = _PW_KEYBYUID; + memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); + key.size = sizeof(pwd.pw_uid) + 1; + if ((dp->put)(dp, &key, &data, methoduid) == -1) + error("put"); + } /* Store insecure special plus and special minus */ if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { @@ -235,7 +261,7 @@ else minuscnt++; key.size = sizeof(cnt) + 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } @@ -251,7 +277,7 @@ data.size = 1; tbuf[0] = _PW_KEYYPENABLED; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } /* If we have +@netgroup entries, store the plus counter */ @@ -260,7 +286,7 @@ data.size = sizeof(pluscnt); tbuf[0] = _PW_KEYPLUSCNT; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } /* If we have -@netgroup entries, store the minus counter */ @@ -269,7 +295,7 @@ data.size = sizeof(minuscnt); tbuf[0] = _PW_KEYMINUSCNT; key.size = 1; - if ((dp->put)(dp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(dp, &key, &data, method) == -1) error("put"); } @@ -281,8 +307,15 @@ /* Open the temporary encrypted password database. */ (void)snprintf(buf, sizeof(buf), "%s/%s.tmp", prefix, _SMP_DB); - edp = dbopen(buf, - O_RDWR|O_CREAT|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + if(username) { + (void)snprintf(buf2, sizeof(buf2), "%s/%s", prefix, _SMP_DB); + cp(buf2, buf, PERM_SECURE); + edp = dbopen(buf, + O_RDWR|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + } else { + edp = dbopen(buf, + O_RDWR|O_CREAT|O_EXCL, PERM_SECURE, DB_HASH, &openinfo); + } if (!edp) error(buf); clean = FILE_SECURE; @@ -291,61 +324,63 @@ minuscnt = pluscnt = 0; for (cnt = 1; scan(fp, &pwd); ++cnt) { - /* Create secure data. */ - p = buf; - COMPACT(pwd.pw_name); - COMPACT(pwd.pw_passwd); - memmove(p, &pwd.pw_uid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_gid, sizeof(int)); - p += sizeof(int); - memmove(p, &pwd.pw_change, sizeof(time_t)); - p += sizeof(time_t); - COMPACT(pwd.pw_class); - COMPACT(pwd.pw_gecos); - COMPACT(pwd.pw_dir); - COMPACT(pwd.pw_shell); - memmove(p, &pwd.pw_expire, sizeof(time_t)); - p += sizeof(time_t); - memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); - p += sizeof pwd.pw_fields; - data.size = p - buf; - - /* Store secure by name. */ - tbuf[0] = _PW_KEYBYNAME; - len = strlen(pwd.pw_name); - memmove(tbuf + 1, pwd.pw_name, len); - key.size = len + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); - - /* Store secure by number. */ - tbuf[0] = _PW_KEYBYNUM; - memmove(tbuf + 1, &cnt, sizeof(cnt)); - key.size = sizeof(cnt) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); - - /* Store secure by uid. */ - tbuf[0] = _PW_KEYBYUID; - memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); - key.size = sizeof(pwd.pw_uid) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) - error("put"); + if(!username || (strcmp(username, pwd.pw_name) == 0)) { + /* Create secure data. */ + p = buf; + COMPACT(pwd.pw_name); + COMPACT(pwd.pw_passwd); + memmove(p, &pwd.pw_uid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_gid, sizeof(int)); + p += sizeof(int); + memmove(p, &pwd.pw_change, sizeof(time_t)); + p += sizeof(time_t); + COMPACT(pwd.pw_class); + COMPACT(pwd.pw_gecos); + COMPACT(pwd.pw_dir); + COMPACT(pwd.pw_shell); + memmove(p, &pwd.pw_expire, sizeof(time_t)); + p += sizeof(time_t); + memmove(p, &pwd.pw_fields, sizeof pwd.pw_fields); + p += sizeof pwd.pw_fields; + data.size = p - buf; + + /* Store secure by name. */ + tbuf[0] = _PW_KEYBYNAME; + len = strlen(pwd.pw_name); + memmove(tbuf + 1, pwd.pw_name, len); + key.size = len + 1; + if ((dp->put)(edp, &key, &data, method) == -1) + error("put"); - /* Store secure special plus and special minus */ - if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { - tbuf[0] = (pwd.pw_name[0] == '+') ? - _PW_KEYPLUSBYNUM : _PW_KEYMINUSBYNUM; - memmove(tbuf + 1, (pwd.pw_name[0] == '+') ? - &pluscnt : &minuscnt, sizeof(cnt)); - if (pwd.pw_name[0] == '+') - pluscnt++; - else - minuscnt++; + /* Store secure by number. */ + tbuf[0] = _PW_KEYBYNUM; + memmove(tbuf + 1, &cnt, sizeof(cnt)); key.size = sizeof(cnt) + 1; - if ((dp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((dp->put)(edp, &key, &data, method) == -1) error("put"); + + /* Store secure by uid. */ + tbuf[0] = _PW_KEYBYUID; + memmove(tbuf + 1, &pwd.pw_uid, sizeof(pwd.pw_uid)); + key.size = sizeof(pwd.pw_uid) + 1; + if ((dp->put)(edp, &key, &data, methoduid) == -1) + error("put"); + + /* Store secure special plus and special minus */ + if (pwd.pw_name[0] == '+' || pwd.pw_name[0] == '-') { + tbuf[0] = (pwd.pw_name[0] == '+') ? + _PW_KEYPLUSBYNUM : _PW_KEYMINUSBYNUM; + memmove(tbuf + 1, (pwd.pw_name[0] == '+') ? + &pluscnt : &minuscnt, sizeof(cnt)); + if (pwd.pw_name[0] == '+') + pluscnt++; + else + minuscnt++; + key.size = sizeof(cnt) + 1; + if ((dp->put)(edp, &key, &data, method) == -1) + error("put"); + } } } /* If YP enabled, set flag. */ @@ -354,7 +389,7 @@ data.size = 1; tbuf[0] = _PW_KEYYPENABLED; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } /* If we have +@netgroup entries, store the plus counter */ @@ -363,7 +398,7 @@ data.size = sizeof(pluscnt); tbuf[0] = _PW_KEYPLUSCNT; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } /* If we have -@netgroup entries, store the minus counter */ @@ -372,7 +407,7 @@ data.size = sizeof(minuscnt); tbuf[0] = _PW_KEYMINUSCNT; key.size = 1; - if ((edp->put)(edp, &key, &data, R_NOOVERWRITE) == -1) + if ((edp->put)(edp, &key, &data, method) == -1) error("put"); } (void)(edp->close)(edp); @@ -437,6 +472,37 @@ } void +cp(from, to, mode) + char *from, *to; + mode_t mode; +{ + static char buf[MAXBSIZE]; + int from_fd, rcount, to_fd, wcount; + + if ((from_fd = open(from, O_RDONLY, 0)) < 0) + error(from); + if ((to_fd = open(to, O_WRONLY|O_CREAT|O_EXCL, mode)) < 0) + error(to); + while ((rcount = read(from_fd, buf, MAXBSIZE)) > 0) { + wcount = write(to_fd, buf, rcount); + if (rcount != wcount || wcount == -1) { + int sverrno = errno; + + (void)snprintf(buf, sizeof(buf), "%s to %s", from, to); + errno = sverrno; + error(buf); + } + } + if (rcount < 0) { + int sverrno = errno; + + (void)snprintf(buf, sizeof(buf), "%s to %s", from, to); + errno = sverrno; + error(buf); + } +} + +void mv(from, to) char *from, *to; { @@ -484,6 +550,6 @@ usage() { - (void)fprintf(stderr, "usage: pwd_mkdb [-p] [-d ] file\n"); + (void)fprintf(stderr, "usage: pwd_mkdb [-p] [-d ] [-u username] file\n"); exit(1); } --- ./gnu/usr.sbin/yppasswdd/pw_util.c.orig Tue May 30 07:05:28 1995 +++ ./gnu/usr.sbin/yppasswdd/pw_util.c Sun Sep 24 21:25:13 1995 @@ -132,7 +132,8 @@ } int -pw_mkdb() +pw_mkdb(username) +char *username; { int pstat; pid_t pid; @@ -140,7 +141,12 @@ warnx("rebuilding the database..."); (void)fflush(stderr); if (!(pid = vfork())) { - execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + if(!username) { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, NULL); + } else { + execl(_PATH_PWD_MKDB, "pwd_mkdb", "-p", tempname, + "-u", username, NULL); + } pw_error(_PATH_PWD_MKDB, 1, 1); } pid = waitpid(pid, &pstat, 0); From owner-freebsd-hackers Wed Sep 27 10:07:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA06754 for hackers-outgoing; Wed, 27 Sep 1995 10:07:12 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA06748 for ; Wed, 27 Sep 1995 10:07:10 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id HAA19187; Wed, 27 Sep 1995 07:49:03 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA02380; Wed, 27 Sep 1995 07:54:45 -0700 Date: Wed, 27 Sep 1995 07:54:45 -0700 Message-Id: <9509271454.AA02380@asimov.volant.org> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk |> > True. But consider what happens if you then install something that |> > has a startup dependancy on having an SMTP server running. If it |> > is using a fixed sequence number, it doesn't care what the SMTP |> > server is called; it just assumes that any replacement will use the |> |> The makefile concept done a little carefully takes care of this: |> |> We have the mail depenendcy be |> |> smtp-daemon: sendmail $SENDMAIL_ARGS |> |> package: smtp-daemon |> |> Now it doesn't care what the smtp-daemon target does, as long as |> it executes successfully. (This assume compatibility between the |> two different SMTP daemons for package purposes, but if you don't |> have that the point is moot anyway). I think I missed some of the details of the Makefile proposal. How does a package install it's make dependancies? Does it add lines to the makefile, or is the makefile dynamically generated by concatenating a bunch of small per-service make fragments? If it adds lines to the makefile, it still suffers from the auto-edit safty concerns that the straight control file scheme does. (Although it does eliminate the concerns about getting the order right.) If it includes a bunch of small fragments, that seems like an unnecessary extra complication. And I think that either the file-name-ordering or straight-control-file scheme would make it easier to quickly review which services are started in what order than any make-based scheme. (But I'm willing to be convinced otherwise.) -Pat From owner-freebsd-hackers Wed Sep 27 10:14:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA06949 for hackers-outgoing; Wed, 27 Sep 1995 10:14:37 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA06941 for ; Wed, 27 Sep 1995 10:14:32 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id SAA13529; Wed, 27 Sep 1995 18:11:49 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509271711.SAA13529@gvr.win.tue.nl> Subject: Re: Guido's pwd_mkdb improvements (fwd) To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Wed, 27 Sep 1995 18:11:48 +0100 (MET) Cc: ache@astral.msk.su, gryphon@healer.com, julian@ref.tfs.com, bugs@ns1.win.net, hackers@freebsd.org, taob@io.org In-Reply-To: <199509261836.TAA11289@gvr.win.tue.nl> from "Guido van Rooij" at Sep 26, 95 07:36:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 244 Sender: owner-hackers@freebsd.org Precedence: bulk > > > > Yes. It screws up things. Passwd automatic sorting IS NOT ALLOWED! > > > > Could you please verify that my patches either do or do not break this? > Don't bother: tey were indeed broken. I corrected this is my latest post. -Guido From owner-freebsd-hackers Wed Sep 27 10:21:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07136 for hackers-outgoing; Wed, 27 Sep 1995 10:21:37 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07129 for ; Wed, 27 Sep 1995 10:21:22 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA32286; Thu, 28 Sep 1995 03:17:20 +1000 Date: Thu, 28 Sep 1995 03:17:20 +1000 From: Bruce Evans Message-Id: <199509271717.DAA32286@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> >And the numbering scheme for the slices > 4 is determined by how they >> >fall in the first 4 slices, correct? >> >> Recursively. >How do you mean? If I have 4 slices inside of the fdisk partition 1, >the first slice in fdisk partition 2 would be (5, 6, 7, 8 are in 1) >slice 9. Is that what you mean by recursively? No, I just mean that the tree of slices is walked recursively to linearize it. It happens to be walked depth-first. This could give strange orders such as: 1 2 3 ext | ext 9 10 11 | 5 ext null null | 6 ext null null | 7 ext null null | 8 null null null but most fdisks generate a degenerate nearly linear tree such as: 1 2 3 ext | 5 ext null null | 6 ext null null | 7 ext null null | 8 null null null >> >disklabel automatically translated /dev/sd0 -> /dev/rsd0c >> >> Disklabel automatically translates sd0 -> /dev/rsd0c. /dev/sd0 is a >> completely different device. >I'm still lost. I *understand* that /dev/rsd0c and /dev/sd0 are >different (one's a block device, the other is a character device), but >how *are* they different in what parts of the disk they represent? /dev/rsd0c is the character device for the c partition on the first slice on sd0 with type 0xa5 (aka the compatibility slice). /dev/sd0 is the block device for the whole disk. >> ># dd if=/dev/sd0 of=/dev/null >> >> >But if I specifically hard-code in the device >> >> ># dd if=/dev/sd0c of=/dev/null >> >> >I should get the same results. >> >> No, they are completely different devices. Look at them with ls -l. >I know, but do the above commands produce the same results (modulo the >block and character device differences). The areas of the disk described by the two devices can be the same in degenerate cases. >> >Is there anyway to determine [ A DOS slice ] outside of sysinstall? >> >> Many. Try >> >> od -c /rsd0sY | head -1 | cut -c 24-44 >> dd if=/dev/rsd0sY | file - # sort of; could be improved >*grin*. I could do this myself, but this is not recommended for a >newbie. Is there an 'fdisk' type of way? Would it be possible to >modify/re-write fdisk to recognize these things? If possible, how much >work would be required to do it? There's the fdisk inside sysinstall and in libdisk/tst01. It recognizes extended partitions but can't create them. Bruce From owner-freebsd-hackers Wed Sep 27 10:28:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07451 for hackers-outgoing; Wed, 27 Sep 1995 10:28:25 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07446 for ; Wed, 27 Sep 1995 10:28:21 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA17738; Wed, 27 Sep 1995 11:30:16 -0600 Date: Wed, 27 Sep 1995 11:30:16 -0600 From: Nate Williams Message-Id: <199509271730.LAA17738@rocky.sri.MT.net> To: Bruce Evans Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509271717.DAA32286@godzilla.zeta.org.au> References: <199509271717.DAA32286@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk > >I'm still lost. I *understand* that /dev/rsd0c and /dev/sd0 are > >different (one's a block device, the other is a character device), but > >how *are* they different in what parts of the disk they represent? > > /dev/rsd0c is the character device for the c partition on the first slice > on sd0 with type 0xa5 (aka the compatibility slice). /dev/sd0 is the > block device for the whole disk. This makes sense. So why does 'disklabel automatically translated /dev/sd0 -> /dev/rsd0c' occur? [ Display slices and types of a disk ] > There's the fdisk inside sysinstall and in libdisk/tst01. It recognizes > extended partitions but can't create them. But no standalone utilities (yet). I think I'm beginning to understand this much better now. However, I still a bit confuseds re: the disklabel translation stuff and the 'compatability' slices. Thanks a bunch, Nate From owner-freebsd-hackers Wed Sep 27 10:58:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA08580 for hackers-outgoing; Wed, 27 Sep 1995 10:58:04 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA08574 for ; Wed, 27 Sep 1995 10:58:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA10533; Wed, 27 Sep 1995 10:52:06 -0700 From: Terry Lambert Message-Id: <199509271752.KAA10533@phaeton.artisoft.com> Subject: Re: vgalib for FreeBSD! To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Wed, 27 Sep 1995 10:52:06 -0700 (MST) Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199509270845.BAA00794@rah.star-gate.com> from "Amancio Hasty Jr." at Sep 27, 95 01:45:51 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 388 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Well, I just took a quick look at it and again I think is a mess. > > I would rather cut out the XFree86 low level graphic support and > make it into a library than to mess with the so called svgalib. Oh, yes! Roll DDX into the console driver! 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 Wed Sep 27 11:01:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA08674 for hackers-outgoing; Wed, 27 Sep 1995 11:01:27 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA08669 for ; Wed, 27 Sep 1995 11:01:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA10546; Wed, 27 Sep 1995 10:56:51 -0700 From: Terry Lambert Message-Id: <199509271756.KAA10546@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 10:56:51 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov In-Reply-To: <199509271353.JAA20564@healer.com> from "Coranth Gryphon" at Sep 27, 95 09:53:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 550 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > With prices for > hard-disks down around our ankles, the need for diskless FreeBSD machines > is functionally NIL. If someone really wants that setup, they have to > configure the remote server anyway, to server the root file-system for > that machine. What's so hard about configuring it for each machine? Lab full of nominally DOS machines which you wish to subvert to BSD using netboot and msdosfs. 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 Wed Sep 27 11:03:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA08763 for hackers-outgoing; Wed, 27 Sep 1995 11:03:34 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA08757 for ; Wed, 27 Sep 1995 11:03:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA10564; Wed, 27 Sep 1995 10:58:58 -0700 From: Terry Lambert Message-Id: <199509271758.KAA10564@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 10:58:58 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509271357.JAA20583@healer.com> from "Coranth Gryphon" at Sep 27, 95 09:57:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > From: Terry Lambert > > I want to replace the SMTP agent with my own. What is the current > > agent's name? How did you determine this? > > How is ANY automated procedure going to determine this? Service categories to allow auto-generation of a "pick one of the following as your mail transport agent". > And if you just "add a script to the directory" then both will be running. > So you have to delete the old daemon, and put the new one in. Yes, that's true. Or rather, you have to rm the symlink, but leave them both in init.d, and create a new symlink. > Either you have an automated means to do this, or you don't. You do. It *must* be automated. 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 Wed Sep 27 11:14:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09052 for hackers-outgoing; Wed, 27 Sep 1995 11:14:06 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09047 for ; Wed, 27 Sep 1995 11:14:01 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10620; Wed, 27 Sep 1995 11:09:06 -0700 From: Terry Lambert Message-Id: <199509271809.LAA10620@phaeton.artisoft.com> Subject: Re: ports startup scripts To: patl@asimov.volant.org Date: Wed, 27 Sep 1995 11:09:05 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <9509271454.AA02380@asimov.volant.org> from "patl@asimov.volant.org" at Sep 27, 95 07:54:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1963 Sender: owner-hackers@freebsd.org Precedence: bulk > I think I missed some of the details of the Makefile proposal. How > does a package install it's make dependancies? Does it add lines to > the makefile, or is the makefile dynamically generated by concatenating > a bunch of small per-service make fragments? I like the ability to manage a dependency graph, but I also think that the makefile approach is overly complicated... mostly because of the shared binaries that would have to be invoked before /usr is mounted given the current arrangement of shared library files (not that I agree with that arrangement, or that it shouldn't change to allow a purely shared binary installation). I think my biggest objection is that it requires install-time configuration administration as part of the install. I'd like to divorce that. Say we have a big OEM (like Rod 8-)) who puts BSD on every box. He will put defaults for the configuration he sells in the packages themselves, and forcing install time configuration will be largely redundant (and very frustrating for Rod). > If it adds lines to the makefile, it still suffers from the auto-edit > safty concerns that the straight control file scheme does. (Although > it does eliminate the concerns about getting the order right.) It doesn't. Concatenation is the method I'd see it using. > If it includes a bunch of small fragments, that seems like an unnecessary > extra complication. So does adding a select(2) system call when you have a perfectly good pipe(2) system call. Sometimes adding complexity to get features is a good thing. 8-). > And I think that either the file-name-ordering or straight-control-file > scheme would make it easier to quickly review which services are started > in what order than any make-based scheme. (But I'm willing to be convinced > otherwise.) I definitely agree here. 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 Wed Sep 27 11:15:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09136 for hackers-outgoing; Wed, 27 Sep 1995 11:15:58 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09131 for ; Wed, 27 Sep 1995 11:15:54 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id EAA01047; Thu, 28 Sep 1995 04:12:10 +1000 Date: Thu, 28 Sep 1995 04:12:10 +1000 From: Bruce Evans Message-Id: <199509271812.EAA01047@godzilla.zeta.org.au> To: bde@zeta.org.au, nate@rocky.sri.MT.net Subject: Re: Diskslice naming convention? Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >So why does 'disklabel automatically translated /dev/sd0 -> /dev/rsd0c' >occur? It doesn't. It translates sd0 to /dev/rsd0c. This is for convenience. It works very well if BSD owns the disk so that there is only one slice. Bruce From owner-freebsd-hackers Wed Sep 27 11:18:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09249 for hackers-outgoing; Wed, 27 Sep 1995 11:18:39 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09244 for ; Wed, 27 Sep 1995 11:18:36 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA17909; Wed, 27 Sep 1995 12:20:34 -0600 Date: Wed, 27 Sep 1995 12:20:34 -0600 From: Nate Williams Message-Id: <199509271820.MAA17909@rocky.sri.MT.net> To: Bruce Evans Cc: nate@rocky.sri.MT.net, hackers@FreeBSD.org Subject: Re: Diskslice naming convention? In-Reply-To: <199509271812.EAA01047@godzilla.zeta.org.au> References: <199509271812.EAA01047@godzilla.zeta.org.au> Sender: owner-hackers@FreeBSD.org Precedence: bulk Bruce Evans writes: > >So why does 'disklabel automatically translated /dev/sd0 -> /dev/rsd0c' > >occur? > > It doesn't. It translates sd0 to /dev/rsd0c. Huh? I'm still really confused. Where exactly does this occur, and why does it occur? Nate From owner-freebsd-hackers Wed Sep 27 11:45:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA09726 for hackers-outgoing; Wed, 27 Sep 1995 11:45:23 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA09721 for ; Wed, 27 Sep 1995 11:45:22 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id LAA12949; Wed, 27 Sep 1995 11:45:21 -0700 Date: Wed, 27 Sep 1995 11:45:21 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: /etc/services, supfilesrv, but no sup entry. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Can an entry for sup be added to the /etc/services by default? There's an entry for supfileserv, might as well add the other I would think. From owner-freebsd-hackers Wed Sep 27 12:03:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10301 for hackers-outgoing; Wed, 27 Sep 1995 12:03:39 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10296 for ; Wed, 27 Sep 1995 12:03:33 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id PAA21561; Wed, 27 Sep 1995 15:06:40 -0400 Date: Wed, 27 Sep 1995 15:06:40 -0400 From: Coranth Gryphon Message-Id: <199509271906.PAA21561@healer.com> To: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk >From patl@asimov.volant.org Wed Sep 27 13:12:14 1995 Date: Wed, 27 Sep 1995 07:54:45 -0700 To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com X-Sun-Charset: US-ASCII From: patl@asimov.volant.org > I think I missed some of the details of the Makefile proposal. How > does a package install it's make dependancies? Does it add lines to > the makefile, or is the makefile dynamically generated by concatenating > a bunch of small per-service make fragments? The makefile is generated by "makerc" (conceptually similar to "makewhatis"). > If it adds lines to the makefile, it still suffers from the auto-edit > safty concerns that the straight control file scheme does. (Although > it does eliminate the concerns about getting the order right.) No files are edited by packages. The packages/ports put control information into /etc/packages and /etc/init.d (for dependencies and scripts respectively). The sysadmin then runs "makerc" to regenerate the startup Makefile. If it includes a bunch of small fragments, that seems like an unnecessary extra complication. > And I think that either the file-name-ordering or straight-control-file > scheme would make it easier to quickly review which services are started > in what order than any make-based scheme. (But I'm willing to be convinced > otherwise.) Actually, the Makefile scheme lists dependencies on the single line that applies to each run-level. Thus (rough example) something like: level-3: mount-local start-nfs mount-nfs clean-locks clean-tmp ... mount-local: mount -t nonfs -a start-nfs: mountd nfsiod nfsd pcnfsd ... and so forth. ( The names have been changed to protect the unwritten :-) -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 12:08:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10406 for hackers-outgoing; Wed, 27 Sep 1995 12:08:36 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10401 for ; Wed, 27 Sep 1995 12:08:35 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id MAA17344; Wed, 27 Sep 1995 12:08:17 -0700 Message-Id: <199509271908.MAA17344@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-reply-to: Your message of "Wed, 27 Sep 1995 11:45:21 PDT." Date: Wed, 27 Sep 1995 12:08:17 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk > > >Can an entry for sup be added to the /etc/services by default? There's >an entry for supfileserv, might as well add the other I would think. supfileserv is the only entry required in /etc/services. Sup, the program doesn't use a particular port, but it does look for supservers at the port listed in /etc/servcies. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Wed Sep 27 12:09:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10461 for hackers-outgoing; Wed, 27 Sep 1995 12:09:36 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10455 for ; Wed, 27 Sep 1995 12:09:29 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id PAA21585; Wed, 27 Sep 1995 15:12:25 -0400 Date: Wed, 27 Sep 1995 15:12:25 -0400 From: Coranth Gryphon Message-Id: <199509271912.PAA21585@healer.com> To: gryphon@healer.com, patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk From: patl@asimov.volant.org Date: Wed, 27 Sep 1995 07:54:45 -0700 > I think I missed some of the details of the Makefile proposal. How > does a package install it's make dependancies? Does it add lines to Each package has a config information file, something to the effect of: [package] RUN=1,2,3 package: dependencies startup-commands The first line "[package]" (really the section heading to allow for a package to start up more than one thing) is for each target that gets added to the startup line in the Makefile. The "RUN" tag refers to what run-states (or run-levels) it is started for. The remainder of the section are the text to include into the makefile. The comment "well, how do you configure what it is dependent on" is answered "the same way you'd figure out what number to assign it". -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 12:10:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10522 for hackers-outgoing; Wed, 27 Sep 1995 12:10:23 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10508 for ; Wed, 27 Sep 1995 12:10:20 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA17993; Wed, 27 Sep 1995 13:12:29 -0600 Date: Wed, 27 Sep 1995 13:12:29 -0600 From: Nate Williams Message-Id: <199509271912.NAA17993@rocky.sri.MT.net> To: Jaye Mathisen Cc: hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-Reply-To: References: Sender: owner-hackers@freebsd.org Precedence: bulk > > Can an entry for sup be added to the /etc/services by default? There's > an entry for supfileserv, might as well add the other I would think. Umm, supfileserv *is* the entry for sup. What other entry should there be besides it? The only other entry is for supfiledbg, which is the non-standard port used for testing purposes. Nate From owner-freebsd-hackers Wed Sep 27 12:10:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10531 for hackers-outgoing; Wed, 27 Sep 1995 12:10:25 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10518 for ; Wed, 27 Sep 1995 12:10:22 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id MAA12985; Wed, 27 Sep 1995 12:10:21 -0700 Date: Wed, 27 Sep 1995 12:10:20 -0700 (PDT) From: Jaye Mathisen To: "Justin T. Gibbs" cc: hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-Reply-To: <199509271908.MAA17344@aslan.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk OK, then the docs on the web page need to be updated to reflect this, because they specifically say to add it... On Wed, 27 Sep 1995, Justin T. Gibbs wrote: > > > > > >Can an entry for sup be added to the /etc/services by default? There's > >an entry for supfileserv, might as well add the other I would think. > > supfileserv is the only entry required in /etc/services. Sup, the program > doesn't use a particular port, but it does look for supservers at the > port listed in /etc/servcies. > -- > Justin T. Gibbs > =========================================== > Software Developer - Walnut Creek CDROM > FreeBSD: Turning PCs into workstations > =========================================== > From owner-freebsd-hackers Wed Sep 27 12:11:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10629 for hackers-outgoing; Wed, 27 Sep 1995 12:11:30 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10624 for ; Wed, 27 Sep 1995 12:11:27 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id MAA12993; Wed, 27 Sep 1995 12:11:22 -0700 Date: Wed, 27 Sep 1995 12:11:22 -0700 (PDT) From: Jaye Mathisen To: Nate Williams cc: hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-Reply-To: <199509271912.NAA17993@rocky.sri.MT.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Hey, I'm just quoting the web page: http://www.freebsd.org/How/handbook/handbook148.html#247 14.6.1. Getting setup First off you will need to pick up the sup binaries. The easiest way of doing this is to grab the sup.tgz package from: ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz Install the sup package using pkg_add and add the following line to your /etc/services file: sup 871/tcp #sup On Wed, 27 Sep 1995, Nate Williams wrote: > > > > Can an entry for sup be added to the /etc/services by default? There's > > an entry for supfileserv, might as well add the other I would think. > > Umm, supfileserv *is* the entry for sup. What other entry should there > be besides it? The only other entry is for supfiledbg, which is the > non-standard port used for testing purposes. > > > Nate > From owner-freebsd-hackers Wed Sep 27 12:12:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10718 for hackers-outgoing; Wed, 27 Sep 1995 12:12:47 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10695 for ; Wed, 27 Sep 1995 12:12:32 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id PAA21613; Wed, 27 Sep 1995 15:15:27 -0400 Date: Wed, 27 Sep 1995 15:15:27 -0400 From: Coranth Gryphon Message-Id: <199509271915.PAA21613@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry > +> hard-disks down around our ankles, the need for diskless FreeBSD machines > +> is functionally NIL. If someone really wants that setup, they have to > +> configure the remote server anyway, to server the root file-system for > +> that machine. What's so hard about configuring it for each machine? > Lab full of nominally DOS machines which you wish to subvert to BSD > using netboot and msdosfs. 8-). Wait, you want to keep the existing DOS partition and boot it FreeBSD? If you just want to use the machines as FreeBSD machines then all you need to do is use whatever disk is in there (40MB is easily enough for local config and remote boot information). Otherwise you'd be booting off what: a floppy? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 12:12:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10752 for hackers-outgoing; Wed, 27 Sep 1995 12:12:53 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10735 for ; Wed, 27 Sep 1995 12:12:49 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA18018; Wed, 27 Sep 1995 13:14:58 -0600 Date: Wed, 27 Sep 1995 13:14:58 -0600 From: Nate Williams Message-Id: <199509271914.NAA18018@rocky.sri.MT.net> To: Jaye Mathisen Cc: Nate Williams , hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-Reply-To: References: <199509271912.NAA17993@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk Jaye Mathisen writes: > > Hey, I'm just quoting the web page: Ahh, I see. > Install the sup package using pkg_add and add the following line to your > /etc/services file: > > sup 871/tcp #sup This line already exists as supfilesrv, which the web page should be modified to show. Thanks for pointing it out, Nate From owner-freebsd-hackers Wed Sep 27 12:14:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA10911 for hackers-outgoing; Wed, 27 Sep 1995 12:14:42 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA10906 for ; Wed, 27 Sep 1995 12:14:35 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id PAA21629; Wed, 27 Sep 1995 15:16:59 -0400 Date: Wed, 27 Sep 1995 15:16:59 -0400 From: Coranth Gryphon Message-Id: <199509271916.PAA21629@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >From terry@lambert.org Wed Sep 27 14:07:15 1995 Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 10:58:58 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509271357.JAA20583@healer.com> from "Coranth Gryphon" at Sep 27, 95 09:57:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 824 From: Terry Lambert > Service categories to allow auto-generation of a "pick one of the > following as your mail transport agent". > +> And if you just "add a script to the directory" then both will be running. > +> So you have to delete the old daemon, and put the new one in. > Yes, that's true. Or rather, you have to rm the symlink, but leave > them both in init.d, and create a new symlink. > +> Either you have an automated means to do this, or you don't. > You do. It *must* be automated. If you can automatically recognize what to replace and where, then *FOR THAT CONCERN* it doesn't matter which method to use. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 12:19:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA11021 for hackers-outgoing; Wed, 27 Sep 1995 12:19:12 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA11015 for ; Wed, 27 Sep 1995 12:19:02 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id PAA21652; Wed, 27 Sep 1995 15:21:48 -0400 Date: Wed, 27 Sep 1995 15:21:48 -0400 From: Coranth Gryphon Message-Id: <199509271921.PAA21652@healer.com> To: patl@asimov.volant.org, terry@lambert.org Subject: Re: ports startup scripts Cc: gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk >From terry@lambert.org Wed Sep 27 14:17:35 1995 Subject: Re: ports startup scripts To: patl@asimov.volant.org Date: Wed, 27 Sep 1995 11:09:05 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: <9509271454.AA02380@asimov.volant.org> from "patl@asimov.volant.org" at Sep 27, 95 07:54:45 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1963 From: Terry Lambert > > I think I missed some of the details of the Makefile proposal. How > I like the ability to manage a dependency graph, but I also think that > the makefile approach is overly complicated... mostly because of the > shared binaries that would have to be invoked before /usr is mounted Make would have to be in /bin and be statically linked. If you consider that unreasonable, then a simplified make does. > I think my biggest objection is that it requires install-time configuration > administration as part of the install. I'd like to divorce that. Say Huh? You have to configure the install at install time ... > we have a big OEM (like Rod 8-)) who puts BSD on every box. He will put > defaults for the configuration he sells in the packages themselves, and He loads the packages, and runs "makerc". If all the packages are the same, then he does it once, and copies the configuration over. If they are not, then it's not the same install. > >If it edits the Makefile... > > It doesn't. Concatenation is the method I'd see it using. Something like that. The startup chain (what gets run) would be generated from scratch by "makerc". The target dependencies would be concatenated from the information supplied by the packages. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 12:22:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA11204 for hackers-outgoing; Wed, 27 Sep 1995 12:22:40 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA11199 for ; Wed, 27 Sep 1995 12:22:37 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id NAA18070; Wed, 27 Sep 1995 13:24:47 -0600 Date: Wed, 27 Sep 1995 13:24:47 -0600 From: Nate Williams Message-Id: <199509271924.NAA18070@rocky.sri.MT.net> To: Jaye Mathisen Cc: Nate Williams , hackers@freebsd.org Subject: Re: /etc/services, supfilesrv, but no sup entry. In-Reply-To: References: <199509271912.NAA17993@rocky.sri.MT.net> Sender: owner-hackers@freebsd.org Precedence: bulk > Hey, I'm just quoting the web page: .. > 14.6.1. Getting setup > > First off you will need to pick up the sup binaries. The easiest way of > doing this is to grab the sup.tgz package from: > > ftp://ftp.FreeBSD.ORG:/pub/FreeBSD/packages/sup.tgz > > Install the sup package using pkg_add and add the following line to your > /etc/services file: > > sup 871/tcp #sup Thanks Jaye, I just modified the sgml sources to modify it to be the same as the line in the default /etc/services in FreeBSD, and mentioned that it doesn't need to be added if it already exists. Nate From owner-freebsd-hackers Wed Sep 27 12:51:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA12178 for hackers-outgoing; Wed, 27 Sep 1995 12:51:21 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA12170 ; Wed, 27 Sep 1995 12:51:20 -0700 Message-Id: <199509271951.MAA12170@freefall.freebsd.org> Subject: Re: vgalib for FreeBSD! To: terry@lambert.org (Terry Lambert) Date: Wed, 27 Sep 1995 12:51:20 -0700 (PDT) Cc: hasty@rah.star-gate.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@freebsd.org In-Reply-To: <199509271752.KAA10533@phaeton.artisoft.com> from "Terry Lambert" at Sep 27, 95 10:52:06 am From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 669 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Terry Lambert who wrote: > > > Well, I just took a quick look at it and again I think is a mess. > > > > I would rather cut out the XFree86 low level graphic support and > > make it into a library than to mess with the so called svgalib. > > Oh, yes! Roll DDX into the console driver! That didn't take long to surface this time either :) NO I have no such plans, but anybody is free to write that particular piece of code as a LKM, any takers ?? :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Wed Sep 27 13:07:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA12811 for hackers-outgoing; Wed, 27 Sep 1995 13:07:16 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA12804 for ; Wed, 27 Sep 1995 13:07:10 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id NAA15891 for ; Wed, 27 Sep 1995 13:07:06 -0700 Prev-Resent: Wed, 27 Sep 1995 13:07:05 -0700 Prev-Resent: "hackers@freebsd.org " Received: from freefall.freebsd.org (freefall.cdrom.com [192.216.222.4]) by time.cdrom.com (8.6.12/8.6.9) with ESMTP id LAA15614 for ; Wed, 27 Sep 1995 11:57:15 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA10052 for ; Wed, 27 Sep 1995 11:57:14 -0700 Received: from shellx.best.com (shellx.best.com [205.149.163.50]) by blob.best.net (8.6.12/8.6.5) with ESMTP id LAA15860; Wed, 27 Sep 1995 11:57:09 -0700 Received: (rompel@localhost) by shellx.best.com (8.6.12/8.6.5) id SAA11554; Wed, 27 Sep 1995 18:57:09 GMT From: David Rompel Message-Id: <199509271857.SAA11554@shellx.best.com> Subject: Newest Dec 100Mbit enet chip announce To: rompel@best.com (David Rompel), jkh@freebsd.org Date: Wed, 27 Sep 1995 11:57:09 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6528 Resent-To: hackers@freebsd.org Resent-Date: Wed, 27 Sep 1995 13:07:06 -0700 Resent-Message-ID: <15889.812232426@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Newsgroups: biz.digital.announce Path: shellx.best.com!news1.best.com!sdd.hp.com!swrinde!howland.reston.ans.net!nntp.crl.com!decwrl!pa.dec.com!rjones From: pr-news@pa.dec.com (Digital Press & Analysts News) Message-ID: <9509251734.AA02840@raptor.pa.dec.com> Approved: rjones@pa.dec.com Subject: Press/Product Leadership For PCI Fast Ethernet Controllers Sender: rjones@usenet.pa.dec.com Date: Mon, 25 Sep 95 10:34:44 -0700 X-Received: by usenet.pa.dec.com; id AA23441; Mon, 25 Sep 1995 10:34:46 -0700 X-Received: by raptor.pa.dec.com; id AA02840; Mon, 25 Sep 95 10:34:45 -0700 X-To: Digital Press and Analysts News:; ; Lines: 124 |||||| Digital Press and Analysts News |||||||||||||||||||||||||||||||||| Digital Equipment Corporation Maynard, Massachusetts 01754-2571 Editorial contact: Lisa Lipson (508) 568-4352 DIGITAL ADDS TO PRODUCT LEADERSHIP FOR PCI FAST ETHERNET CONTROLLERS ...New 21140A PCI Fast Ethernet Chip Gains Features, Performance... MAYNARD, Mass., September 18, 1995 -- Digital Equipment Corporation today announced a new version of its PCI Fast Ethernet controller chip to link computers that use the Peripheral Component Interconnect (PCI) bus to high-speed local area networks. The 21140A PCI Fast Ethernet controller offers new boot ROM memory support, full PCI V2.1 compliance, a new power management feature, improved performance, and full pin compatibility with the current 21140 chip. "Digital Semiconductor was the first PCI Ethernet chip vendor in the open market and is a leader in 100 megabit-per-second (Mbps) solutions for PCI-based systems," said William N. Johnson, vice president, Sales and Marketing for Digital Semiconductor, a Digital Equipment Corporation business. "With the improvements in our second PCI Fast Ethernet product, we are helping network interface card (NIC) and system manufacturers to drive down the cost of high-speed networking for customers." Both the 21140A and the 21140 chips provide cost-effective upgrade paths to 100BaseT networks for 10Mbps PCI Ethernet installations. The devices support internetworking applications such as Ethernet switching, bridges, and routers that require connection to Fast Ethernet. New Features The 21140A chip's new features include: o Boot ROM support for loading of remote code that enables NIC and system suppliers to include vendor- and application- specific differentiation; o A register function for subvendor identification code, in conformity with the PCI V2.1 specification; o Power management with sleep and snooze modes. An improved descriptor interrupt scheme improves chip performance and throughput. The 21140A chip is a 10Mbps/100Mbps dual-port, full-duplex controller that supports both 3.3-volt and 5-volt signals. Large, on-chip FIFO memories avoid the need for external buffers, and the DMA architecture saves CPU cycles for other tasks. The 21140A chip offers the same unified set of software drivers as the 21140, supporting NetWare, LANmanager, Windows NT, Windows 95, MS-DOS, OS/2, SCO UNIX, PATHWORKS, Digital UNIX, OpenVMS, and other environments. The 100Mbps port contains a complete media independent interface (MII) to support voice-grade, data-grade, shielded twisted pair, and unshielded twisted pair cabling in any TX or T4 installation. Price, Availability The 21140A PCI Fast Ethernet controller is priced at $23.30 in quantities of 5,000. Samples will be available in October and volume production is planned for January 1996. Evaluation kits, containing a PCI Ethernet evaluation board, sample drivers, schematics, and documentation, will be available this December. Digital Semiconductor, a Digital Equipment Corporation business headquartered in Hudson, Massachusetts, designs, manufactures and markets industry-leading semiconductor products including Alpha microprocessors and PCI chips for networking, bridging, and graphics/multimedia, as well as low-power StrongARM microprocessors under license from Advanced RISC Machines Ltd. Digital Semiconductor operates design centers in Hudson; Palo Alto, California; Austin, Texas; and Jerusalem, Israel. A new, $450-million fabrication facility in Hudson will begin revenue production in 1996. Mitsubishi Electric Company is a second source for Alpha microprocessors. Digital Equipment Corporation is the world's leader in open client/server solutions from personal computing to integrated worldwide information systems. Digital's scalable Alpha platforms, storage, networking, software and services, together with industry- focused solutions from business partners, help organizations compete and win in today's global marketplace. #### Note to Editors: Digital, the Digital logo, OpenVMS, and PATHWORKS are trademarks of Digital Equipment Corporation. NetWare is a registered trademark of Novell, Inc. Windows and MS-DOS are registered trademarks and LANmanager and Windows NT are trademarks of Microsoft Corporation. OS/2 is a registered trademark of International Business Machines Corporation. SCO is a registered trademark of The Santa Cruz Operation, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Ltd. StrongARM is a trademark of Advanced RISC Machines Ltd. CORP/96/004 ============================================================================ Electronic Editorial Contact: lipson@mr4dec.enet.dec.com ============================================================================ Digital Press and Analysts News is sent as a courtesy to members of the press, analyst and consulting community. For subscription information please contact: Russ Jones Digital Equipment Corporation Voice: 415-853-2145 FAX: 415-853-2265 Internet: pr-news@pa.dec.com All Digital press releases, fact sheets and backgrounders are archived on ftp.digital.com in the /pub/Digital/info/pr-news directory. They are also available at http://www.digital.com/ on the World Wide Web . ============================================================================ From owner-freebsd-hackers Wed Sep 27 13:48:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13856 for hackers-outgoing; Wed, 27 Sep 1995 13:48:44 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA13848 for ; Wed, 27 Sep 1995 13:48:35 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id QAA25203; Wed, 27 Sep 1995 16:47:30 -0400 Date: Wed, 27 Sep 1995 16:47:29 -0400 (EDT) From: Brian Tao To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: <21697.812106895@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Tue, 26 Sep 1995, Jordan K. Hubbard wrote: > > > Well, how does BSD/OS 2.0 stay compatible with its own 1.1 > > binaries? > > I've been wondering that myself.. :-) Oh, good... I thought I had asked a dumb (but obvious) question. :) > I need to boot my BSDI box and check, but it runs FreeBSD 99.9% of > the time right now so I don't get much hands-on time with BSD/OS... :) I've got the 2.0 sources here which I can poke through when I find some time between rebuilding the news server (with FreeBSD!), getting a dedicated RADIUS authentication server online, fixing a zillion bad name server entries and looking for a place to live. :-/ :) -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Wed Sep 27 13:54:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA13998 for hackers-outgoing; Wed, 27 Sep 1995 13:54:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA13993 for ; Wed, 27 Sep 1995 13:54:24 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10931; Wed, 27 Sep 1995 13:49:25 -0700 From: Terry Lambert Message-Id: <199509272049.NAA10931@phaeton.artisoft.com> Subject: Re: ports startup scripts To: terry@lambert.org Date: Wed, 27 Sep 1995 13:49:24 -0700 (MST) Cc: patl@asimov.volant.org, gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, peter@taronga.com In-Reply-To: from "terry@lambert.org" at Sep 27, 95 11:09:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 951 Sender: owner-hackers@freebsd.org Precedence: bulk > > I think my biggest objection is that it requires install-time configuration > > administration as part of the install. I'd like to divorce that. Say > > Huh? You have to configure the install at install time ... No. You have to configure the package at install time or subsequent makes will fail. There is no distinction between "installed" and "active". It'd be nmice to be able to load it but not configure it. One example would be your template install without diskless or dataless or read-only support that you think is the prevalent case. You install and then allow the user to post-configure it a component at a time without creating the need for all components to be configured. When I get my box, I incrementally configure stuff installed but not configured by someone else. 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 Wed Sep 27 13:56:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA14084 for hackers-outgoing; Wed, 27 Sep 1995 13:56:30 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA14075 for ; Wed, 27 Sep 1995 13:56:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA10954; Wed, 27 Sep 1995 13:51:35 -0700 From: Terry Lambert Message-Id: <199509272051.NAA10954@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 13:51:35 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov In-Reply-To: <199509271915.PAA21613@healer.com> from "Coranth Gryphon" at Sep 27, 95 03:15:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 699 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Lab full of nominally DOS machines which you wish to subvert to BSD > > using netboot and msdosfs. 8-). > > Wait, you want to keep the existing DOS partition and boot it FreeBSD? > > If you just want to use the machines as FreeBSD machines then all you > need to do is use whatever disk is in there (40MB is easily enough for > local config and remote boot information). > > Otherwise you'd be booting off what: a floppy? A remote server, via bootp, using the netboor.com file you can build in the /sys/i386 subdirectory (already in the source tree). 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 Wed Sep 27 14:04:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14384 for hackers-outgoing; Wed, 27 Sep 1995 14:04:47 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14352 for ; Wed, 27 Sep 1995 14:04:38 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA20826 for ; Wed, 27 Sep 1995 22:03:12 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA20999 for FreeBSD-hackers@freefall.freebsd.org; Wed, 27 Sep 1995 22:03:12 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA24489 for FreeBSD-hackers@freefall.freebsd.org; Wed, 27 Sep 1995 21:40:18 +0100 From: J Wunsch Message-Id: <199509272040.VAA24489@uriah.heep.sax.de> Subject: Re: can't delete chfn To: FreeBSD-hackers@freefall.freebsd.org Date: Wed, 27 Sep 1995 21:40:18 +0100 (MET) Reply-To: FreeBSD-hackers@freefall.freebsd.org In-Reply-To: from "-Vince-" at Sep 27, 95 03:05:35 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 568 Sender: owner-hackers@FreeBSD.org Precedence: bulk As -Vince- wrote: > > root@apollo [3:03am][/usr/bin] >> dir chfn > -r-sr-xr-x 1 root bin 20480 Jul 26 07:57 chfn > root@apollo [3:04am][/usr/bin] >> rm chfn > override r-sr-xr-x root/bin schg for chfn? y > rm: chfn: Operation not permitted Your famous "dir" fails to report you the immutable flag. Better alias "dir" to "ls -lo" for user root. No idea why the chflags (above in your script, not quoted here) failed. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Sep 27 14:04:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14416 for hackers-outgoing; Wed, 27 Sep 1995 14:04:58 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14348 for ; Wed, 27 Sep 1995 14:04:37 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA20834 for ; Wed, 27 Sep 1995 22:03:16 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA21001 for hackers@freebsd.org; Wed, 27 Sep 1995 22:03:15 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA24866 for hackers@freebsd.org; Wed, 27 Sep 1995 21:55:18 +0100 From: J Wunsch Message-Id: <199509272055.VAA24866@uriah.heep.sax.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: hackers@freebsd.org Date: Wed, 27 Sep 1995 21:55:18 +0100 (MET) Reply-To: hackers@freebsd.org In-Reply-To: from "Jonathan M. Bresler" at Sep 27, 95 08:41:55 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 424 Sender: owner-hackers@freebsd.org Precedence: bulk As Jonathan M. Bresler wrote: > > i have been doing make world's on stable most nights. the only > Error that i encounter is: > > ===> usr.sbin/rmt > ln -s /usr/sbin/rmt /etc/rmt > ln: /etc/rmt: File exists > *** Error code 1 (ignored) Hey, _this one_ is not in error. :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed Sep 27 14:11:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA14680 for hackers-outgoing; Wed, 27 Sep 1995 14:11:01 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA14672 for ; Wed, 27 Sep 1995 14:10:57 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id OAA13045; Wed, 27 Sep 1995 14:10:37 -0700 Date: Wed, 27 Sep 1995 14:10:36 -0700 (PDT) From: Jaye Mathisen To: Brian Tao cc: "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk I have both BSD/OS 2.0 and FreeBSD running here on a slew of machines, if anybody wants to take a gander through it, or tell me where to look in the source, I'd be happy to snoop around, or set it up so somebody else can look. On Wed, 27 Sep 1995, Brian Tao wrote: > On Tue, 26 Sep 1995, Jordan K. Hubbard wrote: > > > > > Well, how does BSD/OS 2.0 stay compatible with its own 1.1 > > > binaries? > > > > I've been wondering that myself.. :-) > > Oh, good... I thought I had asked a dumb (but obvious) question. :) > > > I need to boot my BSDI box and check, but it runs FreeBSD 99.9% of > > the time right now so I don't get much hands-on time with BSD/OS... :) > > I've got the 2.0 sources here which I can poke through when I find > some time between rebuilding the news server (with FreeBSD!), getting > a dedicated RADIUS authentication server online, fixing a zillion bad > name server entries and looking for a place to live. :-/ :) > -- > Brian Tao > System Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > > From owner-freebsd-hackers Wed Sep 27 14:41:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15384 for hackers-outgoing; Wed, 27 Sep 1995 14:41:50 -0700 Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15378 for ; Wed, 27 Sep 1995 14:41:47 -0700 Received: (from vince@localhost) by apollo.COSC.GOV (8.6.11/8.6.9) id OAA09031; Wed, 27 Sep 1995 14:40:50 -0700 Date: Wed, 27 Sep 1995 14:40:48 -0700 (PDT) From: -Vince- To: FreeBSD-hackers@Freefall.FreeBSD.ORG Subject: can't delete chfn Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk I am trying to do a make world with the latest current and somehow it won't overwrite chfn no matter what I do... root@apollo [3:03am][/usr/src/usr.bin/chpass] >> make cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/chpass.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/edit.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/field.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/pw_copy.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb/pw_scan.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/../../usr.sbin/vipw/pw_util.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/table.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/util.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -c /usr/src/usr.bin/chpass/pw_yp.c cc -O -I/usr/src/usr.bin/chpass/../../usr.sbin/pwd_mkdb -I/usr/src/usr.bin/chpass/../../usr.sbin/vipw -DYP -o chpass chpass.o edit.o field.o pw_copy.o pw_scan.o pw_util.o table.o util.o pw_yp.o -lrpcsvc -lcrypt root@apollo [3:03am][/usr/src/usr.bin/chpass] >> make install [ ! -e /usr/bin/chpass ] || chflags noschg /usr/bin/chpass install -c -s -o root -g bin -m 4555 chpass /usr/bin /usr/bin/chfn -> /usr/bin/chpass rm: /usr/bin/chfn: Operation not permitted *** Error code 1 Stop. root@apollo [3:03am][/usr/src/usr.bin/chpass] >> cd /usr/bin root@apollo [3:03am][/usr/bin] >> dir chfn -r-sr-xr-x 1 root bin 20480 Jul 26 07:57 chfn root@apollo [3:04am][/usr/bin] >> rm chfn override r-sr-xr-x root/bin schg for chfn? y rm: chfn: Operation not permitted root@apollo [3:04am][/usr/bin] >> Anyone have any ideas what I can do so that make world will not quit and update this file with a new one? Thanks for any help in advance! Cheers, -Vince- vince@apollo.COSC.GOV - GUS Mailing Lists Admin UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center Running FreeBSD - Real UN*X for Free! From owner-freebsd-hackers Wed Sep 27 14:50:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15750 for hackers-outgoing; Wed, 27 Sep 1995 14:50:37 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15741 for ; Wed, 27 Sep 1995 14:50:20 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA22142; Wed, 27 Sep 1995 17:53:28 -0400 Date: Wed, 27 Sep 1995 17:53:28 -0400 From: Coranth Gryphon Message-Id: <199509272153.RAA22142@healer.com> To: terry@lambert.org Subject: Re: ports startup scripts Cc: gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk From: Terry Lambert > > > think my biggest objection is that it requires install-time configuration > > > administration as part of the install. I'd like to divorce that. Say > > +> Huh? You have to configure the install at install time ... > No. You have to configure the package at install time or subsequent > makes will fail. There is no distinction between "installed" and > "active". It'd be nmice to be able to load it but not configure it. Actually, it is simple to make any package/port that requires configuration be turned off (ie. set to not startup) by default. The simple way I came up with to do that was to have the "makerc" search for "package.mk" in the /etc/packages directory, and if you do not want it to run, just rename it to "package.NO". > One example would be your template install without diskless or dataless > or read-only support that you think is the prevalent case. You install > and then allow the user to post-configure it a component at a time > without creating the need for all components to be configured. When you do the configuration, just rename the file from "package.NO" to "package.mk" and re-run "makerc". You can just as easily configure five packages, then run "makerc" once. And you can start them by hand using the init script (still stored in "init.d") to test the configuration before committing it to auto-startup. Are the any other problems that the Makefile method does not solve/address? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 14:54:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA15898 for hackers-outgoing; Wed, 27 Sep 1995 14:54:25 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA15890 for ; Wed, 27 Sep 1995 14:54:09 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id RAA22156; Wed, 27 Sep 1995 17:57:24 -0400 Date: Wed, 27 Sep 1995 17:57:24 -0400 From: Coranth Gryphon Message-Id: <199509272157.RAA22156@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org, kelly@fsl.noaa.gov Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > > > Lab full of nominally DOS machines which you wish to subvert to BSD > > > using netboot and msdosfs. 8-). > > +> Wait, you want to keep the existing DOS partition and boot it FreeBSD? > +> You'd be booting off what: a floppy? > A remote server, via bootp, using the netboot.com file you can build > in the /sys/i386 subdirectory (already in the source tree). OK. So it would boot DOS, then run "netboot.com" (dos app) which would boot FreeBSD off of the remote server over the network. Neat. Well, either the config can be kept local ("makefile" and "start.mk" both meet the dos naming conventions) since you are using msdosfs, or they can be kept remote, and selected based upon machine connection. I still don't see the problem. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 15:19:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA16482 for hackers-outgoing; Wed, 27 Sep 1995 15:19:04 -0700 Received: from forgery.CS.Berkeley.EDU (forgery.CS.Berkeley.EDU [128.32.33.75]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA16477 for ; Wed, 27 Sep 1995 15:19:02 -0700 Received: (from asami@localhost) by forgery.CS.Berkeley.EDU (8.6.11/8.6.9) id PAA10951; Wed, 27 Sep 1995 15:20:03 -0700 Date: Wed, 27 Sep 1995 15:20:03 -0700 Message-Id: <199509272220.PAA10951@forgery.CS.Berkeley.EDU> To: gryphon@healer.com CC: hackers@freebsd.org In-reply-to: <199509262239.SAA18408@healer.com> (message from Coranth Gryphon on Tue, 26 Sep 1995 18:39:52 -0400) Subject: Re: ports startup scripts From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-hackers@freebsd.org Precedence: bulk * From: Coranth Gryphon * I proposed an mechanism that edits (usually appends to) a master control * file that defines startup order. People were vehemently opposed to * any automated file editing. >From what's going on here, I don't think we are ever going to agree to change the overall startup scheme. ;) * The second task is to write the util that takes this data and generates the * config startup sequence. In this case, it becomes trivial to use either * the "rc?.d" sym-linked subdirs, or the "rc.N" startup scripts. Uhh, I don't think we want to go that far. I just want a way to start the ports/packages, I have no intention to change how "rc" works, as much as I love the SysV scheme of run-levels and (especially) symlinked directories -- if you don't know what I mean, go to /cdrom/ports/packages and do an "ls -RF". :) Can we keep this simple? Just a single default target, and a Makefile that essentially looks like: # port1.mk all:: port1 port1:: /etc/ports.d/port1.sh start # port2.mk all:: port2 port2:: port3 /etc/ports.d/port2.sh start # port3.mk all:: port3 port3:: /etc/ports.d/port3.sh start after all the ".include"s are expanded. Here I'm assuming "port2" depends on "port3". One question is: can we start all the ports from one place in rc (where we source rc.local now), or do some things have to be started at different places? (If so, we need multiple targets.) Satoshi From owner-freebsd-hackers Wed Sep 27 15:42:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA16982 for hackers-outgoing; Wed, 27 Sep 1995 15:42:02 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA16968 for ; Wed, 27 Sep 1995 15:41:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA11197; Wed, 27 Sep 1995 15:36:42 -0700 From: Terry Lambert Message-Id: <199509272236.PAA11197@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 15:36:42 -0700 (MST) Cc: terry@lambert.org, gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509272153.RAA22142@healer.com> from "Coranth Gryphon" at Sep 27, 95 05:53:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 577 Sender: owner-hackers@freebsd.org Precedence: bulk > Are the any other problems that the Makefile method does not solve/address? The case of the missing dependency. If I have package B installed and it depends on package A, but package A is not installed, then a make will fail at generation of the package A startup, when instead it should fail the generation of the package B startup (but still generate a valid rc file). This was my point about installed-but-not-configure packages. 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 Wed Sep 27 16:04:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA17731 for hackers-outgoing; Wed, 27 Sep 1995 16:04:46 -0700 Received: from apollo.COSC.GOV (root@apollo.COSC.GOV [198.94.103.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA17725 for ; Wed, 27 Sep 1995 16:04:44 -0700 Received: (from vince@localhost) by apollo.COSC.GOV (8.6.11/8.6.9) id QAA09602; Wed, 27 Sep 1995 16:03:01 -0700 Date: Wed, 27 Sep 1995 16:03:01 -0700 (PDT) From: -Vince- To: J Wunsch cc: FreeBSD-hackers@freefall.freebsd.org Subject: Re: can't delete chfn In-Reply-To: <199509272040.VAA24489@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Wed, 27 Sep 1995, J Wunsch wrote: > As -Vince- wrote: > > > > root@apollo [3:03am][/usr/bin] >> dir chfn > > -r-sr-xr-x 1 root bin 20480 Jul 26 07:57 chfn > > root@apollo [3:04am][/usr/bin] >> rm chfn > > override r-sr-xr-x root/bin schg for chfn? y > > rm: chfn: Operation not permitted > > Your famous "dir" fails to report you the immutable flag. Better > alias "dir" to "ls -lo" for user root. > > No idea why the chflags (above in your script, not quoted here) > failed. I just did alias dir ls -lo and here's the output: root@apollo [3:58pm][/usr/bin] >> dir chfn -r-sr-xr-x 1 root bin schg 20480 Jul 26 07:57 chfn root@apollo [3:58pm][/usr/bin] >> Any ideas what I can do to delete chfn so I can install the updated one? Thanks! Cheers, -Vince- vince@apollo.COSC.GOV - GUS Mailing Lists Admin UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) Chabot Observatory & Science Center Running FreeBSD - Real UN*X for Free! From owner-freebsd-hackers Wed Sep 27 16:13:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA17994 for hackers-outgoing; Wed, 27 Sep 1995 16:13:43 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA17977 for ; Wed, 27 Sep 1995 16:13:39 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id TAA11150; Wed, 27 Sep 1995 19:00:16 -0400 Date: Wed, 27 Sep 1995 19:00:15 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: can't delete chfn To: -Vince- cc: J Wunsch , FreeBSD-hackers@freefall.freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Wed, 27 Sep 1995, -Vince- wrote: > I just did alias dir ls -lo and here's the output: > > root@apollo [3:58pm][/usr/bin] >> dir chfn > -r-sr-xr-x 1 root bin schg 20480 Jul 26 07:57 chfn ^^^^ schg prevents you from replacing the file. the same should be true of your kernel. do a 'chflags noschg /usr/bin/chfn' from man chflags: Flags are a comma separated list of keywords. The following keywords are currently defined: arch set the archived flag (super-user only) dump set the dump flag sappnd set the system append-only flag (super-user only) schg set the system immutable flag (super-user only) uappnd set the user append-only flag (owner or super-user only) uchg set the user immutable flag (owner or super-user only) archived, sappend, schange, simmutable, uappend, uchange, uimmutable aliases for the above > root@apollo [3:58pm][/usr/bin] >> > > Any ideas what I can do to delete chfn so I can install the > updated one? Thanks! > > Cheers, > -Vince- vince@apollo.COSC.GOV - GUS Mailing Lists Admin > UC Berkeley AstroPhysics - Electrical Engineering (Honorary B.S.) > Chabot Observatory & Science Center > Running FreeBSD - Real UN*X for Free! > > > > Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Wed Sep 27 16:56:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA19169 for hackers-outgoing; Wed, 27 Sep 1995 16:56:53 -0700 Received: from rf900.physics.su.oz.au (rf900.physics.su.OZ.AU [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA19164 ; Wed, 27 Sep 1995 16:56:36 -0700 Received: (from dawes@localhost) by rf900.physics.su.oz.au (8.6.11/8.6.9) id JAA14990; Thu, 28 Sep 1995 09:55:57 +1000 From: David Dawes Message-Id: <199509272355.JAA14990@rf900.physics.su.oz.au> Subject: Re: Whither XFree86 3.1.2? To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Thu, 28 Sep 1995 09:55:57 +1000 (EST) Cc: nate@rocky.sri.MT.net, jkh@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199509271557.IAA16580@aslan.cdrom.com> from "Justin T. Gibbs" at Sep 27, 95 08:57:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 860 Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> Was this never released for FreeBSD? I don't see anything in >>> ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. Yeah, I recently noticed that what is on ftp.cdrom.com is 3.1.1 rather than 3.1.2. >>The mirror script which pulls it from ftp.Xfree86.org didn't pull it >>down. There *are* binaries there for 3.1.2 which I'm using for 2.0.5. >> >> >>Nate > >I will look into this later today. ftp.xfree86.org is out of action at the moment, so if you don't already have 3.1.2 elsewhere you'll need to try another site. Our other official site is x.physics.usyd.edu.au, but you will probably be better off trying one of the US mirrors. The following two should have a complete 3.1.2 distribution (source and binaries for all platforms): ftp://ftp.rge.com/pub/XFree86/XFree86/3.1.2 ftp://ftp.eecs.umich.edu/BSD/XFree86/3.1.2 David From owner-freebsd-hackers Wed Sep 27 17:09:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA19380 for hackers-outgoing; Wed, 27 Sep 1995 17:09:01 -0700 Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA19375 for ; Wed, 27 Sep 1995 17:08:58 -0700 Received: (from mbarkah@localhost) by hemi.com (8.6.11/8.6.9) id SAA03886; Wed, 27 Sep 1995 18:12:19 -0600 From: Ade Barkah Message-Id: <199509280012.SAA03886@hemi.com> Subject: Re: Whither XFree86 3.1.2? To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Wed, 27 Sep 1995 18:12:19 -0600 (MDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509272355.JAA14990@rf900.physics.su.oz.au> from "David Dawes" at Sep 28, 95 09:55:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 616 Sender: owner-hackers@FreeBSD.org Precedence: bulk > ftp.xfree86.org is out of action at the moment, so if you don't already > have 3.1.2 elsewhere you'll need to try another site. ... Out of mailing list scope, but, what's up with that ? We've noticed that xfree86.org has been out of action for a few weeks. We have a Diamond card on 2.0.5 we need patches for. =) For awhile we couldn't even resolve any computer in the xfree86.org domain. Thanks, -Ade -------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - www: -------------------------------------------------------------------- From owner-freebsd-hackers Wed Sep 27 17:17:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA19633 for hackers-outgoing; Wed, 27 Sep 1995 17:17:37 -0700 Received: from linux4nn.iaf.nl (root@linux4nn.iaf.nl [193.67.144.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA19614 for ; Wed, 27 Sep 1995 17:17:27 -0700 Received: from uni4nn.iaf.nl (root@uni4nn.iaf.nl [193.67.144.33]) by linux4nn.iaf.nl (8.6.9/8.6.9) with SMTP id BAA08525; Thu, 28 Sep 1995 01:26:15 +0100 Received: by uni4nn.iaf.nl with UUCP id AA05702 (5.67b/IDA-1.5); Thu, 28 Sep 1995 01:17:41 +0100 Received: by iafnl.iaf.nl with UUCP id AA22512 (5.65c/IDA-1.4.4); Wed, 27 Sep 1995 22:39:03 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.6.8/8.6.6) id WAA01282; Wed, 27 Sep 1995 22:01:18 +0100 From: Wilko Bulte Message-Id: <199509272101.WAA01282@yedi.iaf.nl> Subject: Re: ports startup scripts To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 27 Sep 1995 22:01:17 +0100 (MET) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org.iaf.nl In-Reply-To: <24295.812164359@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 06:12:39 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1282 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >_ > > > The product is QA'd with the validation suite. 2 hours were required for > > the validation suite, which is interesting, considering POSIX validation > > takes less time to run. > > Sorry, this statement simply leads me to believe that you've never > worked on anything of significant size or complexity. 2 hours is > about how long it took to brief the QA team on how to structure the > run at most large ISVs I've worked at! :-) If you got the results back > in 3 or 4 days you considered it a rush job. I used to do (amongst other things) X/Open validation work. Believe me that you are going for your friendly colleagues throats when the XPG suite falls over once more. Generally say 4 - 5 runs were needed to get everything thru the XPG. And that was only XPG/2. XPG > 2 is worse. The SVVS (SVID test) is a piece of &*^*( And don't talk about bugs in your infallible test suite.. Sigh... And who writes this flawless testsuite BTW? ;-) Wilko > Jordan _ __________________________________________________________________________ | / o / / _ Wilko Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Private FreeBSD site - Arnhem - The Netherlands -------------------------------------------------------------------------------- From owner-freebsd-hackers Wed Sep 27 17:21:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA19808 for hackers-outgoing; Wed, 27 Sep 1995 17:21:43 -0700 Received: from rf900.physics.su.oz.au (rf900.physics.su.OZ.AU [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA19802 for ; Wed, 27 Sep 1995 17:21:32 -0700 Received: (from dawes@localhost) by rf900.physics.su.oz.au (8.6.11/8.6.9) id KAA15088; Thu, 28 Sep 1995 10:20:56 +1000 From: David Dawes Message-Id: <199509280020.KAA15088@rf900.physics.su.oz.au> Subject: Re: Whither XFree86 3.1.2? To: mbarkah@hemi.com (Ade Barkah) Date: Thu, 28 Sep 1995 10:20:56 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199509280012.SAA03886@hemi.com> from "Ade Barkah" at Sep 27, 95 06:12:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 797 Sender: owner-hackers@freebsd.org Precedence: bulk >> ftp.xfree86.org is out of action at the moment, so if you don't already >> have 3.1.2 elsewhere you'll need to try another site. ... > >Out of mailing list scope, but, what's up with that ? We've noticed >that xfree86.org has been out of action for a few weeks. We have a >Diamond card on 2.0.5 we need patches for. =) For awhile we couldn't >even resolve any computer in the xfree86.org domain. Basically the machine died in a big way (the cooling fan failed, and everything cooked). We went without a replacement primary DNS long enough for the secondaries to expire the data :-(. There is now another machine masquerading as our primary DNS and mailhost, but it has taken much longer than I'd hoped to get a replacement machine going, and I still don't know when it will be done. David From owner-freebsd-hackers Wed Sep 27 17:35:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA20251 for hackers-outgoing; Wed, 27 Sep 1995 17:35:03 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA20239 for ; Wed, 27 Sep 1995 17:35:00 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA11400; Wed, 27 Sep 1995 17:29:17 -0700 From: Terry Lambert Message-Id: <199509280029.RAA11400@phaeton.artisoft.com> Subject: Re: ports startup scripts To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Wed, 27 Sep 1995 17:29:17 -0700 (MST) Cc: jkh@time.cdrom.com, terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org.iaf.nl In-Reply-To: <199509272101.WAA01282@yedi.iaf.nl> from "Wilko Bulte" at Sep 27, 95 10:01:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2614 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > The product is QA'd with the validation suite. 2 hours were required for > > > the validation suite, which is interesting, considering POSIX validation > > > takes less time to run. > > > > Sorry, this statement simply leads me to believe that you've never > > worked on anything of significant size or complexity. 2 hours is > > about how long it took to brief the QA team on how to structure the > > run at most large ISVs I've worked at! :-) If you got the results back > > in 3 or 4 days you considered it a rush job. > > I used to do (amongst other things) X/Open validation work. Believe me > that you are going for your friendly colleagues throats when the XPG > suite falls over once more. I've run both the X/Open PVS and NIST/PCTS. Actually ran them on 1.X BSD at one time. Unfortunately I was unable to send the 20 or so patches and didn't work for a certified testing laboratory. > Generally say 4 - 5 runs were needed to get everything thru the > XPG. And that was only XPG/2. XPG > 2 is worse. The SVVS (SVID test) > is a piece of &*^*( This is assuming a failure. This is also assuming that you care about testing anything other than a few interfaces. You use as few system interfaces as possible in portable software -- it's one of the things that makes it portable. The SVVS is useless. UnixWare and Solaris both passed SVVS (I ran them for reference platform designation for the NetWare for UNIX product), but at the time, both were technically not SVID compliant. The test just didn't look for all aspects of conformance. UnixWare and SCO are *still* not SVID compliant (read SVID III, gettimeofday(RT), setitimer(RT), and getitimer(RT), with special emphasis on the phrases "system time" and "system time update frequency"). > And don't talk about bugs in your infallible test suite.. Everyone knows TET and ETET are bug free. 8-) 8-). > And who writes this flawless testsuite BTW? A piece of software called "battlemap". Other software. Mostly *not* human beings. I never claimed it was flawless, only that a human running test cases is inherently slower and provides less code coverage. If you run a fast machine test, throwing a human at it won't result in a better product, only a waste of the humans time. The human will make the same mistakes running from a writen procedure that a test suite coded from the same written procedure would make -- and will probably add data entry and interpretation mistakes 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 Wed Sep 27 20:05:25 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA27569 for hackers-outgoing; Wed, 27 Sep 1995 20:05:25 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA27558 for ; Wed, 27 Sep 1995 20:05:18 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id XAA22964; Wed, 27 Sep 1995 23:07:59 -0400 Date: Wed, 27 Sep 1995 23:07:59 -0400 From: Coranth Gryphon Message-Id: <199509280307.XAA22964@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk >From terry@lambert.org Wed Sep 27 18:45:12 1995 From: Terry Lambert Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Wed, 27 Sep 1995 15:36:42 -0700 (MST) Cc: terry@lambert.org, gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509272153.RAA22142@healer.com> from "Coranth Gryphon" at Sep 27, 95 05:53:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 577 > > Are the any other problems that the Makefile method does not solve/address? > The case of the missing dependency. > If I have package B installed and it depends on package A, but package > A is not installed, then a make will fail at generation of the package > A startup, when instead it should fail the generation of the package B > startup (but still generate a valid rc file). Actually, it will still generate correctly, but will fail at boot time since A is not runable. Which is what I would consider the correct behavior. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Wed Sep 27 21:56:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA04135 for hackers-outgoing; Wed, 27 Sep 1995 21:56:16 -0700 Received: from Glock.COM (root@glock.com [198.82.228.165]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA04130 ; Wed, 27 Sep 1995 21:56:13 -0700 Received: (from mmead@localhost) by Glock.COM (8.6.12/8.6.12) id AAA03968; Thu, 28 Sep 1995 00:56:08 -0400 Date: Thu, 28 Sep 1995 00:56:08 -0400 From: "matthew c. mead" Message-Id: <199509280456.AAA03968@Glock.COM> To: questions@freebsd.org Cc: hackers@freebsd.org Subject: Low end PS laser, or inkjet/bubblejet Sender: owner-hackers@freebsd.org Precedence: bulk I've been needing a new printer for a while now, considering what I've got is from 1991 - a Star Micronics 1020 Rainbow 9 pin dot matrix thing. I'd like to retire that to line printer status only and purchase either a low end postscript level 2 capable laser printer, or a mid to high end ink/bubblejet printer. I'm leaning towards the ink/bubblejet printers right now because PS laser starts higher than I'd like to spend. I know that the HP DJ540, 550, 560, and 660 are all very well supported with apsfilter and ghostscript, but from the reviews I've been reading, the Canon BJC-4000 does a lot better job. And then apparently the Epson Color Stylus II is even better. What I would like to know is whether or not anyone's out there running either of these two printers, and if so, how well do they reproduce a postscript document as prepped by ghostscript? Also, how easy was the printer to setup with freebsd, and can you use its highest dpi mode? Thanks for any pointers, recommendations, and help in advance! -matt -- Matthew C. Mead mmead@Glock.COM | Network Administration and Software Development http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com From owner-freebsd-hackers Wed Sep 27 23:01:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04975 for hackers-outgoing; Wed, 27 Sep 1995 23:01:49 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04969 for ; Wed, 27 Sep 1995 23:01:47 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id BAA05493; Thu, 28 Sep 1995 01:00:40 -0500 From: Joe Greco Message-Id: <199509280600.BAA05493@brasil.moneng.mei.com> Subject: News Server VM & I/O issues (was: Re: Big win for BSD/OS compatibility) To: taob@io.org (Brian Tao) Date: Thu, 28 Sep 1995 01:00:39 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: from "Brian Tao" at Sep 27, 95 04:47:29 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > I've got the 2.0 sources here which I can poke through when I find > some time between rebuilding the news server (with FreeBSD!), getting > a dedicated RADIUS authentication server online, fixing a zillion bad > name server entries and looking for a place to live. :-/ :) FreeBSD works great as a news server (although INN inherently sucks more RAM than I think it really should, but for understandable reasons). Which leads me to an only-somewhat-related topic. Rod Grimes and I were having a small side discussion about news server problems as they relate to disk striping, mirroring, and other similar issues. News servers traditionally suffer somewhat from the design of UNIX file systems - just not optimized to deal with a few million small files ;-) and one of the traditional answers has been to stripe disks, or run multiple spool drives (like I do). While this helps, it still tends to create "filesystem hot spots" with no easy and fast solution. I was hoping to throw a striped disk of some sort at a particular problem I am experiencing. Obviously the _real_ solution is to throw more RAM at the problem, but that's not always possible. :-) With 48MB already in the box, there's no room for more, and I would have to buy 32 to go to 64 :-/ (and this is a non-profit type outfit). Of course this would be a pointless discussion if I could afford to purchase a gigabyte of RAM, but until that happens, it is impossible to cache everything "useful" in memory. Rod made an interesting suggestion: > Start chasing around in the UFS code and see if you can some how create > seperate priorities of importanace for meta data vs file block data in > the VM cache, in your application tossing out meta data is VERY expensive. > A few quick emails to John Dyson or David Greenman might point you to > some tuneable parameters in the system that would help you out. (David and John are invited to jump in any time now...) What, if anything, are other people doing to optimize towards news service? All I am really doing under 2.0.5R is to bump maxusers to 128. Are there other fun things to tweak? ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Wed Sep 27 23:12:08 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05194 for hackers-outgoing; Wed, 27 Sep 1995 23:12:08 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05189 for ; Wed, 27 Sep 1995 23:12:06 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id CAA12340; Thu, 28 Sep 1995 02:12:03 -0400 Date: Thu, 28 Sep 1995 02:12:03 -0400 (EDT) From: Brian Tao To: FreeBSD-hackers@freefall.freebsd.org Subject: Re: can't delete chfn In-Reply-To: <199509272040.VAA24489@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Wed, 27 Sep 1995, J Wunsch wrote: > > No idea why the chflags (above in your script, not quoted here) > failed. Perhaps his kern.securelevel was >=1, which I think absolutely forbids you from unsetting the schg and sappnd flags. -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Wed Sep 27 23:20:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05424 for hackers-outgoing; Wed, 27 Sep 1995 23:20:16 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05419 for ; Wed, 27 Sep 1995 23:20:14 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id CAA12583; Thu, 28 Sep 1995 02:20:00 -0400 Date: Thu, 28 Sep 1995 02:19:59 -0400 (EDT) From: Brian Tao To: Pete Carah cc: hackers@FreeBSD.ORG Subject: Re: Big win for BSD/OS compatibility In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Mon, 25 Sep 1995, Pete Carah wrote: > > The first answer is that there are a *lot* more linux sites than > freebsd ones. linux is a bit less standardized, though... But porting to Free/NetBSD is practically a done deal if you've already got working code for BSD/OS. It would be a lot more work getting it running under Linux. > As to web servers, I run 2 at 2 ISPs for a total of 6 or 7 domains now > (using the apache virtual-host trick with ifconfig alias). One of them > is signing up folks weekly so I wonder how many aliases ifconfig is good > for? Someone (Chris Mauritz at mordor.com?) said he had 500+ aliases running on a single machine... > I don't know how many more web sites are freebsd-powered. I need to get > the 'powered by freebsd' logo to tack on to some of these pages if it's > allowed :-) Feel free. I've got both the FreeBSD and Apache logo badges on my home page at http://www.io.org/~taob/. This site is significantly faster than my old one in Taiwan (except for Taiwanese users). ;-) -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Wed Sep 27 23:22:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05499 for hackers-outgoing; Wed, 27 Sep 1995 23:22:32 -0700 Received: from trepan.io.org (taob@trepan.io.org [198.133.36.8]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05494 for ; Wed, 27 Sep 1995 23:22:30 -0700 Received: (from taob@localhost) by trepan.io.org (8.6.9/8.6.9) id CAA12643; Thu, 28 Sep 1995 02:22:25 -0400 Date: Thu, 28 Sep 1995 02:22:24 -0400 (EDT) From: Brian Tao To: David Rompel cc: freebsd-hackers@freebsd.org Subject: Re: Newest Dec 100Mbit enet chip announce In-Reply-To: <199509271857.SAA11554@shellx.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Wed, 27 Sep 1995, David Rompel wrote: > > Price, Availability > > The 21140A PCI Fast Ethernet controller is priced at $23.30 in > quantities of 5,000. Is that price just for the controller chip(set) or for a full working PCI board? Considering there isn't a lot of markup on computer hardware, that's an amazing price... -- Brian Tao System Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Thu Sep 28 00:55:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA06828 for hackers-outgoing; Thu, 28 Sep 1995 00:55:11 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA06808 for ; Thu, 28 Sep 1995 00:54:05 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id IAA14443; Thu, 28 Sep 1995 08:51:58 +0100 Message-Id: <199509280751.IAA14443@gilberto.physik.rwth-aachen.de> Subject: Re: Low end PS laser, or inkjet/bubblejet To: mmead@Glock.COM (matthew c. mead) Date: Thu, 28 Sep 1995 08:51:58 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509280456.AAA03968@Glock.COM> from "matthew c. mead" at Sep 28, 95 00:56:08 am From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2021 Sender: owner-hackers@freebsd.org Precedence: bulk > > > I've been needing a new printer for a while now, considering what > I've got is from 1991 - a Star Micronics 1020 Rainbow 9 pin dot matrix > thing. I'd like to retire that to line printer status only and purchase > either a low end postscript level 2 capable laser printer, or a mid to high > end ink/bubblejet printer. I'm leaning towards the ink/bubblejet printers > right now because PS laser starts higher than I'd like to spend. I know > that the HP DJ540, 550, 560, and 660 are all very well supported with > apsfilter and ghostscript, but from the reviews I've been reading, the > Canon BJC-4000 does a lot better job. And then apparently the Epson Color > Stylus II is even better. What I would like to know is whether or not > anyone's out there running either of these two printers, and if so, how > well do they reproduce a postscript document as prepped by ghostscript? I'm running an Epson Stylus color (with a hacked gs2.6.1 under FreeBSD 2.0.5) and it works like a charm. I have two test printouts escher.ps and colorcirc.ps sticking at the wall and they look fine. A bit a problem is the color trueness (dithering method) and I don't see any way to manipulate this other than digging into the drivers dithering method. > Also, how easy was the printer to setup with freebsd, and can you use its > highest dpi mode? Thanks for any pointers, recommendations, and help in > advance! Once you are familar with lpr setup it's an easy task. eps|epson-postscript|EPSON Stylus COLOR PostScript:\ :lp=/dev/lpt1:\ :sd=/var/spool/eps:\ :sh:\ :of=/usr/local/bin/gseps:\ :lf=/var/log/lpd-errs:\ :mx#0: > /usr/local/bin/gseps: #!/bin/sh /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 -r360 -dNOPAUSE -sOutputFile=- - > -matt > > -- > Matthew C. Mead > > mmead@Glock.COM | Network Administration and Software Development > http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Sep 28 04:00:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA11001 for hackers-outgoing; Thu, 28 Sep 1995 04:00:19 -0700 Received: from Glock.COM (root@glock.com [198.82.228.165]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA10994 for ; Thu, 28 Sep 1995 04:00:08 -0700 Received: (from mmead@localhost) by Glock.COM (8.6.12/8.6.12) id GAA04831; Thu, 28 Sep 1995 06:57:35 -0400 Date: Thu, 28 Sep 1995 06:57:35 -0400 From: "matthew c. mead" Message-Id: <199509281057.GAA04831@Glock.COM> To: Christoph Kukulies Cc: hackers@freebsd.org Subject: Re: Low end PS laser, or inkjet/bubblejet In-Reply-To: Your message of Thu, September 28, 1995 08:51:58 +0100 References: <199509280456.AAA03968@Glock.COM> <199509280751.IAA14443@gilberto.physik.rwth-aachen.de> Sender: owner-hackers@freebsd.org Precedence: bulk On Thu, September 28, 1995 at 08:51:58 (+0100), Christoph Kukulies wrote: First, thanks for the info... > I'm running an Epson Stylus color (with a hacked gs2.6.1 under FreeBSD > 2.0.5) and it works like a charm. I have two test printouts > escher.ps and colorcirc.ps sticking at the wall and they look fine. What's the "hacked" refer to? Will gs262 do this out of the box or is there some driver you added? If there is, what is its public availability? > A bit a problem is the color trueness (dithering method) and I > don't see any way to manipulate this other than digging into > the drivers dithering method. Yeah, that makes sense. If you hear of any improved driver, please let me know - I'd like to integrate it if possible, as I think I'll now grab this printer... :-) > > Also, how easy was the printer to setup with freebsd, and can you use its > > highest dpi mode? Thanks for any pointers, recommendations, and help in > > advance! > Once you are familar with lpr setup it's an easy task. I kind of figured. I know BSD lpr/lpd stuff pretty well... > eps|epson-postscript|EPSON Stylus COLOR PostScript:\ > :lp=/dev/lpt1:\ > :sd=/var/spool/eps:\ > :sh:\ > :of=/usr/local/bin/gseps:\ > :lf=/var/log/lpd-errs:\ > :mx#0: > /usr/local/bin/gseps: > #!/bin/sh > /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 -r360 -dNOPAUSE -sOutputFile=- - I'd probably end up using apsfilter so that I could just do a plain old lpr and it would autodetect both ps and dvi input. -matt -- Matthew C. Mead mmead@Glock.COM | Network Administration and Software Development http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com From owner-freebsd-hackers Thu Sep 28 04:11:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA11378 for hackers-outgoing; Thu, 28 Sep 1995 04:11:19 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA11371 for ; Thu, 28 Sep 1995 04:10:30 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id MAA14754; Thu, 28 Sep 1995 12:07:20 +0100 Message-Id: <199509281107.MAA14754@gilberto.physik.rwth-aachen.de> Subject: Re: Low end PS laser, or inkjet/bubblejet To: mmead@Glock.COM (matthew c. mead) Date: Thu, 28 Sep 1995 12:07:19 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509281057.GAA04831@Glock.COM> from "matthew c. mead" at Sep 28, 95 06:57:35 am From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2156 Sender: owner-hackers@freebsd.org Precedence: bulk > > On Thu, September 28, 1995 at 08:51:58 (+0100), Christoph Kukulies wrote: > > First, thanks for the info... > > > I'm running an Epson Stylus color (with a hacked gs2.6.1 under FreeBSD > > 2.0.5) and it works like a charm. I have two test printouts > > escher.ps and colorcirc.ps sticking at the wall and they look fine. > > What's the "hacked" refer to? Will gs262 do this out of the box or > is there some driver you added? If there is, what is its public > availability? It were the drivers for the epson stylus which are *not* in the standard gs262 (that should have been 262, btw, the last 'free' gs distribution before gs3.x). I dropped them into the gs source directory, changed the makefile and rebuilt gs. That's what I meant by hacking. > > > A bit a problem is the color trueness (dithering method) and I > > don't see any way to manipulate this other than digging into > > the drivers dithering method. > > Yeah, that makes sense. If you hear of any improved driver, please > let me know - I'd like to integrate it if possible, as I think I'll now > grab this printer... :-) > > > > Also, how easy was the printer to setup with freebsd, and can you use its > > > highest dpi mode? Thanks for any pointers, recommendations, and help in > > > advance! > > > Once you are familar with lpr setup it's an easy task. > > I kind of figured. I know BSD lpr/lpd stuff pretty well... > > > eps|epson-postscript|EPSON Stylus COLOR PostScript:\ > > :lp=/dev/lpt1:\ > > :sd=/var/spool/eps:\ > > :sh:\ > > :of=/usr/local/bin/gseps:\ > > :lf=/var/log/lpd-errs:\ > > :mx#0: > > > /usr/local/bin/gseps: > > > #!/bin/sh > > /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 -r360 -dNOPAUSE -sOutputFile=- - > > I'd probably end up using apsfilter so that I could just do a plain > old lpr and it would autodetect both ps and dvi input. > > -matt > > -- > Matthew C. Mead > > mmead@Glock.COM | Network Administration and Software Development > http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Thu Sep 28 05:20:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA12129 for hackers-outgoing; Thu, 28 Sep 1995 05:20:56 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA12121 for ; Thu, 28 Sep 1995 05:20:53 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA15502 (5.67a/IDA-1.5 for hackers@freebsd.org); Thu, 28 Sep 1995 07:18:02 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA05910 for hackers@freebsd.org; Thu, 28 Sep 1995 07:13:41 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509281213.HAA05910@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Thu, 28 Sep 1995 07:13:40 -0500 (CDT) In-Reply-To: <9509271454.AA02380@asimov.volant.org> from "patl@asimov.volant.org" at Sep 27, 95 07:54:45 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 671 Sender: owner-hackers@freebsd.org Precedence: bulk > I think I missed some of the details of the Makefile proposal. How > does a package install it's make dependancies? Does it add lines to > the makefile, or is the makefile dynamically generated by concatenating > a bunch of small per-service make fragments? The latter. I'm very much in favor of *whatever* scheme is used assembling the startup/shutdown sequence and other control files from fragments. Either directly by having the startup shell script run the files (the rc.d model) or by having the package install process rebuild them. I just want to get away from editing one big file that has a load of unrelated packages *and* the administrator diddling it. From owner-freebsd-hackers Thu Sep 28 05:22:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA12175 for hackers-outgoing; Thu, 28 Sep 1995 05:22:29 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA12169 for ; Thu, 28 Sep 1995 05:22:26 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD4.4) id WAA29719 for hackers@freebsd.org; Thu, 28 Sep 1995 22:22:12 +1000 From: michael butler Message-Id: <199509281222.WAA29719@asstdc.scgt.oz.au> Subject: Re: Low end PS laser, or inkjet/bubblejet To: hackers@freebsd.org Date: Thu, 28 Sep 1995 22:22:11 +1000 (EST) X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 903 Sender: owner-hackers@freebsd.org Precedence: bulk matthew c. mead writes: > I kind of figured. I know BSD lpr/lpd stuff pretty well... > > eps|epson-postscript|EPSON Stylus COLOR PostScript:\ > > :lp=/dev/lpt1:\ > > :sd=/var/spool/eps:\ > > :sh:\ > > :of=/usr/local/bin/gseps:\ > > :lf=/var/log/lpd-errs:\ > > :mx#0: > > /usr/local/bin/gseps: > > #!/bin/sh > > /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 -r360 -dNOPAUSE -sOutputFile=- - > I'd probably end up using apsfilter so that I could just do a plain > old lpr and it would autodetect both ps and dvi input. Whilst not directly related .. I run a pair of HP4s (one M+ and one MV for A3 printing) with JetDirect cards and, therefore, an "rm" entry in /etc/printcap. What surprised me was that I don't seem to be able to get any filters to preprocess the stuff before shooting it at the printer. Is this what's supposed to happen ? How do I fix it ? :-) michael From owner-freebsd-hackers Thu Sep 28 05:50:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA12495 for hackers-outgoing; Thu, 28 Sep 1995 05:50:09 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA12490 for ; Thu, 28 Sep 1995 05:50:06 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA15730 (5.67a/IDA-1.5 for hackers@freebsd.org); Thu, 28 Sep 1995 07:47:21 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA06384 for hackers@freebsd.org; Thu, 28 Sep 1995 07:34:28 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509281234.HAA06384@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Thu, 28 Sep 1995 07:34:28 -0500 (CDT) In-Reply-To: <199509271809.LAA10620@phaeton.artisoft.com> from "Terry Lambert" at Sep 27, 95 11:09:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 342 Sender: owner-hackers@freebsd.org Precedence: bulk > I think my biggest objection is that it requires install-time configuration > administration as part of the install. Why do you say that? You can just install a prebuilt canned makefile or whatever. And startup is no special case... there are all sorts of files that could be usefully built the same way (ttys, gettydefs, inetd.conf, ...) From owner-freebsd-hackers Thu Sep 28 05:50:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA12518 for hackers-outgoing; Thu, 28 Sep 1995 05:50:14 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id FAA12503 for ; Thu, 28 Sep 1995 05:50:11 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA15732 (5.67a/IDA-1.5 for hackers@freebsd.org); Thu, 28 Sep 1995 07:47:28 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA06402 for hackers@freebsd.org; Thu, 28 Sep 1995 07:38:30 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509281238.HAA06402@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Thu, 28 Sep 1995 07:38:30 -0500 (CDT) In-Reply-To: <199509271906.PAA21561@healer.com> from "Coranth Gryphon" at Sep 27, 95 03:06:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 447 Sender: owner-hackers@freebsd.org Precedence: bulk > No files are edited by packages. The packages/ports put control information > into /etc/packages and /etc/init.d (for dependencies and scripts > respectively). What is /etc/packages in your model? If it's a file, well, we've just come back to the original problem of having automated editing of a file. And the other control files have still to be dealt with. Much better to come up with a single scheme that has as much coverage as possible. From owner-freebsd-hackers Thu Sep 28 06:05:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13034 for hackers-outgoing; Thu, 28 Sep 1995 06:05:31 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA13027 for ; Thu, 28 Sep 1995 06:05:24 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA10570; Thu, 28 Sep 95 13:04:24 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA09023; Thu, 28 Sep 1995 07:04:22 -0600 Date: Thu, 28 Sep 1995 07:04:22 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509281304.AA09023@emu.fsl.noaa.gov> To: imb@scgt.oz.au Cc: hackers@freebsd.org In-Reply-To: <199509281222.WAA29719@asstdc.scgt.oz.au> (message from michael butler on Thu, 28 Sep 1995 22:22:11 +1000 (EST)) Subject: Re: Low end PS laser, or inkjet/bubblejet Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "michael" == michael butler writes: michael> matthew c. mead writes: >> I kind of figured. I know BSD lpr/lpd stuff pretty well... >> > eps|epson-postscript|EPSON Stylus COLOR PostScript:\ > >> :lp=/dev/lpt1:\ > :sd=/var/spool/eps:\ > :sh:\ > >> :of=/usr/local/bin/gseps:\ > :lf=/var/log/lpd-errs:\ > :mx#0: >> > /usr/local/bin/gseps: >> > #!/bin/sh > /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 >> -r360 -dNOPAUSE -sOutputFile=- - >> I'd probably end up using apsfilter so that I could just do a >> plain old lpr and it would autodetect both ps and dvi input. michael> Whilst not directly related .. I run a pair of HP4s (one michael> M+ and one MV for A3 printing) with JetDirect cards and, michael> therefore, an "rm" entry in /etc/printcap. What surprised michael> me was that I don't seem to be able to get any filters to michael> preprocess the stuff before shooting it at the printer. Ah, yep. The LPD protocol says that filtering of jobs happens on the printer host. And if the printer host is itself the printer, it's expected to have enough smarts to know how to convert DVI, troff, ditroff, cifplot, Fortran Text, etc., to native format. michael> Is this what's supposed to happen ? How do I fix it ? :-) Oh, I'm sure it's not what you wanted! You can fix it if your JetDirect card also supports non-server (LPD) mode---if it just has some data stream mode, where it listens to a certain port number and prints any data that comes in, rather than emulate a spooling host. If it can do that, then set up on of your FreeBSD hosts to be the printer host. Then you can have the conversion filters for the formats you want to support. Have them send their results to the printer. Or, use PLP or LPRng, which support filtering of jobs on the submitting host instead of the printer host---then you can still use the server mode on the printer. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA I can remember the first time I had to go to sleep. Mom said, "Steven, time to go to sleep." I said, "But I don't know how." She said, "It's real easy. Just go down to the end of tired and hang a left." So I went down to the end of tired, and just out of curiosity I hung a right. My mother was there, and she said "I thought I told you to go to sleep." -- Steven Wright From owner-freebsd-hackers Thu Sep 28 06:20:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA13699 for hackers-outgoing; Thu, 28 Sep 1995 06:20:11 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id GAA13694 for ; Thu, 28 Sep 1995 06:20:06 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA15789 (5.67a/IDA-1.5 for hackers@freebsd.org); Thu, 28 Sep 1995 08:02:31 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA06625; Thu, 28 Sep 1995 07:54:22 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509281254.HAA06625@bonkers.taronga.com> Subject: Re: ports startup scripts Date: Thu, 28 Sep 1995 07:54:21 -0500 (CDT) To: hackers@freebsd.org In-Reply-To: <199509271912.PAA21585@healer.com> from "Coranth Gryphon" at Sep 27, 95 03:12:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1024 Sender: owner-hackers@freebsd.org Precedence: bulk > The comment "well, how do you configure what it is dependent on" > is answered "the same way you'd figure out what number to assign it". It's easier to figure that out with the coarse granularity of a numbering scheme than the fine granularity of a dependency scheme. Really. One possibility is to abstract the dependencies in the makefile, so that you have your package set up like so (I say, use command syntax to make parsing easier, and discourage the baroque. If you have multiple entries, create config-this and config-that files, or just put them in separate directories): /etc/packages/oracle config depends-on smtp-server nfs-client satisfies sql-server name oracle script orasrv -d /oracle Then in the makefile, you generate an entry: sql-server: oracle [anything else that has satisfies sql-server] oracle: smtp-server nfs-client orasrv -d /oracle This also allows the config tool to do a static dependency analysis and tell you "snmp-manager requires snmp-service, aborting". From owner-freebsd-hackers Thu Sep 28 06:44:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA14478 for hackers-outgoing; Thu, 28 Sep 1995 06:44:36 -0700 Received: from coop.uc.uah.edu (coop.uc.uah.edu [146.229.19.14]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA14473 for ; Thu, 28 Sep 1995 06:44:34 -0700 Received: from [146.229.19.14] by coop.uc.uah.edu with SMTP (MailShare 1.0b10); Thu, 28 Sep 1995 08:49:24 -0600 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Sep 1995 08:49:24 -0600 To: hackers@freebsd.org From: batemanm@coop.uc.uah.edu (UAH Cooperative Education) Subject: DOS binaries under FreeBSD Sender: owner-hackers@freebsd.org Precedence: bulk > 3.5. Can I run DOS binaries under FreeBSD? > Not yet! We'd like to add support for this someday, but are still lacking > anyone to actually do the work. Ongoing work with Linux's DOSEMU utility may > bring this much closer to being a reality sometime soon. Send mail to The > FreeBSD hackers list if you're interested in joining this effort! Can I get more information about what is involved? What kind of commitment is involved? etc. Thank You, Michael D. Bateman batemanm@coop.uc.uah.edu http://coop.uc.uah.edu/ From owner-freebsd-hackers Thu Sep 28 07:19:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15032 for hackers-outgoing; Thu, 28 Sep 1995 07:19:18 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15027 for ; Thu, 28 Sep 1995 07:19:10 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA24338; Thu, 28 Sep 1995 10:23:40 -0400 Date: Thu, 28 Sep 1995 10:23:40 -0400 From: Coranth Gryphon Message-Id: <199509281423.KAA24338@healer.com> To: hackers@freebsd.org, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk >From owner-freebsd-hackers@freefall.freebsd.org Thu Sep 28 09:18:40 1995 From: peter@taronga.com (Peter da Silva) Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Thu, 28 Sep 1995 07:38:30 -0500 (CDT) In-Reply-To: <199509271906.PAA21561@healer.com> from "Coranth Gryphon" at Sep 27, 95 03:06:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 447 Sender: owner-hackers@freebsd.org Precedence: bulk > +> No files are edited by packages. The packages/ports put control information > +> into /etc/packages and /etc/init.d (for dependencies and scripts > +> respectively). > What is /etc/packages in your model? If it's a file, well, we've just come > back to the original problem of having automated editing of a file. It's a directory (or directory tree) that holds configuration information on packages. Used in place of /var/db/pkg (based upon the idea to keep all system configuration information under /etc). Package install just puts the approprite files into the directory. I prefer one directory (with files "foo.DESC"), rather than the tree ("/etc/packages/foo/DESC"), but it doesn't really matter. > And the other control files have still to be dealt with. We can only avoid editing files so much. Password files, inetd.conf, services. These have to be editied, or we have to throw them out and replace them with another model. At some point, you either have to allow auto-editing of system files, or just leave some stuff to hand-configuration. Or make all entries into /etc/services and /etc/inetd.conf and comment out the lines that correspond to packages not yet installed. The package can be told exactly what line to uncomment. Anything else requires human intervention. It's still a LOT better than we have now. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Thu Sep 28 07:27:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15273 for hackers-outgoing; Thu, 28 Sep 1995 07:27:09 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15268 for ; Thu, 28 Sep 1995 07:27:01 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id KAA24354; Thu, 28 Sep 1995 10:31:31 -0400 Date: Thu, 28 Sep 1995 10:31:31 -0400 From: Coranth Gryphon Message-Id: <199509281431.KAA24354@healer.com> To: hackers@freebsd.org, peter@taronga.com Subject: Re: ports startup scripts Sender: owner-hackers@freebsd.org Precedence: bulk From: peter@taronga.com (Peter da Silva) > One possibility is to abstract the dependencies in the makefile, so that you > have your package set up like so (I say, use command syntax to make Definately abstract as much as possible. For example, almost all of the standard unix sub-systems (nfs-client, nfs-server, mount-remote, mount-local, mail-agent, name-service, routes, ...) can be abstracted. > config > depends-on smtp-server nfs-client > satisfies sql-server > name oracle > > This also allows the config tool to do a static dependency analysis and > tell you "snmp-manager requires snmp-service, aborting". This is an interesting concept. A little more work, but you verify at config time (rather than boot time) if it is a valid dependency chain. I don't know how much outside of standard services could really be abstracted though - except in the case if interdependent packages, which could come up with abstractions names within that group. Which is most of what you need to worry about anyway... I like it. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Thu Sep 28 07:43:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA15808 for hackers-outgoing; Thu, 28 Sep 1995 07:43:17 -0700 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA15798 for ; Thu, 28 Sep 1995 07:43:09 -0700 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA05723; Thu, 28 Sep 1995 09:42:04 -0500 From: Joe Greco Message-Id: <199509281442.JAA05723@brasil.moneng.mei.com> Subject: Re: News Server VM & I/O issues (was: Re: Big win for BSD/OS compatibility) To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 28 Sep 1995 09:42:04 -0500 (CDT) Cc: taob@io.org, hackers@freebsd.org In-Reply-To: <199509280600.BAA05493@brasil.moneng.mei.com> from "Joe Greco" at Sep 28, 95 01:00:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk > Which leads me to an only-somewhat-related topic. Rod Grimes and I were > having a small side discussion about news server problems as they relate to > disk striping, mirroring, and other similar issues. News servers > traditionally suffer somewhat from the design of UNIX file systems - just > not optimized to deal with a few million small files ;-) and one of the > traditional answers has been to stripe disks, or run multiple spool drives > (like I do). While this helps, it still tends to create "filesystem hot > spots" with no easy and fast solution. I was hoping to throw a striped disk > of some sort at a particular problem I am experiencing. > [....] > (David and John are invited to jump in any time now...) What, if anything, > are other people doing to optimize towards news service? All I am really > doing under 2.0.5R is to bump maxusers to 128. Are there other fun things > to tweak? If I hadn't been half asleep when I wrote this, I would have remembered the other issue I wanted to inject into this... Coming from the Sun world, there are several traditional answers to the types of problems I am having - including both On-Line Disk Suite (a general striping/mirroring/etc package) and PrestoServe (a cache system that effectively gives you the benefits of a journaling filesystem). Having covered OLDS, I forgot about PrestoServe. :-) Has anybody had any wild ideas about trying to throw together some sort of analogue to PrestoServe? I know somebody mentioned a Compaq SCSI(??) controller of some sort that had cache RAM and may or may not have done something somewhat similar, but as memory serves it was an EISA card. This is something we need to consider if we want FreeBSD to be useful in an NFS server environment, and I've often seen PrestoServes added to systems to help increase overall I/O throughput too. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 From owner-freebsd-hackers Thu Sep 28 07:51:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16048 for hackers-outgoing; Thu, 28 Sep 1995 07:51:43 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16038 for ; Thu, 28 Sep 1995 07:51:38 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA18329; Thu, 28 Sep 1995 07:51:27 -0700 To: Nate Williams cc: hackers@freebsd.org Subject: Re: Bulletins for 2.1.0-950922-SNAP: In-reply-to: Your message of "Wed, 27 Sep 1995 09:01:25 MDT." <199509271501.JAA17146@rocky.sri.MT.net> Date: Thu, 28 Sep 1995 07:51:27 -0700 Message-ID: <18327.812299887@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk I have been looking at this issue lately WRT producing an IDE CDROM version of boot.flp and will probably fold your changes in along with a few others - I wasn't simply ignoring the patch! Jordan > > Problem: 4MB machines appear to have overflowed again. > > Work-around: None. > > Fix: Must shrink size of GENERIC kernel again. > > I sent you a patch that will remove the SYSV* options from the kernel. > They are never used *during* the install, so you should be able to apply > my patch even if you don't like the other things I'm attempting to do > w/regards to the dual consoles. > > > > Nate From owner-freebsd-hackers Thu Sep 28 07:57:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16277 for hackers-outgoing; Thu, 28 Sep 1995 07:57:21 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA16261 for ; Thu, 28 Sep 1995 07:57:12 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA12018; Thu, 28 Sep 95 14:56:49 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA09070; Thu, 28 Sep 1995 08:56:46 -0600 Date: Thu, 28 Sep 1995 08:56:46 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509281456.AA09070@emu.fsl.noaa.gov> To: imb@scgt.oz.au Cc: freebsd-hackers@freebsd.org In-Reply-To: <199509281412.AAA04216@asstdc.scgt.oz.au> (message from michael butler on Fri, 29 Sep 1995 00:12:26 +1000 (EST)) Subject: Re: Low end PS laser, or inkjet/bubblejet Sender: owner-hackers@freebsd.org Precedence: bulk Michael: Okay, PLP, the Portable Line Printer Spooler, is available from these locations: ftp://ftp.iona.ie/pub/plp (main site, but slooow) ftp://ftp.informatik.uni-hamburg.de/pub/utils/plp ftp://ftp.beckman.uiuc.edu/pub/plp ftp://ftp.zod.wau.nl/pub/mirror/plp ftp://ftp.lps.ens.fr/pub/software/plp ftp.uni-paderborn.de:/pub/unix/printer/plp It was originally written by Patrick Powell, and later modified and ported by an Internet-wide group of hackers. It compiles on FreeBSD fairly painlessly (I did have to edit setproctitle.c and add a #include and #include , and remove a declaration of malloc, calloc, and sys_siglist). PLP became an effort independent of Patrick Powell, who teamed up with one of the major PLP contributors Jason Mason, who together recently released an alpha version of LPRng, or Line Print - the Next Generation. It's quite similar to PLP, actually, but I haven't delved deeper into its differences. You can get LPRng from ftp://dickory.sdsu.edu/pub/LPRng/LPRng-1.2.2.tgz It compiles on FreeBSD even more easily than PLP. And yes, I know, I should make ports out of these. Soon, I promise. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA I took a baby shower. -- Steven Wright From owner-freebsd-hackers Thu Sep 28 07:57:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16301 for hackers-outgoing; Thu, 28 Sep 1995 07:57:27 -0700 Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA16275 for ; Thu, 28 Sep 1995 07:57:21 -0700 Received: from localhost (localhost [127.0.0.1]) by spooky.rwwa.com (8.6.11/8.6.9) with SMTP id KAA03718 for ; Thu, 28 Sep 1995 10:59:35 -0400 Message-Id: <199509281459.KAA03718@spooky.rwwa.com> X-Authentication-Warning: spooky.rwwa.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.5.3 12/28/94 To: hackers@freebsd.org Subject: Re: ports startup scripts In-reply-to: Your message of "Wed, 27 Sep 1995 15:06:40 EDT." <199509271906.PAA21561@healer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Sep 1995 10:59:35 -0400 From: Robert Withrow Sender: owner-hackers@freebsd.org Precedence: bulk > The makefile is generated by "makerc" (conceptually similar to "makewhatis"). That is an unnecessary complication. I think the pkgs should simply place makefile parts into the specified directory or directories, and the init makefile should simply include them. The part makefiles would include themselves in the appropriate targets for the desired runlevel or runstate, and make would be called to make the target for the desired runlevel or runstate. There should be no need to ever modify the toplevel makefile. ----------------------------------------------------------------------------- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430 Net: witr@rwwa.COM R.W. Withrow Associates, 319 Lynnway Suite 201, Lynn MA 01901 USA From owner-freebsd-hackers Thu Sep 28 08:33:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA17881 for hackers-outgoing; Thu, 28 Sep 1995 08:33:09 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA17875 for ; Thu, 28 Sep 1995 08:33:06 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA00242 for ; Thu, 28 Sep 1995 11:34:31 -0400 Date: Thu, 28 Sep 1995 11:34:31 -0400 Message-Id: <199509281534.LAA00242@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: ifconfig delete Sender: owner-hackers@freebsd.org Precedence: bulk What does ifconfig delete actually do ? Does it clear a structure or remove a a table entry somewhere? Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Thu Sep 28 09:40:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA19696 for hackers-outgoing; Thu, 28 Sep 1995 09:40:05 -0700 Received: from Glock.COM (root@glock.com [198.82.228.165]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA19691 for ; Thu, 28 Sep 1995 09:40:03 -0700 Received: (from mmead@localhost) by Glock.COM (8.6.12/8.6.12) id MAA06045; Thu, 28 Sep 1995 12:38:39 -0400 Date: Thu, 28 Sep 1995 12:38:39 -0400 From: "matthew c. mead" Message-Id: <199509281638.MAA06045@Glock.COM> To: Christoph Kukulies Cc: hackers@freebsd.org Subject: Re: Low end PS laser, or inkjet/bubblejet In-Reply-To: Your message of Thu, September 28, 1995 12:07:19 +0100 References: <199509281057.GAA04831@Glock.COM> <199509281107.MAA14754@gilberto.physik.rwth-aachen.de> Sender: owner-hackers@freebsd.org Precedence: bulk On Thu, September 28, 1995 at 12:07:19 (+0100), Christoph Kukulies wrote: > > What's the "hacked" refer to? Will gs262 do this out of the box or > > is there some driver you added? If there is, what is its public > > availability? > It were the drivers for the epson stylus which are *not* > in the standard gs262 (that should have been 262, btw, the last > 'free' gs distribution before gs3.x). I dropped them into > the gs source directory, changed the makefile and rebuilt > gs. That's what I meant by hacking. Where did you get the sources for the epson stylus drivers? Would you be willing to mail them to me? > > > #!/bin/sh > > > /usr/local/bin/gs -q -dSAFER -sDEVICE=escp2cfs2 -r360 -dNOPAUSE -sOutputFile=- - I'm assuming -r360 makes it print in 360x360dpi mode. Do you know if the driver supports 720x720? Thanks for all your info! -matt -- Matthew C. Mead mmead@Glock.COM | Network Administration and Software Development http://www.Glock.COM/~mmead/ | Consulting: BizNet Technologies -> mmead@bnt.com From owner-freebsd-hackers Thu Sep 28 10:12:49 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA20796 for hackers-outgoing; Thu, 28 Sep 1995 10:12:49 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA20791 for ; Thu, 28 Sep 1995 10:12:46 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id KAA05604; Thu, 28 Sep 1995 10:12:31 -0700 Message-Id: <199509281712.KAA05604@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: kelly@fsl.noaa.gov (Sean Kelly) cc: imb@scgt.oz.au, freebsd-hackers@freebsd.org Subject: Re: Low end PS laser, or inkjet/bubblejet In-reply-to: Your message of "Thu, 28 Sep 1995 08:56:46 MDT." <9509281456.AA09070@emu.fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 1995 10:12:31 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Hmmm... How different is PLP from APS filter? Tnks Amancio >>> Sean Kelly said: > Michael: > > Okay, PLP, the Portable Line Printer Spooler, is available from these From owner-freebsd-hackers Thu Sep 28 10:25:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21067 for hackers-outgoing; Thu, 28 Sep 1995 10:25:36 -0700 Received: from fslg8.fsl.noaa.gov (fslg8.fsl.noaa.gov [137.75.131.171]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA21062 for ; Thu, 28 Sep 1995 10:25:33 -0700 Received: by fslg8.fsl.noaa.gov (5.57/Ultrix3.0-C) id AA13638; Thu, 28 Sep 95 17:25:19 GMT Received: by emu.fsl.noaa.gov (1.38.193.4/SMI-4.1 (1.38.193.4)) id AA16445; Thu, 28 Sep 1995 11:25:16 -0600 Date: Thu, 28 Sep 1995 11:25:16 -0600 From: kelly@fsl.noaa.gov (Sean Kelly) Message-Id: <9509281725.AA16445@emu.fsl.noaa.gov> To: hasty@rah.star-gate.com Cc: imb@scgt.oz.au, freebsd-hackers@freebsd.org In-Reply-To: <199509281712.KAA05604@rah.star-gate.com> (hasty@rah.star-gate.com) Subject: Re: Low end PS laser, or inkjet/bubblejet Sender: owner-hackers@freebsd.org Precedence: bulk >>>>> "Amancio" == Amancio Hasty writes: Amancio> Hmmm... How different is PLP from APS filter? apsfilter is an input filter (text filter) for a spooling system, but PLP is an entire spooling system. PLP replaces lpd, lpr, lpq, lprm, lpc, etc. with its own version of those programs. You can use apsfilter with BSD LPD, PLP, LPRng, and (I'd imagine) System-V LP, too. -- Sean Kelly NOAA Forecast Systems Laboratory, Boulder Colorado USA When I was a little kid we had a sand box. It was a quicksand box. I was an only child... Eventually. -- Steven Wright From owner-freebsd-hackers Thu Sep 28 10:36:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21650 for hackers-outgoing; Thu, 28 Sep 1995 10:36:57 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA21645 for ; Thu, 28 Sep 1995 10:36:54 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12828; Thu, 28 Sep 1995 10:31:57 -0700 From: Terry Lambert Message-Id: <199509281731.KAA12828@phaeton.artisoft.com> Subject: Re: ports startup scripts To: terry@lambert.org (Terry Lambert) Date: Thu, 28 Sep 1995 10:31:57 -0700 (MST) Cc: gryphon@healer.com, terry@lambert.org, hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: from "Terry Lambert" at Sep 27, 95 03:36:42 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 627 Sender: owner-hackers@freebsd.org Precedence: bulk > > If I have package B installed and it depends on package A, but package > > A is not installed, then a make will fail at generation of the package > > A startup, when instead it should fail the generation of the package B > > startup (but still generate a valid rc file). > > Actually, it will still generate correctly, but will fail at boot > time since A is not runable. > > Which is what I would consider the correct behavior. Failing to boot is NEVER correct behaviour. NEVER. 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 Sep 28 10:42:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21788 for hackers-outgoing; Thu, 28 Sep 1995 10:42:07 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA21783 for ; Thu, 28 Sep 1995 10:42:05 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id KAA20980; Thu, 28 Sep 1995 10:40:20 -0700 Message-Id: <199509281740.KAA20980@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Mark Murray cc: Andreas Klemm , hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Wed, 27 Sep 1995 10:04:43 +0200." <199509270804.KAA08007@grumble.grondar.za> Date: Thu, 28 Sep 1995 10:40:20 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >You are not alone. I have a 486DX4/100/PCI and an adaptec 2940, and I get >these the whole time, as well as the signal 11's. I just tried a reboot, >ant the files that were corrupted before are now OK???!! They are corrupted >in exactly that same sort of way you are reporting. > >My kernel is stable, the rest is a mix (a lot hand-installed). > >M The only known problem with the aic7xxx driver has to do with losing bytes (the transfer leaves a residual of 1-13 bytes). This only happens when the transfer is going faster then 10MB/s (like a wide cappella or atlas), so a narrow device shouldn't show this problem. Single bit errors are almost always ram or cache problems. The driver supports full parity checking on its data up to the point that it is transfered to host memory, so I don't think this is the driver's fault. >-- >Mark Murray >46 Harvey Rd, Claremont, Cape Town 7700, South Africa >+27 21 61-3768 GMT+0200 >Finger mark@grumble.grondar.za for PGP key -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Thu Sep 28 10:42:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA21822 for hackers-outgoing; Thu, 28 Sep 1995 10:42:54 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA21815 for ; Thu, 28 Sep 1995 10:42:52 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id KAA20996; Thu, 28 Sep 1995 10:42:05 -0700 Message-Id: <199509281742.KAA20996@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Mark Murray cc: davidg@Root.COM, hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Wed, 27 Sep 1995 11:07:08 +0200." <199509270907.LAA22148@grumble.grondar.za> Date: Thu, 28 Sep 1995 10:42:05 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >> >I have tried a different SCSI controller - briefly. It seemed to work. >> >> Make sure you enable bounce buffers before you stick that 1542C in. :-) > >Thanks (wry smile). I got bitten by that first time round. :-) ISA bus master instead of a PCI bus master. What you really need is something like an NCR or some other PCI bus master to see if you can reproduce this. >M >-- >Mark Murray >46 Harvey Rd, Claremont, Cape Town 7700, South Africa >+27 21 61-3768 GMT+0200 >Finger mark@grumble.grondar.za for PGP key -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Thu Sep 28 10:43:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA22038 for hackers-outgoing; Thu, 28 Sep 1995 10:43:58 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA22021 for ; Thu, 28 Sep 1995 10:43:55 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12846; Thu, 28 Sep 1995 10:38:08 -0700 From: Terry Lambert Message-Id: <199509281738.KAA12846@phaeton.artisoft.com> Subject: Re: News Server VM & I/O issues (was: Re: Big win for BSD/OS compatibility) To: jgreco@brasil.moneng.mei.com (Joe Greco) Date: Thu, 28 Sep 1995 10:38:08 -0700 (MST) Cc: taob@io.org, hackers@FreeBSD.ORG In-Reply-To: <199509280600.BAA05493@brasil.moneng.mei.com> from "Joe Greco" at Sep 28, 95 01:00:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1059 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Rod made an interesting suggestion: > > > Start chasing around in the UFS code and see if you can some how create > > seperate priorities of importanace for meta data vs file block data in > > the VM cache, in your application tossing out meta data is VERY expensive. > > A few quick emails to John Dyson or David Greenman might point you to > > some tuneable parameters in the system that would help you out. This is actually bogus; it violates the locality rules that cause a cache to function in the first place. One soloution would be to make writes be ordered but not synchronus. The synchronus metadata updates are a poor mechanism for guaranteeing the order is (1) metadata and (2) data. Unfortunately, this approach is currently patent-pending by USL, although I believe there is sufficient prior art that it isn't really patentable, that usually has little bearing on whether or not a patent is granted. 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 Sep 28 10:46:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA22287 for hackers-outgoing; Thu, 28 Sep 1995 10:46:40 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA22278 for ; Thu, 28 Sep 1995 10:46:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12874; Thu, 28 Sep 1995 10:42:36 -0700 From: Terry Lambert Message-Id: <199509281742.KAA12874@phaeton.artisoft.com> Subject: Re: ports startup scripts To: peter@taronga.com (Peter da Silva) Date: Thu, 28 Sep 1995 10:42:36 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199509281234.HAA06384@bonkers.taronga.com> from "Peter da Silva" at Sep 28, 95 07:34:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 672 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > I think my biggest objection is that it requires install-time configuration > > administration as part of the install. > > Why do you say that? You can just install a prebuilt canned makefile or > whatever. And startup is no special case... there are all sorts of files > that could be usefully built the same way (ttys, gettydefs, inetd.conf, ...) Because the installation *is* the activation of the package. I think that install and activation should be held seperate. Hence my support for the rc[0-6].d/symlink -> init.d. 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 Sep 28 10:56:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA22522 for hackers-outgoing; Thu, 28 Sep 1995 10:56:53 -0700 Received: from blob.best.net (blob.best.net [204.156.128.88]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA22517 for ; Thu, 28 Sep 1995 10:56:51 -0700 Received: from shell1.best.com (shell1.best.com [204.156.128.10]) by blob.best.net (8.6.12/8.6.5) with ESMTP id KAA14432; Thu, 28 Sep 1995 10:56:49 -0700 Received: from rompel (rompel.vip.best.com [204.156.141.238]) by shell1.best.com (8.6.12/8.6.5) with SMTP id KAA12655; Thu, 28 Sep 1995 10:56:48 -0700 Message-Id: <199509281756.KAA12655@shell1.best.com> Comments: Authenticated sender is From: "David Rompel" Organization: None To: Brian Tao Date: Thu, 28 Sep 1995 10:56:57 -800 Subject: Re: Newest Dec 100Mbit enet chip announce Reply-to: rompel@best.com CC: freebsd-hackers@freebsd.org Priority: normal X-mailer: Pegasus Mail for Windows (v2.01) Sender: owner-hackers@freebsd.org Precedence: bulk Hi Brian, that price is for the chipset, probably a single chip It probably only needs voltage generation hw to produce the correct interface voltage (see below). Very cool price as this is in the ball park of what name brand (National & AMD) 10 MBit parts go for, bringing manufacturing costs in the $35/card range (don't quote me on this). Contact DEC marketing for more information or see their web page. cut from orig. usenet posting: The 100Mbps port contains a complete media independent interface (MII) to support voice-grade, data-grade, shielded twisted pair, and unshielded twisted pair cabling in any TX or T4 installation. [snip] All Digital press releases, fact sheets and backgrounders are archived on ftp.digital.com in the /pub/Digital/info/pr-news directory. They are also available at http://www.digital.com/ on the World Wide Web . > Date: Thu, 28 Sep 1995 02:22:24 -0400 (EDT) > From: Brian Tao > To: David Rompel > Cc: freebsd-hackers@freebsd.org > Subject: Re: Newest Dec 100Mbit enet chip announce > On Wed, 27 Sep 1995, David Rompel wrote: > > > > Price, Availability > > > > The 21140A PCI Fast Ethernet controller is priced at $23.30 in > > quantities of 5,000. > > Is that price just for the controller chip(set) or for a full > working PCI board? Considering there isn't a lot of markup on > computer hardware, that's an amazing price... > -- > Brian Tao > System Administrator, Internex Online Inc. > "Though this be madness, yet there is method in't" > > > From owner-freebsd-hackers Thu Sep 28 11:41:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24079 for hackers-outgoing; Thu, 28 Sep 1995 11:41:58 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24066 for ; Thu, 28 Sep 1995 11:41:29 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id OAA24987; Thu, 28 Sep 1995 14:42:49 -0400 Date: Thu, 28 Sep 1995 14:42:49 -0400 From: Coranth Gryphon Message-Id: <199509281842.OAA24987@healer.com> To: terry@lambert.org Subject: Re: ports startup scripts Cc: gryphon@healer.com, hackers@freebsd.org, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Sender: owner-hackers@freebsd.org Precedence: bulk From: Terry Lambert > +> Actually, it will still generate correctly, but will fail at boot > +> time since A is not runable. > +> > +> Which is what I would consider the correct behavior. > Failing to boot is NEVER correct behaviour. NEVER. OK. So, under the SysV mechanism (S##foo) , if I put in Package B, and not put in Package A (which B depends upon) what is the correct behavior? How much is going to run? "Fail at boot time" means run a sysadmin shell at that point (just like it does now if something important fails). By using "make -k" for startup, it will do whatever it can and skip anything that proper dependencies do not exit for. The only other option is to try and do some sort of sanity check when running "makerc" to determine if the things are all in the right places. (For example, using "make -n start"). -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Thu Sep 28 11:42:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24118 for hackers-outgoing; Thu, 28 Sep 1995 11:42:20 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24113 ; Thu, 28 Sep 1995 11:42:17 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id LAA14970; Thu, 28 Sep 1995 11:41:44 -0700 From: Julian Elischer Message-Id: <199509281841.LAA14970@ref.tfs.com> Subject: Re: Whither XFree86 3.1.2? To: dawes@rf900.physics.usyd.edu.au (David Dawes) Date: Thu, 28 Sep 1995 11:41:44 -0700 (PDT) Cc: gibbs@freefall.freebsd.org, nate@rocky.sri.MT.net, jkh@freefall.freebsd.org, hackers@freefall.freebsd.org In-Reply-To: <199509272355.JAA14990@rf900.physics.su.oz.au> from "David Dawes" at Sep 28, 95 09:55:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 968 Sender: owner-hackers@FreeBSD.org Precedence: bulk > Ref.tfs.com has it and it's REAL CLOSE to freefall. > >>> Was this never released for FreeBSD? I don't see anything in > >>> ftp://ftp.cdrom.com/pub/XFree86/binaries/FreeBSD* that's recent. > > Yeah, I recently noticed that what is on ftp.cdrom.com is 3.1.1 rather > than 3.1.2. > > >>The mirror script which pulls it from ftp.Xfree86.org didn't pull it > >>down. There *are* binaries there for 3.1.2 which I'm using for 2.0.5. > >> > >> > >>Nate > > > >I will look into this later today. > > ftp.xfree86.org is out of action at the moment, so if you don't already > have 3.1.2 elsewhere you'll need to try another site. Our other official > site is x.physics.usyd.edu.au, but you will probably be better off trying > one of the US mirrors. The following two should have a complete 3.1.2 > distribution (source and binaries for all platforms): > > ftp://ftp.rge.com/pub/XFree86/XFree86/3.1.2 > ftp://ftp.eecs.umich.edu/BSD/XFree86/3.1.2 > > David > From owner-freebsd-hackers Thu Sep 28 11:44:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA24325 for hackers-outgoing; Thu, 28 Sep 1995 11:44:28 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA24245 for ; Thu, 28 Sep 1995 11:43:44 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id OAA25004; Thu, 28 Sep 1995 14:46:35 -0400 Date: Thu, 28 Sep 1995 14:46:35 -0400 From: Coranth Gryphon Message-Id: <199509281846.OAA25004@healer.com> To: peter@taronga.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > > > my biggest objection is that it requires install-time configuration > > > administration as part of the install. > > > Why do you say that? You can just install a prebuilt canned makefile or > > whatever. And startup is no special case... there are all sorts of files > > that could be usefully built the same way (ttys, gettydefs, inetd.conf, ...) > > Because the installation *is* the activation of the package. I think > that install and activation should be held seperate. Hence my support > for the rc[0-6].d/symlink -> init.d. You're either not paying attention to the makefile proposal, or failing to see obvious parallels. Creating the symlink from rcN.d to init.d is the same as changing the name of the init chunk from "package.NO" to "package.mk" and running "makerc". If you don't, it is there, but does not run on startup. If you do, it runs on startup. What's the functional difference? -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Thu Sep 28 12:30:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA26343 for hackers-outgoing; Thu, 28 Sep 1995 12:30:56 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA26336 for ; Thu, 28 Sep 1995 12:30:42 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id VAA13909; Thu, 28 Sep 1995 21:30:26 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id VAA18103; Thu, 28 Sep 1995 21:30:24 +0200 Message-Id: <199509281930.VAA18103@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: "Justin T. Gibbs" cc: Mark Murray , Andreas Klemm , hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Thu, 28 Sep 1995 21:30:24 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > >You are not alone. I have a 486DX4/100/PCI and an adaptec 2940, and I get > >these the whole time, as well as the signal 11's. I just tried a reboot, > >ant the files that were corrupted before are now OK???!! They are corrupted > >in exactly that same sort of way you are reporting. > > > >My kernel is stable, the rest is a mix (a lot hand-installed). > > > >M > > The only known problem with the aic7xxx driver has to do with losing bytes > (the transfer leaves a residual of 1-13 bytes). This only happens when > the transfer is going faster then 10MB/s (like a wide cappella or atlas), > so a narrow device shouldn't show this problem. Single bit errors are > almost always ram or cache problems. The driver supports full parity > checking on its data up to the point that it is transfered to host memory, > so I don't think this is the driver's fault. I don't think you are right. I have slowed my Adaptec down to 5MB/s and I get (got) 2 errors: 1) Single bit errors - fixed by banging the box a bit an reseating the chips (cache etc) 2) Missing chunks of code - 1-13 looks about right. This is with an 2940 and an HP scsi2 (narrow) disk. Replacing the 2940 with a 1542 fixes the problem. The problem only occurs after a great deal of activity (like a big system build), and is repeatable on the broken file until a reboot. After the reboot the file is fine. If a sig11 occurs, it is also repeatable until a reboot. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Thu Sep 28 12:57:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27660 for hackers-outgoing; Thu, 28 Sep 1995 12:57:51 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27654 for ; Thu, 28 Sep 1995 12:57:48 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id MAA21578; Thu, 28 Sep 1995 12:56:16 -0700 Message-Id: <199509281956.MAA21578@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Mark Murray cc: "Justin T. Gibbs" , Andreas Klemm , hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 In-reply-to: Your message of "Thu, 28 Sep 1995 21:30:24 +0200." <199509281930.VAA18103@grumble.grondar.za> Date: Thu, 28 Sep 1995 12:56:16 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >> >You are not alone. I have a 486DX4/100/PCI and an adaptec 2940, and I get >> >these the whole time, as well as the signal 11's. I just tried a reboot, >> >ant the files that were corrupted before are now OK???!! They are corrupted >> >in exactly that same sort of way you are reporting. >> > >> >My kernel is stable, the rest is a mix (a lot hand-installed). >> > >> >M >> >> The only known problem with the aic7xxx driver has to do with losing bytes >> (the transfer leaves a residual of 1-13 bytes). This only happens when >> the transfer is going faster then 10MB/s (like a wide cappella or atlas), >> so a narrow device shouldn't show this problem. Single bit errors are >> almost always ram or cache problems. The driver supports full parity >> checking on its data up to the point that it is transfered to host memory, >> so I don't think this is the driver's fault. > >I don't think you are right. I have slowed my Adaptec down to 5MB/s and I >get (got) 2 errors: > >1) Single bit errors - fixed by banging the box a bit an reseating the > chips (cache etc) > >2) Missing chunks of code - 1-13 looks about right. This is with an > 2940 and an HP scsi2 (narrow) disk. Replacing the 2940 with a 1542 > fixes the problem. The problem only occurs after a great deal of > activity (like a big system build), and is repeatable on the broken > file until a reboot. After the reboot the file is fine. If a sig11 > occurs, it is also repeatable until a reboot. Can you turn on the ahc debug code in the driver and see if you are getting residuals with this drive? #define AHC_DEBUG int ahc_debug = AHC_SHOWABORTS|AHC_SHOWMISC; If you get residuals reported during normal file I/O (the residuals during check sense retrieval and mounting partitions are normal), then it is the same bug. >M > >-- >Mark Murray >46 Harvey Rd, Claremont, Cape Town 7700, South Africa >+27 21 61-3768 GMT+0200 >Finger mark@grumble.grondar.za for PGP key -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Thu Sep 28 13:45:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29950 for hackers-outgoing; Thu, 28 Sep 1995 13:45:27 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29908 for ; Thu, 28 Sep 1995 13:45:12 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id WAA13981; Thu, 28 Sep 1995 22:45:00 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id WAA18356; Thu, 28 Sep 1995 22:44:58 +0200 Message-Id: <199509282044.WAA18356@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: "Justin T. Gibbs" cc: Mark Murray , Andreas Klemm , hackers@freebsd.org Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 Date: Thu, 28 Sep 1995 22:44:58 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk > Can you turn on the ahc debug code in the driver and see if you are > getting residuals with this drive? > > #define AHC_DEBUG > int ahc_debug = AHC_SHOWABORTS|AHC_SHOWMISC; > > If you get residuals reported during normal file I/O (the residuals during > check sense retrieval and mounting partitions are normal), then it is > the same bug. Sure. I'll only get to it tomorrow, though... M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Thu Sep 28 13:45:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA29960 for hackers-outgoing; Thu, 28 Sep 1995 13:45:29 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA29941 for ; Thu, 28 Sep 1995 13:45:25 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA13263; Thu, 28 Sep 1995 13:40:15 -0700 From: Terry Lambert Message-Id: <199509282040.NAA13263@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Thu, 28 Sep 1995 13:40:15 -0700 (MST) Cc: terry@lambert.org, gryphon@healer.com, hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com In-Reply-To: <199509281842.OAA24987@healer.com> from "Coranth Gryphon" at Sep 28, 95 02:42:49 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1020 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Failing to boot is NEVER correct behaviour. NEVER. > > OK. So, under the SysV mechanism (S##foo) , if I put in Package B, and not > put in Package A (which B depends upon) what is the correct behavior? Don't run the packages is the best behaviour. Run the packages and have the run fail without failing subsequent components is acceptable behaviour. > How much is going to run? As much as can run, hopefully. > By using "make -k" for startup, it will do whatever it can and skip > anything that proper dependencies do not exit for. This is probably the closest you could come. > The only other option is to try and do some sort of sanity check when > running "makerc" to determine if the things are all in the right places. > (For example, using "make -n start"). Right. Allow it to be installed, but don't allow it to be made active until the dependencies are met. 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 Sep 28 13:49:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00490 for hackers-outgoing; Thu, 28 Sep 1995 13:49:31 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00476 for ; Thu, 28 Sep 1995 13:49:23 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA13277; Thu, 28 Sep 1995 13:44:20 -0700 From: Terry Lambert Message-Id: <199509282044.NAA13277@phaeton.artisoft.com> Subject: Re: ports startup scripts To: gryphon@healer.com (Coranth Gryphon) Date: Thu, 28 Sep 1995 13:44:20 -0700 (MST) Cc: peter@taronga.com, terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <199509281846.OAA25004@healer.com> from "Coranth Gryphon" at Sep 28, 95 02:46:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1276 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > Because the installation *is* the activation of the package. I think > > that install and activation should be held seperate. Hence my support > > for the rc[0-6].d/symlink -> init.d. > > You're either not paying attention to the makefile proposal, or failing > to see obvious parallels. > > Creating the symlink from rcN.d to init.d is the same as changing the name > of the init chunk from "package.NO" to "package.mk" and running "makerc". > > If you don't, it is there, but does not run on startup. If you do, it > runs on startup. What's the functional difference? Arbitration of the rename bases on dependencies existing vs. arbitration of the link based on explicit package activation (activation being denied if dependencies don't exist). The difference is whether you find out at boot time that you've been screwed or find out when you try to activate the package using the administrative tool that a dependency doesn't exist. Admittedly, you could make the makefile proposal multiple pass to get it to "do the right thing", but it would be inelegant and time consuming (at run time; programmer time is irrelevant). 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 Sep 28 14:05:01 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA01242 for hackers-outgoing; Thu, 28 Sep 1995 14:05:01 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA01217 for ; Thu, 28 Sep 1995 14:04:52 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id WAA12176; Thu, 28 Sep 1995 22:03:34 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.12/8.6.12) id VAA02832; Thu, 28 Sep 1995 21:39:50 +0100 From: Andreas Klemm Message-Id: <199509282039.VAA02832@knobel.gun.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: davidg@Root.COM Date: Thu, 28 Sep 1995 21:39:50 +0100 (MET) Cc: mark@grondar.za, hackers@freebsd.org In-Reply-To: <199509270837.BAA00184@corbin.Root.COM> from "David Greenman" at Sep 27, 95 01:36:57 am X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 1434 Sender: owner-hackers@freebsd.org Precedence: bulk > Okay, thanks for the info. There were some changes to the 2940 sequencer > code since 2.0.5, and Justin has gotten some reports of problems with wide > drives when operating them an 20MB/sec...but these seemed to go away when > the data rate was slowed down and hasn't (until now?) been seen to happen > with non-wide drives. Hi ! I think I found out, why my system crashed so frequently. Hardware problems, as some of you already said. But not the AHA 2940 or RAM chips ... no. The CPU ! I clocked down my Pentium P90 CPU to 75 MHZ (50 x 1.5) and now everything seems to work fine. I'll replace the P90, since it's within the warranty. Puh ! 3 weeks of hard work to track that down. I'm happy that I can tell you, that FreeBSD 2.0.5R sources compiled this time successfully and even the FreeBSD stable sources this evening. During the two make worlds I ran the Harddisk at 10MB/sec. No SCSI timeout problems ! So no trouble with 4GB drives at 10MB anymore ... for me so far... Thanks for your responses ! Sorry, that I didn't answer to all of you directly, but it's because of the brokenness of my system these days. I didn't save all mails ... etc Many thanks to you all ! Andreas /// -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Thu Sep 28 14:34:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02481 for hackers-outgoing; Thu, 28 Sep 1995 14:34:11 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02471 for ; Thu, 28 Sep 1995 14:34:04 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA13394; Thu, 28 Sep 1995 14:27:57 -0700 From: Terry Lambert Message-Id: <199509282127.OAA13394@phaeton.artisoft.com> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: andreas@knobel.gun.de (Andreas Klemm) Date: Thu, 28 Sep 1995 14:27:57 -0700 (MST) Cc: davidg@root.com, mark@grondar.za, hackers@FreeBSD.ORG In-Reply-To: <199509282039.VAA02832@knobel.gun.de> from "Andreas Klemm" at Sep 28, 95 09:39:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 547 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Hi ! > > I think I found out, why my system crashed so frequently. Hardware > problems, as some of you already said. But not the AHA 2940 or > RAM chips ... no. The CPU ! I clocked down my Pentium P90 CPU > to 75 MHZ (50 x 1.5) and now everything seems to work fine. > > I'll replace the P90, since it's within the warranty. Puh ! > 3 weeks of hard work to track that down. Suspect your L2 cache first. 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 Sep 28 15:00:34 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA03996 for hackers-outgoing; Thu, 28 Sep 1995 15:00:34 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA03987 for ; Thu, 28 Sep 1995 15:00:24 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id OAA19385; Thu, 28 Sep 1995 14:55:58 -0700 To: Terry Lambert cc: gryphon@healer.com (Coranth Gryphon), hackers@FreeBSD.ORG, jmb@kryten.atinc.com, patl@asimov.volant.org, peter@taronga.com Followup-to: terry@lambert.org Subject: Re: ports startup scripts In-reply-to: Your message of "Thu, 28 Sep 1995 13:40:15 PDT." <199509282040.NAA13263@phaeton.artisoft.com> Date: Thu, 28 Sep 1995 14:55:58 -0700 Message-ID: <19382.812325358@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Folks.. I'm sure that this discussion started and has continued due to the finest intentions on the part of its participants to hash out the best possible ports startup script mechanism. However, even the very best of things can become distasteful when administered in overzealous quantities and those things must unfortunately include chocolate, cotton candy and about the last 3/4 of this conversation. Please, can you guys take it private now? This ping-pong exchange has exhausted my poor inbox and ceased to be of any interest whatsoever to the majority of residents in -hackers quite some time ago! Why not simply present us with the final conclusion once you've finished the internal debate? :-) Jordan From owner-freebsd-hackers Thu Sep 28 15:07:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA04554 for hackers-outgoing; Thu, 28 Sep 1995 15:07:09 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA04540 for ; Thu, 28 Sep 1995 15:07:02 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id XAA27478; Thu, 28 Sep 1995 23:02:06 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.12/8.6.12) id WAA03839; Thu, 28 Sep 1995 22:41:22 +0100 From: Andreas Klemm Message-Id: <199509282141.WAA03839@knobel.gun.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: terry@lambert.org (Terry Lambert) Date: Thu, 28 Sep 1995 22:41:22 +0100 (MET) Cc: davidg@root.com, mark@grondar.za, hackers@FreeBSD.ORG In-Reply-To: <199509282127.OAA13394@phaeton.artisoft.com> from "Terry Lambert" at Sep 28, 95 02:27:57 pm X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 712 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > I think I found out, why my system crashed so frequently. Hardware > > problems, as some of you already said. But not the AHA 2940 or > > RAM chips ... no. The CPU ! I clocked down my Pentium P90 CPU > > to 75 MHZ (50 x 1.5) and now everything seems to work fine. > > > > I'll replace the P90, since it's within the warranty. Puh ! > > 3 weeks of hard work to track that down. > > Suspect your L2 cache first. Hmmm ... it's burst cache ram ... the _bleeding_ edge ?!?! ;-) -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Thu Sep 28 15:18:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05001 for hackers-outgoing; Thu, 28 Sep 1995 15:18:45 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA04992 for ; Thu, 28 Sep 1995 15:18:40 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA13468; Thu, 28 Sep 1995 15:12:16 -0700 From: Terry Lambert Message-Id: <199509282212.PAA13468@phaeton.artisoft.com> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: andreas@knobel.gun.de (Andreas Klemm) Date: Thu, 28 Sep 1995 15:12:16 -0700 (MST) Cc: terry@lambert.org, davidg@root.com, mark@grondar.za, hackers@FreeBSD.ORG In-Reply-To: <199509282141.WAA03839@knobel.gun.de> from "Andreas Klemm" at Sep 28, 95 10:41:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 505 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > I'll replace the P90, since it's within the warranty. Puh ! > > > 3 weeks of hard work to track that down. > > > > Suspect your L2 cache first. > > Hmmm ... it's burst cache ram ... the _bleeding_ edge ?!?! ;-) Doesn't matter. A cache problem is much more likely than a spec failure on a P90. Unless the P90 is ovreheating. You do have a CPU fan, right? 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 Sep 28 17:07:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09439 for hackers-outgoing; Thu, 28 Sep 1995 17:07:44 -0700 Received: from rf900.physics.su.oz.au (rf900.physics.su.OZ.AU [129.78.129.109]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09433 for ; Thu, 28 Sep 1995 17:07:34 -0700 Received: (from dawes@localhost) by rf900.physics.su.oz.au (8.6.11/8.6.9) id KAA17498; Fri, 29 Sep 1995 10:07:10 +1000 From: David Dawes Message-Id: <199509290007.KAA17498@rf900.physics.su.oz.au> Subject: Re: Whither XFree86 3.1.2? To: julian@ref.tfs.com (Julian Elischer) Date: Fri, 29 Sep 1995 10:07:10 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199509281841.LAA14970@ref.tfs.com> from "Julian Elischer" at Sep 28, 95 11:41:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 157 Sender: owner-hackers@freebsd.org Precedence: bulk >Ref.tfs.com has it and it's REAL CLOSE to freefall. For the FreeBSD binaries, yes. ftp.cdrom.com usually has the full XFree86 distribution though. David From owner-freebsd-hackers Thu Sep 28 17:19:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09741 for hackers-outgoing; Thu, 28 Sep 1995 17:19:14 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09734 for ; Thu, 28 Sep 1995 17:19:10 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id RAA22391; Thu, 28 Sep 1995 17:18:12 -0700 Message-Id: <199509290018.RAA22391@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: David Dawes cc: julian@ref.tfs.com (Julian Elischer), hackers@freebsd.org Subject: Re: Whither XFree86 3.1.2? In-reply-to: Your message of "Fri, 29 Sep 1995 10:07:10 +1000." <199509290007.KAA17498@rf900.physics.su.oz.au> Date: Thu, 28 Sep 1995 17:18:12 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >>Ref.tfs.com has it and it's REAL CLOSE to freefall. > >For the FreeBSD binaries, yes. ftp.cdrom.com usually has the >full XFree86 distribution though. > >David As it does now. WC had a copy of the full 3.1.2 tree from when we did the X11R6p12 CDROM. I supped it over to ftp.cdrom.com yesturday. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Thu Sep 28 18:29:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA12484 for hackers-outgoing; Thu, 28 Sep 1995 18:29:50 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA12479 for ; Thu, 28 Sep 1995 18:29:47 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA13960; Thu, 28 Sep 1995 18:25:13 -0700 From: Terry Lambert Message-Id: <199509290125.SAA13960@phaeton.artisoft.com> Subject: Re: SYSCONS PROBLEM IDENTIFIED To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Thu, 28 Sep 1995 18:25:13 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Sep 20, 95 09:39:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1610 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > It isn't turning attributes off, but (1) "erase with black color" > instead of (2) "erase with background color". I.e. Elm can > turn reverse on, then attempt to clear screen or end of line. > For (1) you got clear screen, for (2) you got reverse screen. > Sounds like Elm error, it must turn off highlight before any clearing. > Curses works this way. > > Maybe it is recent SCO addition (erase with black color). > I check Xenix box and got the same behaviour like in FreeBSD. > Can you check Linux console too? (it attempts to emulate SCO > somehow). OK; I have checked the Linux console six ways from sunday. Start at default: ^[[43m^[[2J clear the screen to white text on orange ^[[47m^[[30m^[[2J clear the screen to black text on white ^[[40m^[[47m^[[2J clear the screen to white text on black (restore default) ^[7m enable reverse ^[7m^[2J clear screen to white text on black, but leave reverse on so that prompt is black on white text. This is what is expected (and happens) on an SCO box as well (well, not orange, that's not a default PC color). > Advantage of "erase with background color" is that you can quickly > fill whole screen with any color without putting lots of damn spaces. Agreed, *if* you set the color. The point is, the attribute and the color state are maintained seperately on SCO and Xenix 2.3.1, but not on FreeBSD. A full SCO console emulation will include 10m, 11m, and 12m for character set selection 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 Thu Sep 28 18:50:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA13058 for hackers-outgoing; Thu, 28 Sep 1995 18:50:28 -0700 Received: from UUCP-GW.CC.UH.EDU (root@UUCP-GW.CC.UH.EDU [129.7.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA13052 for ; Thu, 28 Sep 1995 18:50:25 -0700 Received: from Taronga.COM by UUCP-GW.CC.UH.EDU with UUCP id AA24678 (5.67a/IDA-1.5 for hackers@freebsd.org); Thu, 28 Sep 1995 20:47:52 -0500 Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id UAA20335 for hackers@freebsd.org; Thu, 28 Sep 1995 20:22:43 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199509290122.UAA20335@bonkers.taronga.com> Subject: Re: ports startup scripts To: hackers@freebsd.org Date: Thu, 28 Sep 1995 20:22:42 -0500 (CDT) In-Reply-To: <199509281423.KAA24338@healer.com> from "Coranth Gryphon" at Sep 28, 95 10:23:40 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 683 Sender: owner-hackers@freebsd.org Precedence: bulk > We can only avoid editing files so much. Password files, inetd.conf, services. > These have to be editied, or we have to throw them out and replace them > with another model. At some point, you either have to allow auto-editing > of system files, or just leave some stuff to hand-configuration. inetd.conf and services don't need to be auto-edited. You auto-generate them based on the templates in /etc/packages/*/inetd.conf and .../services. You will have to remember to edit /etc/packages/*/inetd.conf instead of inetd.conf itself if you need to tune it. Most people don't. The only file I can think of that can't be done this way without a lot of pain is /etc/master.passwd From owner-freebsd-hackers Thu Sep 28 20:31:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA17276 for hackers-outgoing; Thu, 28 Sep 1995 20:31:21 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA17264 for ; Thu, 28 Sep 1995 20:31:13 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id XAA26384; Thu, 28 Sep 1995 23:34:56 -0400 Date: Thu, 28 Sep 1995 23:34:56 -0400 From: Coranth Gryphon Message-Id: <199509290334.XAA26384@healer.com> To: gryphon@healer.com, terry@lambert.org Subject: Re: ports startup scripts Cc: hackers@FreeBSD.ORG, peter@taronga.com Sender: owner-hackers@FreeBSD.ORG Precedence: bulk From: Terry Lambert > Arbitration of the rename bases on dependencies existing vs. arbitration > of the link based on explicit package activation (activation being denied > if dependencies don't exist). If we do the sanity check, then we can verify correctness at install time, with a cost of a lot more detail work required for each package. The sanity check requires being able to clearly specify what requirements exist, AND what each target satisfies. That is just not feasible. > The difference is whether you find out at boot time that you've been > screwed or find out when you try to activate the package using the It's far easier to run "make -n start" to check validity of the configuration. -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 3 Hansom Drive, Merrimack, NH 03054 Disclaimer: All these words are yours, except Europa... From owner-freebsd-hackers Thu Sep 28 23:31:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA26560 for hackers-outgoing; Thu, 28 Sep 1995 23:31:18 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA26545 for ; Thu, 28 Sep 1995 23:31:11 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id HAA27146 for hackers@freebsd.org; Fri, 29 Sep 1995 07:31:05 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.12/8.6.12) id XAA04055 for hackers@freebsd.org; Thu, 28 Sep 1995 23:02:28 +0100 From: Andreas Klemm Message-Id: <199509282202.XAA04055@knobel.gun.de> Subject: -stable: tuucp1061: tproto, so fast ! To: hackers@freebsd.org Date: Thu, 28 Sep 1995 23:02:28 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 505 Sender: owner-hackers@freebsd.org Precedence: bulk Hi ! Never saw such transmission speeds using uucp via ppp. 16550er UART, Zyxel 1496EG+. Well done ! Maybe the quality of ppp increased, too. Anyway ... good work ! news easix (1995-09-28 22:54:06.04) received 184342 bytes in 89.577 seconds (2057 bytes/sec) on port TCP -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Thu Sep 28 23:48:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA27599 for hackers-outgoing; Thu, 28 Sep 1995 23:48:30 -0700 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA27594 for ; Thu, 28 Sep 1995 23:48:26 -0700 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) with UUCP id HAA02872; Fri, 29 Sep 1995 07:47:17 +0100 Received: (from andreas@localhost) by knobel.gun.de (8.6.12/8.6.12) id HAA13907; Fri, 29 Sep 1995 07:35:26 +0100 From: Andreas Klemm Message-Id: <199509290635.HAA13907@knobel.gun.de> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: terry@lambert.org (Terry Lambert) Date: Fri, 29 Sep 1995 07:35:26 +0100 (MET) Cc: terry@lambert.org, davidg@root.com, mark@grondar.za, hackers@FreeBSD.ORG In-Reply-To: <199509282212.PAA13468@phaeton.artisoft.com> from "Terry Lambert" at Sep 28, 95 03:12:16 pm X-Mailer: ELM [version 2.4 PL24 ME7] Content-Type: text Content-Length: 1790 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > > I'll replace the P90, since it's within the warranty. Puh ! > > > > 3 weeks of hard work to track that down. > > > > > > Suspect your L2 cache first. > > > > Hmmm ... it's burst cache ram ... the _bleeding_ edge ?!?! ;-) > > Doesn't matter. A cache problem is much more likely than a spec failure > on a P90. > > Unless the P90 is ovreheating. You do have a CPU fan, right? Well not only a fan. A fan with a heat sensor. So I thought I'm relatively save, not overheating the P90. And I think this is the only thing that might happen, when overclocking a chip. Ok, the CPU works perfectly with 75 MHz, It made 2 make worlds and now I was supping -current the whole night long without problems. Can I assume, that the CPU should be completely damaged at any frequency, when I had overheated it ??? So that it's more likely, that the L2 burst cache is buggy ??? At what speed is the cache driven ?? Same as CPU speed ? Or has is the same base frequency as the oscillator (50,60,66 MHz) ??? I think base*something (1.5,2.0,...). The problem is, that a friend of mine has the problem, what to give back to his distributor, we don't want to have much trouble with his dealer .... Are there test programs available for the 2nd level cache .... Perhaps souns silly since this is not the kind of memory, one has directly access to ... But perhaps someone has a good idea, how to find out precisely, what's damaged and what not. Ok, I could start asking people, to give my their working P90 for a weekend ... but I don't know someone who could .... -- $$ apsfilter - magic print filter 4lpd @home : andreas@knobel.gun.de $$ ftp://sunsite.unc.edu @work : andreas@sunny.wup.de $$ /pub/Linux/system/Printing/aps-491.tgz knobel: >>> powered by FreeBSD <<< From owner-freebsd-hackers Fri Sep 29 00:26:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA29839 for hackers-outgoing; Fri, 29 Sep 1995 00:26:32 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA29827 ; Fri, 29 Sep 1995 00:26:29 -0700 Message-Id: <199509290726.AAA29827@freefall.freebsd.org> Subject: Re: SYSCONS PROBLEM IDENTIFIED To: terry@lambert.org (Terry Lambert) Date: Fri, 29 Sep 1995 00:26:29 -0700 (PDT) Cc: ache@astral.msk.su, terry@lambert.org, hackers@freebsd.org In-Reply-To: <199509290125.SAA13960@phaeton.artisoft.com> from "Terry Lambert" at Sep 28, 95 06:25:13 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 768 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Terry Lambert who wrote: [much deleted] > A full SCO console emulation will include 10m, 11m, and 12m for character > set selection as well. Hmm, do you have a "machine readable" version of the latest SCO console specs ? Mine went away with our last 3.2.2 system here at work :( If I can get my hands on the docs for the SCO console, I'll change syscons accordingly (We do claim SCO compat right)... Also is there a specification of the Linux console (bisides reading the code) I'd like to know, It might come in usefull for my next little project.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Fri Sep 29 00:33:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA00285 for hackers-outgoing; Fri, 29 Sep 1995 00:33:29 -0700 Received: (from sos@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA00277 ; Fri, 29 Sep 1995 00:33:26 -0700 Message-Id: <199509290733.AAA00277@freefall.freebsd.org> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: terry@lambert.org (Terry Lambert) Date: Fri, 29 Sep 1995 00:33:26 -0700 (PDT) Cc: andreas@knobel.gun.de, terry@lambert.org, davidg@root.com, mark@grondar.za, hackers@freebsd.org In-Reply-To: <199509282212.PAA13468@phaeton.artisoft.com> from "Terry Lambert" at Sep 28, 95 03:12:16 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 809 Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Terry Lambert who wrote: > > > > > I'll replace the P90, since it's within the warranty. Puh ! > > > > 3 weeks of hard work to track that down. > > > > > > Suspect your L2 cache first. > > > > Hmmm ... it's burst cache ram ... the _bleeding_ edge ?!?! ;-) > > Doesn't matter. A cache problem is much more likely than a spec failure > on a P90. > > Unless the P90 is ovreheating. You do have a CPU fan, right? Or you have got one of the "remarked" p75's that has been found in several places (the german magazine CT follows this pretty closely). Where did you buy your CPU/Motherboard ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-hackers Fri Sep 29 01:57:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA05007 for hackers-outgoing; Fri, 29 Sep 1995 01:57:21 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA04283 for ; Fri, 29 Sep 1995 01:51:05 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id JAA17224 for freebsd-hackers@freefall.cdrom.com; Fri, 29 Sep 1995 09:48:56 +0100 Date: Fri, 29 Sep 1995 09:48:56 +0100 From: "Christoph P. Kukulies" Message-Id: <199509290848.JAA17224@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: WD8013 problem Sender: owner-hackers@FreeBSD.org Precedence: bulk A while ago I reported a strangeness with connecting to one of my machines. Strange is now that I can only observe the effect with that one machine and gradually I'm beginning to think it's hardware or a driver problem. Let me enumerate the problems I have: 1/ Connecting from my remote 1.1.5.1 site via slip gives the following picture. $ telnet gil Trying 137.226.31.2... Connected to gilberto.physik.rwth-aachen.de. Escape character is '^]'. FreeBSD (gil.physik.rwth-aachen.de) (ttyp2) (note the missing login: prompt - it only appears when I type ) Same telnet to a neighboured machine: $ telnet blues Trying 137.226.31.18... Connected to blues.physik.rwth-aachen.de. Escape character is '^]'. FreeBSD (blues.physik.rwth-aachen.de) (ttyp0) login: Prompt appears. 2/ Logging in from home from my KA9Q/NOS box via ISDN I get the login prompt but when typing my login name (kuku) it looks like: Connected to gilberto.physik.rwth-aachen.de. Escape character is '^]'. FreeBSD (gil.physik.rwth-aachen.de) (ttyp2) login:uku Note the missing first character k from my login name.I definitely typed it but it gets eaten up by something. Doing the same telnet to blues does not have this effect. 3/ Doing rlogin (also telnet I believe) sessions from gil to neighboured hosts often results in getting a connection refused, connection closed by foreign host the first time, rlogin the second time then works. Now what is peculiar to gil ? The only thing I can see (beside CPU, 20MB, 486/33) is a WD8013 EP card which the other hosts don't have Im running a 2.1.0-950726-SNAP kernel on gil. The neighboured systems (despite the remote SLIP site are 2.0.5 systems or -current ). I'm clueless at this point. Maybe the next thing I'll do is change the network adapter to a different type. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Sep 29 02:42:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA07357 for hackers-outgoing; Fri, 29 Sep 1995 02:42:22 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA07195 for ; Fri, 29 Sep 1995 02:38:55 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA19200; Fri, 29 Sep 1995 10:39:59 +0100 From: Luigi Rizzo Message-Id: <199509290939.KAA19200@labinfo.iet.unipi.it> Subject: Re: Bulletins for 2.1.0-950922-SNAP: To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 29 Sep 1995 10:39:59 +0100 (MET) Cc: nate@rocky.sri.MT.net, hackers@freebsd.org In-Reply-To: <18327.812299887@time.cdrom.com> from "Jordan K. Hubbard" at Sep 28, 95 07:51:08 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 880 Sender: owner-hackers@freebsd.org Precedence: bulk > I have been looking at this issue lately WRT producing an IDE CDROM > version of boot.flp and will probably fold your changes in along > with a few others - I wasn't simply ignoring the patch! I have a plea for something I consider vital. * make sure that "fdisk" and "disklabel" work in this snapshot; * make a "fixit" floppy. It was painful to make it in the july snap, without recompiling all the source tree; the makefile didn't have the right dependencies. Thanks 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 Fri Sep 29 02:58:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA08547 for hackers-outgoing; Fri, 29 Sep 1995 02:58:19 -0700 Received: from ccslinux.dlsu.edu.ph (linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA08518 for ; Fri, 29 Sep 1995 02:58:03 -0700 Received: by ccslinux.dlsu.edu.ph (Linux Smail3.1.28.1 #13) Sender: owner-hackers@FreeBSD.org Precedence: bulk id m0syc3l-000A5LC; Fri, 29 Sep 95 17:48 GMT+0800 Date: Fri, 29 Sep 1995 17:48:48 +48000 From: "Humprey C. Sy" Subject: Questions on system calls To: hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! We're currently developing a software on FreeBSD platform, and generally, we are not really familiar with system calls. We were hoping you'd take time out to answer these questions. Thanks! 1. Are system calls preemptive? 2. How do we create additional system calls? 3. Do we have to recompile the whole kernel if we create additional system calls? - Humprey - From owner-freebsd-hackers Fri Sep 29 03:13:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA09623 for hackers-outgoing; Fri, 29 Sep 1995 03:13:20 -0700 Received: from physics.su.oz.au (dawes@physics.su.OZ.AU [129.78.129.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA09616 for ; Fri, 29 Sep 1995 03:13:15 -0700 Received: (from dawes@localhost) by physics.su.oz.au (8.6.12/8.6.12) id UAA15300; Fri, 29 Sep 1995 20:05:36 +1000 From: David Dawes Message-Id: <199509291005.UAA15300@physics.su.oz.au> Subject: Re: WD8013 problem To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Fri, 29 Sep 1995 20:05:35 +1000 (EST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199509290848.JAA17224@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Sep 29, 95 09:48:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1884 Sender: owner-hackers@FreeBSD.org Precedence: bulk >A while ago I reported a strangeness with connecting to one >of my machines. Strange is now that I can only observe >the effect with that one machine and gradually I'm beginning to >think it's hardware or a driver problem. Let me enumerate the >problems I have: > >1/ Connecting from my remote 1.1.5.1 site via slip gives the following > picture. > $ telnet gil > > Trying 137.226.31.2... > Connected to gilberto.physik.rwth-aachen.de. > Escape character is '^]'. > > FreeBSD (gil.physik.rwth-aachen.de) (ttyp2) > > (note the missing login: prompt - it only appears when I type ) I've sometimes seen this symptom, and I've seen it happen when running 'telnet localhost' on a 2.0.5 machine. It doesn't always happen though. I just tried it, and the first two attempts worked OK, and the third showed the problem (I just typed ^D at the login prompts): rf900[116]> telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. FreeBSD (rf900) (ttypn) login: Connection closed by foreign host. rf900[117]> telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. FreeBSD (rf900) (ttypn) login: Connection closed by foreign host. rf900[118]> telnet localhost Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. FreeBSD (rf900) (ttypn) Connection closed by foreign host. >3/ Doing rlogin (also telnet I believe) sessions from gil to > neighboured hosts often results in getting a connection refused, > connection closed by foreign host the first time, rlogin the > second time then works. There was a time when I saw something like this, but with rsh. I may have been running the rsh from an SVR4 machine -- it was a while ago and I don't remember the details. I think this problem disappeared when I set tcp_extensions to NO in /etc/sysconfig. David From owner-freebsd-hackers Fri Sep 29 07:17:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA16824 for hackers-outgoing; Fri, 29 Sep 1995 07:17:41 -0700 Received: from falco.ibama.gov.br ([200.6.48.80]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA16813 for ; Fri, 29 Sep 1995 07:17:24 -0700 Received: by falco.ibama.gov.br (AIX 3.2/UCB 5.64/4.03) id AA15715; Fri, 29 Sep 1995 11:17:09 -0300 Newsgroups: comp.unix.bsd.freebsd.misc Path: jazz.cr-df.rnp.br!usenet From: "Andries J. Algera" Subject: NIS maps and passwd file formats problem? Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit Organization: CSR - IBAMA Mime-Version: 1.0 Date: Mon, 25 Sep 1995 20:33:30 GMT X-Mailer: Mozilla 1.1N (X11; I; SunOS 5.3 sun4m) X-Url: news:comp.unix.bsd.freebsd.misc Lines: 42 Resent-Date: Fri, 29 Sep 1995 11:15:33 -0300 (GRNLNDST) Resent-From: Bernardo Brummer Resent-To: freebsd-hackers@freebsd.org Resent-Message-Id: Apparently-To: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk I recently installed Freebsd and would like to have it using NIS for authentication. We already have a NIS+ server in NIS mode running on a SPARC w/ Solaris 2.3. The machine w/ FreeBSD seems to recognize perfectly well the NIS server, commands like ypcat passwd give the result I expect. In order to be able to use the NIS-password map for loging in, I put the following at the end of the password file (using vipw) +::::::::: So one would expect to be able to log in. However to my surprise I get the following error after typing a login name: yp_order: clnt_call: RPC: Procedure unavailable I suppose that the format of the password file and the NIS map are different. I found the password file having the format as described in passwd(5), whereas the NIS map has the following format (7 fields instead of 10): andries:z6rdfghast1.:330:30:Andries Algera:/home/vera:/bin/ksh Could anyone out there help me to solve this problem. Cheers, Andries -- -------------------------------------------------------------------- Andries Algera CSR - IBAMA Brasilia / DF - Brasil ph: +5561 316-1218 316-1219 316-1220 -------------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 29 08:15:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18620 for hackers-outgoing; Fri, 29 Sep 1995 08:15:17 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18601 for ; Fri, 29 Sep 1995 08:14:57 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id QAA17811; Fri, 29 Sep 1995 16:11:10 +0100 Message-Id: <199509291511.QAA17811@gilberto.physik.rwth-aachen.de> Subject: Re: WD8013 problem To: dennis@etinc.com (dennis) Date: Fri, 29 Sep 1995 16:11:09 +0100 (MET) Cc: freebsd-hackers@freefall.FreeBSD.org (user alias) In-Reply-To: <199509291423.KAA01809@etinc.com> from "dennis" at Sep 29, 95 10:23:12 am From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1571 Sender: owner-hackers@FreeBSD.org Precedence: bulk [trimmed] > >think it's hardware or a driver problem. Let me enumerate the > >problems I have: > > > >1/ Connecting from my remote 1.1.5.1 site via slip gives the following > > picture. > > $ telnet gil > > > > Trying 137.226.31.2... > > Connected to gilberto.physik.rwth-aachen.de. > > Escape character is '^]'. > > > > FreeBSD (gil.physik.rwth-aachen.de) (ttyp2) > > > > (note the missing login: prompt - it only appears when I type ) To clarify: If I do nothing here the prompt never appears until the connections times out. > > > > Same telnet to a neighboured machine: > > $ telnet blues > > Trying 137.226.31.18... > > Connected to blues.physik.rwth-aachen.de. > > Escape character is '^]'. > > > > FreeBSD (blues.physik.rwth-aachen.de) (ttyp0) > > > > login: > > > > This happens on several of my FreeBSD machines. I'm not using WD8013s see above: Are you sure it's not slow response, process activation or whatever happens on the server side? I often see 'slow' connections where the prompt appears after a significant delay. But this is not what I'm describing. In my case the prompt appears immediately after I hit return as if it's already there. > > Dennis > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com > > Synchronous Communications Cards and Routers For > Discriminating Tastes. 56k to T1 and beyond. Frame > Relay, PPP, HDLC, and X.25 > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Sep 29 08:29:51 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA19157 for hackers-outgoing; Fri, 29 Sep 1995 08:29:51 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA19150 for ; Fri, 29 Sep 1995 08:29:47 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id IAA00236; Fri, 29 Sep 1995 08:28:20 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id IAA00239; Fri, 29 Sep 1995 08:29:40 -0700 Message-Id: <199509291529.IAA00239@corbin.Root.COM> To: Christoph Kukulies cc: dennis@etinc.com (dennis), freebsd-hackers@freefall.freebsd.org (user alias) Subject: Re: WD8013 problem In-reply-to: Your message of "Fri, 29 Sep 95 16:11:09 BST." <199509291511.QAA17811@gilberto.physik.rwth-aachen.de> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 29 Sep 1995 08:29:39 -0700 Sender: owner-hackers@FreeBSD.org Precedence: bulk >> > (note the missing login: prompt - it only appears when I type ) > >To clarify: If I do nothing here the prompt never appears >until the connections times out. > >> This happens on several of my FreeBSD machines. I'm not using WD8013s > >see above: Are you sure it's not slow response, process activation >or whatever happens on the server side? I often see 'slow' connections >where the prompt appears after a significant delay. But this is not what >I'm describing. >In my case the prompt appears immediately after I hit return >as if it's already there. This is caused by a race condition in the options negotiation of telnetd and has been recently fixed. This fix was brought into 2.1-stable, and thus will be in the 2.1 release. -DG From owner-freebsd-hackers Fri Sep 29 08:36:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA19765 for hackers-outgoing; Fri, 29 Sep 1995 08:36:30 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA19753 for ; Fri, 29 Sep 1995 08:36:26 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id IAA07774; Fri, 29 Sep 1995 08:30:19 -0700 To: "Christoph P. Kukulies" cc: freebsd-hackers@freefall.freebsd.org Subject: Re: WD8013 problem In-reply-to: Your message of "Fri, 29 Sep 1995 09:48:56 BST." <199509290848.JAA17224@gilberto.physik.rwth-aachen.de> Date: Fri, 29 Sep 1995 08:30:18 -0700 Message-ID: <7772.812388618@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > A while ago I reported a strangeness with connecting to one > of my machines. Strange is now that I can only observe > the effect with that one machine and gradually I'm beginning to > think it's hardware or a driver problem. Let me enumerate the > problems I have: FWIW, I've seen similar problems with telnet negotiation from time to time. I would be interested in the results of your swapping various components - it could be that you've uncovered a very very subtle bug somewhere. I'm assuming that both machines are running the *exact same* version of the OS, right? Otherwise the test results will be useless. Things *have* changed in that area between almost every major release and point release. Jordan From owner-freebsd-hackers Fri Sep 29 08:37:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA19894 for hackers-outgoing; Fri, 29 Sep 1995 08:37:58 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA19881 for ; Fri, 29 Sep 1995 08:37:53 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id IAA07856; Fri, 29 Sep 1995 08:35:35 -0700 To: Luigi Rizzo cc: nate@rocky.sri.MT.net, hackers@freebsd.org Subject: Re: Bulletins for 2.1.0-950922-SNAP: In-reply-to: Your message of "Fri, 29 Sep 1995 10:39:59 BST." <199509290939.KAA19200@labinfo.iet.unipi.it> Date: Fri, 29 Sep 1995 08:35:34 -0700 Message-ID: <7854.812388934@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > I have a plea for something I consider vital. > > * make sure that "fdisk" and "disklabel" work in this snapshot; That's out of my control, but if anyone wants to dive on those utilities.. I've a hard enough time just making sysinstall do the job correctly. > * make a "fixit" floppy. It was painful to make it in the july snap, > without recompiling all the source tree; the makefile didn't have > the right dependencies. The fixit floppy was reborn in a slightly different (but more powerful and flexible) mechanism with the last snapshot. Take a look at it! Jordan From owner-freebsd-hackers Fri Sep 29 11:16:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA25835 for hackers-outgoing; Fri, 29 Sep 1995 11:16:55 -0700 Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA25828 for ; Fri, 29 Sep 1995 11:16:52 -0700 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id TAA18196; Fri, 29 Sep 1995 19:14:06 +0100 Message-Id: <199509291814.TAA18196@gilberto.physik.rwth-aachen.de> Subject: Re: WD8013 problem To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 29 Sep 1995 19:14:05 +0100 (MET) Cc: kuku@gilberto.physik.rwth-aachen.de, freebsd-hackers@freefall.freebsd.org In-Reply-To: <7772.812388618@time.cdrom.com> from "Jordan K. Hubbard" at Sep 29, 95 08:30:18 am From: Christoph Kukulies Reply-To: Christoph Kukulies X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 999 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > > A while ago I reported a strangeness with connecting to one > > of my machines. Strange is now that I can only observe > > the effect with that one machine and gradually I'm beginning to > > think it's hardware or a driver problem. Let me enumerate the > > problems I have: > > FWIW, I've seen similar problems with telnet negotiation from time to > time. I would be interested in the results of your swapping various > components - it could be that you've uncovered a very very subtle bug > somewhere. I'm assuming that both machines are running the *exact > same* version of the OS, right? Otherwise the test results will I'll make it run the same version. At present the machine (gil) showing the symptom is a 2.1.0-950726-SNAP GENERIC kernel. But I will make it to -current for the tests. > be useless. Things *have* changed in that area between almost > every major release and point release. > > Jordan > > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri Sep 29 11:21:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA25929 for hackers-outgoing; Fri, 29 Sep 1995 11:21:14 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA25924 ; Fri, 29 Sep 1995 11:21:10 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15099; Fri, 29 Sep 1995 11:16:43 -0700 From: Terry Lambert Message-Id: <199509291816.LAA15099@phaeton.artisoft.com> Subject: Re: SYSCONS PROBLEM IDENTIFIED To: sos@FreeBSD.ORG Date: Fri, 29 Sep 1995 11:16:43 -0700 (MST) Cc: terry@lambert.org, ache@astral.msk.su, hackers@FreeBSD.ORG In-Reply-To: <199509290726.AAA29827@freefall.freebsd.org> from "sos@FreeBSD.ORG" at Sep 29, 95 00:26:29 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1253 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > A full SCO console emulation will include 10m, 11m, and 12m for character > > set selection as well. > > Hmm, do you have a "machine readable" version of the latest SCO > console specs ? Mine went away with our last 3.2.2 system > here at work :( I'll see if I can find one. I certainly have SCO manuals; I guess I can type one in if I have to. A lot of the behaviour isn't perfectly obvious from the manuals; unfortunately, it's been 4 years since I've written an SCO console emulation for a commercial terminal emulation package, and actually, the first one was back in 1988, so I might not be able to identify all of the possible issues while typing it in. 8-(. > If I can get my hands on the docs for the SCO console, I'll change > syscons accordingly (We do claim SCO compat right)... 8-). Good. I'll see if I can find the scan code mode documentation used by SCO WP and MS Word on the console. > Also is there a specification of the Linux console (bisides > reading the code) I'd like to know, It might come in usefull > for my next little project.. None that I have been able to find, sorry. 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 Fri Sep 29 11:28:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26061 for hackers-outgoing; Fri, 29 Sep 1995 11:28:33 -0700 Received: from cecusac.gdl.iteso.mx (cecusac.gdl.iteso.mx [148.201.1.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26056 for ; Fri, 29 Sep 1995 11:28:28 -0700 Received: from mexicano.gdl.iteso.mx ([148.201.1.10]) by cecusac.gdl.iteso.mx (8.6.11/8.6.9) with SMTP id MAA25542; Fri, 29 Sep 1995 12:26:16 -0600 Message-Id: <199509291826.MAA25542@cecusac.gdl.iteso.mx> Received: from MEXICANO/MERCURYQ by mexicano.gdl.iteso.mx (Mercury 1.1); Fri, 29 Sep 95 12:26:34 -0600 From: "Hector Gonzalez Jaime." Organization: ITESO university. To: peter@taronga.com (Peter da Silva), hackers@FreeBSD.ORG Date: Fri, 29 Sep 1995 12:26:07 CST Subject: Re: That annoying pty problem again... Priority: normal X-mailer: Pegasus Mail v3.1 (R1a) Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I've been getting it from people quitting telnet sessions without exiting the > program they were running. > > When you close a PTY, what should happen is you get a SIGHUP, and further reads > from the PTY get EOF. > > I suspect that some programs ignore both these events. > I get this same problem with getty and users that turn off their modems to hangup. Hector Gonzalez Jaime. Iteso, Guadalajara, Mexico. cacho@mexicano.gdl.iteso.mx From owner-freebsd-hackers Fri Sep 29 11:41:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26561 for hackers-outgoing; Fri, 29 Sep 1995 11:41:15 -0700 Received: from elf.kendall.mdcc.edu (elf.kendall.mdcc.edu [147.70.150.122]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26556 for ; Fri, 29 Sep 1995 11:41:12 -0700 Received: (from freelist@localhost) by elf.kendall.mdcc.edu (8.6.11/8.6.9) id OAA29048; Fri, 29 Sep 1995 14:30:44 -0400 Date: Fri, 29 Sep 1995 14:30:42 -0400 (EDT) From: Don Whiteside To: Network Coordinator cc: hackers@freebsd.org Subject: Re: FreeBSD Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sun, 24 Sep 1995, Network Coordinator wrote: > 1) Most of these questions should not be hackers. Try questions. This seems to happen constantly. Perhaps 'hackers' is too close in meaning to 'experts' (sure not true in MY case!) and the list should be changed to something more akin to 'development.' From owner-freebsd-hackers Fri Sep 29 11:42:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA26612 for hackers-outgoing; Fri, 29 Sep 1995 11:42:37 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA26607 for ; Fri, 29 Sep 1995 11:42:34 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15118; Fri, 29 Sep 1995 11:33:12 -0700 From: Terry Lambert Message-Id: <199509291833.LAA15118@phaeton.artisoft.com> Subject: Re: make world on FreeBSD-stable impossible. cc1: ... signal 11 To: andreas@knobel.gun.de (Andreas Klemm) Date: Fri, 29 Sep 1995 11:33:12 -0700 (MST) Cc: terry@lambert.org, davidg@root.com, mark@grondar.za, hackers@FreeBSD.ORG In-Reply-To: <199509290635.HAA13907@knobel.gun.de> from "Andreas Klemm" at Sep 29, 95 07:35:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2355 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > Ok, the CPU works perfectly with 75 MHz, It made 2 make worlds and > now I was supping -current the whole night long without problems. > Can I assume, that the CPU should be completely damaged at any > frequency, when I had overheated it ??? No; overheat != cook. > So that it's more likely, that the L2 burst cache is buggy ??? Unless it's a remarked P75 (as has been suggested) and you are screwed. One way to check this *might* be go for clocking it as a P66. If it's the cache, then the memory clock rate went from 33 to 25 when you went to 75, so going to 66 will boost it back to 33 assuming you had a P100. A P90 runs at 90, so you are on the order of 3 times faster. You may be able to clock it as a native 50 or native 60 (was there a native 66, non-doubled?) and start pushing it. Basically, if the cache isn't ~15ns, it won't handle 90MHz. I guess the question is whether the chip can handle this. There's some docs somewhere on a german site that supposedly tell you the contents of Appendix H. The last time I looked, they included the clock multiplier control register, and that may be needed (unless it's an outside pin control -- guess it depends on the MB design). If it doesn't work at 66, you are guaranteed bad cache chips that can't go at 33, but if it works, you still can't tell the difference between overheating or having been sold a P75 with the printing changed. > At what speed is the cache driven ?? Same as CPU speed ? Or has > is the same base frequency as the oscillator (50,60,66 MHz) ??? > I think base*something (1.5,2.0,...). L2 cache should be aternal memory bus speed. Another reason to stay away from clock multiplied chips: L2 cache efficiency goes down expotentially. > The problem is, that a friend of mine has the problem, what to > give back to his distributor, we don't want to have much trouble > with his dealer .... > > Are there test programs available for the 2nd level cache .... > Perhaps souns silly since this is not the kind of memory, > one has directly access to ... But perhaps someone has a good > idea, how to find out precisely, what's damaged and > what not. Not very complex tests. Better tests would require hardware dependencies. 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 Fri Sep 29 11:54:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA27198 for hackers-outgoing; Fri, 29 Sep 1995 11:54:39 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA27191 for ; Fri, 29 Sep 1995 11:54:34 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id LAA08556 for ; Fri, 29 Sep 1995 11:54:30 -0700 To: hackers@freefall.FreeBSD.org Subject: A moment in the life of ftp.cdrom.com Date: Fri, 29 Sep 1995 11:54:30 -0700 Message-ID: <8554.812400870@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk As a periodic reminder of what FreeBSD is doing on ftp.cdrom.com, I thought I'd paste in the first page of the `top' listing I just ran now.. load averages: 21.41, 20.54, 18.44 11:44:00 499 processes: 20 running, 472 sleeping, 7 zombie Cpu states: % user, % nice, % system, % interrupt, % idle Memory: 71M Active, 25M Inact, 16M Wired, 2476K Cache, 180K Free Swap: 819M Total, 670M Free, 18% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 18896 root 85 0 684K 584K run 0:33 4.20% 4.20% compress 14212 root 86 0 568K 332K run 2:12 4.33% 4.16% gzip 1449 root 85 0 568K 332K run 6:51 4.16% 4.16% gzip 13231 root 85 0 568K 332K run 2:30 4.16% 4.16% gzip 8302 root 85 0 568K 328K run 2:21 3.74% 3.74% gzip 11383 root 2 0 98M 12M sleep 15:04 3.09% 3.09% perl 84 root 2 0 180K 136K sleep 318:39 2.71% 2.71% syslogd 17093 root 2 0 664K 320K sleep 0:16 1.94% 1.60% ftpd 99 root 2 0 232K 12K run 39:56 1.60% 1.60% nfsd 17553 www 2 0 436K 480K sleep 0:04 1.45% 1.45% httpd 20782 root 2 0 624K 232K sleep 0:00 0.99% 0.80% ftpd 18066 www 2 0 472K 504K sleep 0:05 0.72% 0.72% httpd 2316 root 89 4 728K 480K run 16:55 0.72% 0.72% compress 20850 root 2 0 616K 368K sleep 0:00 2.08% 0.69% ftpd 19913 www 2 0 412K 412K sleep 0:02 0.65% 0.65% httpd Whoa, momma! Check out the size of that PERL mirror job! :-) I realize that this is highly subjective data given that no two ftp servers are alike, but it's an interesting datapoint nonetheless and I thought that it might be of interest to those of you out there who are looking for comparison data. The machine remains more than reasonably interactive and I wouldn't be at all adverse to using it as a general user if I didn't have a perfectly good FreeBSD machine sitting next to my own desk. With 350 ftp users logged in along with 7 interactive users (one of whom appears to be running emacs :-), 31 active HTTP sessions and some 700K/sec streaming constantly out of its one ethernet interface (as checked with netstat), well, all I can say is: "This is a PC??!" :-) The irony is that if we could only fit more than 128MB of memory into this beast we could do even more.. I wonder if anyone from Intel is listening? Guys! We need a decent motherboard with room for more memory, please! please! :-) Jordan From owner-freebsd-hackers Fri Sep 29 12:20:00 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27852 for hackers-outgoing; Fri, 29 Sep 1995 12:20:00 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27847 for ; Fri, 29 Sep 1995 12:19:58 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id MAA00453; Fri, 29 Sep 1995 12:18:37 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id MAA00138; Fri, 29 Sep 1995 12:19:57 -0700 Message-Id: <199509291919.MAA00138@corbin.Root.COM> To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-reply-to: Your message of "Fri, 29 Sep 95 11:54:30 PDT." <8554.812400870@time.cdrom.com> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 29 Sep 1995 12:19:56 -0700 Sender: owner-hackers@FreeBSD.org Precedence: bulk >As a periodic reminder of what FreeBSD is doing on ftp.cdrom.com, I >thought I'd paste in the first page of the `top' listing I just ran >now.. ...and here's a sample of the past 10 minutes or so of traffic. Each line is one minute worth. ftp.cdrom.com pushed out 45GB yesterday (and that doesn't include http and other traffic, just the total bytes of the files read). This shows that the average is around 800K bytes/sec which considering the relatively small size of the packets, is very close to ethernet saturation (and ftp.cdrom.com isn't the only machine on this wire :-)). input (de0) output input (Total) output packets errs bytes packets errs bytes colls packets errs bytes packets errs bytes colls 60791 0 7784909 74938 0 38217601 34215 60791 0 7784909 74938 0 38217601 34215 59752 0 8104662 73676 0 38158329 31228 59752 0 8104662 73676 0 38158329 31228 49741 0 6397465 61071 0 31170543 18866 49741 0 6397465 61071 0 31170543 18866 53875 0 5002170 68560 0 35524265 23665 53875 0 5002170 68560 0 35524265 23665 55889 0 4222487 86575 0 45658253 33961 55889 0 4222487 86575 0 45658253 33961 61474 0 5433897 81258 0 42751029 34059 61474 0 5433897 81258 0 42751029 34059 59465 0 4862928 81396 0 42744354 34780 59465 0 4862928 81396 0 42744354 34780 57773 0 4566530 80428 0 42417423 32270 57773 0 4566530 80428 0 42417423 32270 58883 0 5048094 81654 0 42869163 33596 58883 0 5048094 81654 0 42869163 33596 58359 0 5090290 80509 0 42211636 34166 58359 0 5090290 80509 0 42211636 34166 55131 0 4263980 76909 0 40214196 27566 55131 0 4263980 76909 0 40214196 27566 59537 0 5480926 78669 0 41020682 30238 59537 0 5480926 78669 0 41020682 30238 58966 0 5450119 77844 0 40617802 30199 58966 0 5450119 77844 0 40617802 30199 57491 0 5167980 79373 0 41347721 30294 57491 0 5167980 79373 0 41347721 30294 58355 0 5035381 80891 0 42367813 31228 58355 0 5035381 80891 0 42367813 31228 -DG From owner-freebsd-hackers Fri Sep 29 12:22:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA27949 for hackers-outgoing; Fri, 29 Sep 1995 12:22:11 -0700 Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA27845 for ; Fri, 29 Sep 1995 12:19:56 -0700 Received: by crox.net.kiae.su id WAA00246; (8.6.11/vak/1.8a) Fri, 29 Sep 1995 22:13:58 +0300 To: jehamby@lightside.com Cc: hackers@freebsd.org References: Message-ID: Organization: Cronyx Ltd. Date: Fri, 29 Sep 95 22:13:58 +0300 X-Mailer: BML [UNIX Beauty Mail v.1.39] From: vak@cronyx.ru Subject: Re: [patch] wcd.c version 1.6 Sender: owner-hackers@freebsd.org Precedence: bulk Hi, > When I tried to apply the last three patches you've posted to my copy of > wcd 1.3, a couple of them were rejected. Can you repost the whole wcd > package to freefall.freebsd.org, please? Thanks! By the way, if these > patches have resolved whatever IDE hard drive probing problems existed, > what are the chances of getting them into FreeBSD-stable (i.e. 2.1.0)? I submitted the version 1.8a to ftp.freebsd.org:/FreeBSD/incoming/wcd18a.tgz. The probing problem seems to be solved in this version. Regards, Serge --- Serge Vakulenko Cronyx Ltd., Moscow Unix consulting and custom programming phone: +7 (095) 939-23-23 FreeBSD support fax: +7 (095) 939-03-00 Relcom network development From owner-freebsd-hackers Fri Sep 29 12:40:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA28557 for hackers-outgoing; Fri, 29 Sep 1995 12:40:59 -0700 Received: from kryten.atinc.com (kryten.Atinc.COM [198.138.38.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA28552 ; Fri, 29 Sep 1995 12:40:55 -0700 Received: (jmb@localhost) by kryten.atinc.com (8.6.9/8.3) id PAA04471; Fri, 29 Sep 1995 15:32:32 -0400 Date: Fri, 29 Sep 1995 15:32:31 -0400 (EDT) From: "Jonathan M. Bresler" Subject: Re: SYSCONS PROBLEM IDENTIFIED To: Terry Lambert cc: sos@FreeBSD.ORG, terry@lambert.org, ache@astral.msk.su, hackers@FreeBSD.ORG In-Reply-To: <199509291816.LAA15099@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk On Fri, 29 Sep 1995, Terry Lambert wrote: > > > A full SCO console emulation will include 10m, 11m, and 12m for character > > > set selection as well. > > > > Hmm, do you have a "machine readable" version of the latest SCO > > console specs ? Mine went away with our last 3.2.2 system > > here at work :( > > I'll see if I can find one. I certainly have SCO manuals; I guess I can > type one in if I have to. ackkk!!! if this information is available on a SCO 3.2.2 system. i can get it. give me the filename! Jonathan M. Bresler jmb@kryten.atinc.com | Analysis & Technology, Inc. FreeBSD Postmaster jmb@FreeBSD.Org | 2341 Jeff Davis Hwy play go. | Arlington, VA 22202 ride bike. hack FreeBSD.--ah the good life | 703-418-2800 x346 From owner-freebsd-hackers Fri Sep 29 12:49:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29063 for hackers-outgoing; Fri, 29 Sep 1995 12:49:42 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA29053 ; Fri, 29 Sep 1995 12:49:33 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA14369; Fri, 29 Sep 1995 20:49:15 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id UAA09684; Fri, 29 Sep 1995 20:49:12 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id UAA04787; Fri, 29 Sep 1995 20:11:39 +0100 From: J Wunsch Message-Id: <199509291911.UAA04787@uriah.heep.sax.de> Subject: Re: Questions on system calls To: humprey@linux1.dlsu.edu.ph Date: Fri, 29 Sep 1995 20:11:39 +0100 (MET) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers), freebsd-questions@freebsd.org, joerg_wunsch@uriah.heep.sax.de Reply-To: freebsd-questions@freebsd.org In-Reply-To: <199509290958.CAA08560@freefall.freebsd.org> from "owner-freebsd-hackers@freefall.freebsd.org" at Sep 29, 95 02:58:19 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1413 Sender: owner-hackers@freebsd.org Precedence: bulk As owner-freebsd-hackers@freefall.freebsd.org wrote: > > We're currently developing a software on FreeBSD platform, and generally, > we are not really familiar with system calls. We were hoping you'd take > time out to answer these questions. Thanks! > > 1. Are system calls preemptive? I'm not exactly sure what you're meaning here, but if you're asking whether the scheduler could switch processes while one is inside a system call -- yes! this is a basic principle on every Unix installation. > 2. How do we create additional system calls? What exactly would you need it for? It's normally not a good idea to do it. Of course, you've got the source, so you can do what you want, but it's not the recommended procedure. Perhaps you would better use an existing system call and hook up a new driver? > 3. Do we have to recompile the whole kernel if we create additional > system calls? Normally yes, but you can also build a "loadable kernel module" (LKM). Sample code for how to do this is under /usr/share/examples. Note that on FreeBSD 2.0.5, all Makefiles under this directory are missing, and the source files are not buildable out of the box. So you might wish to grab more recent example files, e.g. from ftp.cdrom.com under FreeBSD-current. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri Sep 29 12:54:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA29491 for hackers-outgoing; Fri, 29 Sep 1995 12:54:48 -0700 Received: from netcom22.netcom.com (bakul@netcom22.netcom.com [192.100.81.136]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA29486 for ; Fri, 29 Sep 1995 12:54:47 -0700 Received: from localhost by netcom22.netcom.com (8.6.12/Netcom) id MAA05143; Fri, 29 Sep 1995 12:54:29 -0700 Message-Id: <199509291954.MAA05143@netcom22.netcom.com> To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-reply-to: Your message of "Fri, 29 Sep 95 11:54:30 PDT." <8554.812400870@time.cdrom.com> Date: Fri, 29 Sep 95 12:54:26 -0700 From: Bakul Shah Sender: owner-hackers@FreeBSD.org Precedence: bulk > 18896 root 85 0 684K 584K run 0:33 4.20% 4.20% compress > 14212 root 86 0 568K 332K run 2:12 4.33% 4.16% gzip > 1449 root 85 0 568K 332K run 6:51 4.16% 4.16% gzip > 13231 root 85 0 568K 332K run 2:30 4.16% 4.16% gzip > 8302 root 85 0 568K 328K run 2:21 3.74% 3.74% gzip > 11383 root 2 0 98M 12M sleep 15:04 3.09% 3.09% perl > 84 root 2 0 180K 136K sleep 318:39 2.71% 2.71% syslogd Caching compressed/gzipped files for a while may be a win. It'd be interesting to know where majority of that 98M is going. Memory leak? profligate memory use? or just a huge amount of data? It is probably spending half its time paging. 318:39 for syslogd? Hmm... It'd also be interesting to know who waits for how long and why. Performance tuning can be an interesting and rewarding exercise! -- bakul From owner-freebsd-hackers Fri Sep 29 13:10:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00209 for hackers-outgoing; Fri, 29 Sep 1995 13:10:03 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00204 for ; Fri, 29 Sep 1995 13:09:56 -0700 Received: from exalt.x.org by expo.x.org id AA18560; Fri, 29 Sep 95 16:09:23 -0400 Received: from localhost by exalt.x.org id QAA29806; Fri, 29 Sep 1995 16:09:22 -0400 Message-Id: <199509292009.QAA29806@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: gildea@x.org Subject: /bin/sh thinks it's csh Date: Fri, 29 Sep 1995 16:09:21 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk Here's what happens on any else's box: % sh -c 'echo $1' foo bar baz bar % csh -c 'echo $1' foo bar baz foo Here's what happens on FreeBSD-2.1.0-950928-SNAP: % sh -c 'echo $1' foo bar baz foo % csh -c 'echo $1' foo bar baz foo POSIX.2 Section 4.56.3 says everyone else is right, and FreeBSD is ... not right. Perhaps this ought to be fixed before 2.1.0 goes golden??? There are existing scripts that this will cause to break. -- Kaleb KEITHLEY From owner-freebsd-hackers Fri Sep 29 13:11:43 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00341 for hackers-outgoing; Fri, 29 Sep 1995 13:11:43 -0700 Received: from mail.nyc.pipeline.com (root@mail.nyc.pipeline.com [198.80.32.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00327 for ; Fri, 29 Sep 1995 13:11:39 -0700 Received: from pipe6.nyc.pipeline.com (pipe6.nyc.pipeline.com [198.80.32.46]) by mail.nyc.pipeline.com (8.6.12/8.6.12) with ESMTP id QAA03528; Fri, 29 Sep 1995 16:11:43 -0400 Received: (axon@localhost) by pipe6.nyc.pipeline.com (8.6.10/8.6.9) id QAA28063; Fri, 29 Sep 1995 16:11:35 -0400 Date: Fri, 29 Sep 1995 16:11:25 -0400 (EDT) From: "Amir Y. Rosenblatt" To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-Reply-To: <8554.812400870@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Fri, 29 Sep 1995, Jordan K. Hubbard wrote: > As a periodic reminder of what FreeBSD is doing on ftp.cdrom.com, I > thought I'd paste in the first page of the `top' listing I just ran > now.. Wow. In evangelizing FreeBSD to the folks I woprk with (who just today announced their web site, which is running on a Sparc Classic), I forwarded this to them -- they were very impressed, needless to say. They want to know the config of the machine (RAM, how much diskspace, what kinda disks [i.e. regular scsi2, RAID5, etc), etc... Would it be possible to get some of this info? -Amir > > load averages: 21.41, 20.54, 18.44 11:44:00 > 499 processes: 20 running, 472 sleeping, 7 zombie > Cpu states: % user, % nice, % system, % interrupt, % idle > Memory: 71M Active, 25M Inact, 16M Wired, 2476K Cache, 180K Free > Swap: 819M Total, 670M Free, 18% Inuse > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 18896 root 85 0 684K 584K run 0:33 4.20% 4.20% compress > 14212 root 86 0 568K 332K run 2:12 4.33% 4.16% gzip > 1449 root 85 0 568K 332K run 6:51 4.16% 4.16% gzip > 13231 root 85 0 568K 332K run 2:30 4.16% 4.16% gzip > 8302 root 85 0 568K 328K run 2:21 3.74% 3.74% gzip > 11383 root 2 0 98M 12M sleep 15:04 3.09% 3.09% perl > 84 root 2 0 180K 136K sleep 318:39 2.71% 2.71% syslogd > 17093 root 2 0 664K 320K sleep 0:16 1.94% 1.60% ftpd > 99 root 2 0 232K 12K run 39:56 1.60% 1.60% nfsd > 17553 www 2 0 436K 480K sleep 0:04 1.45% 1.45% httpd > 20782 root 2 0 624K 232K sleep 0:00 0.99% 0.80% ftpd > 18066 www 2 0 472K 504K sleep 0:05 0.72% 0.72% httpd > 2316 root 89 4 728K 480K run 16:55 0.72% 0.72% compress > 20850 root 2 0 616K 368K sleep 0:00 2.08% 0.69% ftpd > 19913 www 2 0 412K 412K sleep 0:02 0.65% 0.65% httpd > > Whoa, momma! Check out the size of that PERL mirror job! :-) > > I realize that this is highly subjective data given that no two ftp > servers are alike, but it's an interesting datapoint nonetheless and I > thought that it might be of interest to those of you out there who are > looking for comparison data. > > The machine remains more than reasonably interactive and I wouldn't be > at all adverse to using it as a general user if I didn't have a > perfectly good FreeBSD machine sitting next to my own desk. With 350 > ftp users logged in along with 7 interactive users (one of whom > appears to be running emacs :-), 31 active HTTP sessions and some > 700K/sec streaming constantly out of its one ethernet interface (as > checked with netstat), well, all I can say is: "This is a PC??!" :-) > > The irony is that if we could only fit more than 128MB of memory into > this beast we could do even more.. I wonder if anyone from Intel is > listening? Guys! We need a decent motherboard with room for more > memory, please! please! :-) > > Jordan > /\ Set the controls for the heart of the sun. -Pink Floyd ______/ \ ___________ __ __ _ _ _ _ . . . amir@neuron.net \ / \/ For PGP 2.6 key send mail with subject: SEND PGPKEY From owner-freebsd-hackers Fri Sep 29 13:25:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01091 for hackers-outgoing; Fri, 29 Sep 1995 13:25:20 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01086 for ; Fri, 29 Sep 1995 13:25:15 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id NAA25078; Fri, 29 Sep 1995 13:24:42 -0700 Message-Id: <199509292024.NAA25078@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: Bakul Shah cc: "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-reply-to: Your message of "Fri, 29 Sep 1995 12:54:26 PDT." <199509291954.MAA05143@netcom22.netcom.com> Date: Fri, 29 Sep 1995 13:24:42 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org Precedence: bulk >It'd be interesting to know where majority of that 98M is >going. Memory leak? profligate memory use? or just a huge >amount of data? I have no idea. IMHO, Mirror should really be re-written in C, SUP does a similar job in 1/10th the space, and SUP is not very efficient. >It is probably spending half its time >paging. 318:39 for syslogd? Hmm... I think we need to reduce the amount of logging our wu-ftpd is doing. :) >It'd also be interesting to know who waits for how long and why. > >Performance tuning can be an interesting and rewarding exercise! > >-- bakul -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Fri Sep 29 13:29:03 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA01239 for hackers-outgoing; Fri, 29 Sep 1995 13:29:03 -0700 Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA01225 for ; Fri, 29 Sep 1995 13:28:46 -0700 Received: by gvr.win.tue.nl (8.6.10/1.53) id VAA01687; Fri, 29 Sep 1995 21:28:00 +0100 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199509292028.VAA01687@gvr.win.tue.nl> Subject: Re: A moment in the life of ftp.cdrom.com To: amir@neuron.net (Amir Y. Rosenblatt) Date: Fri, 29 Sep 1995 21:27:59 +0100 (MET) Cc: jkh@time.cdrom.com, hackers@freefall.freebsd.org In-Reply-To: from "Amir Y. Rosenblatt" at Sep 29, 95 04:11:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1433 Sender: owner-hackers@FreeBSD.org Precedence: bulk Amir Y. Rosenblatt wrote: > > On Fri, 29 Sep 1995, Jordan K. Hubbard wrote: > > > As a periodic reminder of what FreeBSD is doing on ftp.cdrom.com, I > > thought I'd paste in the first page of the `top' listing I just ran > > now.. > > Wow. In evangelizing FreeBSD to the folks I woprk with (who just today > announced their web site, which is running on a Sparc Classic), I > forwarded this to them -- they were very impressed, needless to say. > They want to know the config of the machine (RAM, how much diskspace, > what kinda disks [i.e. regular scsi2, RAID5, etc), etc... > > Would it be possible to get some of this info? > It can be found at ftp;//ftp.cdrom.com:config Since so many people ask us about the configuration of ftp.cdrom.com, here's the scoop: ftp.cdrom.com is an Intel architecture PC machine running the FreeBSD operating system. Its configuration is as follows: ASUS PCI/I-P54TP4 motherboard w/100Mhz Pentium, 512k cache 128MB of main memory (60nsec "wide" SIMMS). 3 Adaptec AHA-2940 SCSI controllers (PCI) 1 Compex ENET32 (DC21040 based) 32bit ethernet (PCI) 1 Generic VGA card 14 attached SCSI drives of various types, typically 2.7GB & 4.3GB. The machine is housed in a industrial rack mount chassis with one CPU cabinet and three disk drive cabinets. Average number of users logged in at any point in time seems to hover around 300, though it can peak as high as 350 during rush hour. From owner-freebsd-hackers Fri Sep 29 13:55:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA02262 for hackers-outgoing; Fri, 29 Sep 1995 13:55:39 -0700 Received: from Wit401402.student.utwente.nl (Wit401402.student.utwente.nl [130.89.236.162]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA02245 ; Fri, 29 Sep 1995 13:55:31 -0700 Received: (from alain@localhost) by Wit401402.student.utwente.nl (8.6.12/8.6.9) id VAA01000; Fri, 29 Sep 1995 21:55:26 +0100 Date: Fri, 29 Sep 1995 21:55:26 +0100 (MET) From: Alain Kalker Reply-To: A.C.P.M.Kalker@student.utwente.nl To: "Justin T. Gibbs" cc: Bakul Shah , "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-Reply-To: <199509292024.NAA25078@aslan.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Fri, 29 Sep 1995, Justin T. Gibbs wrote: > >It'd be interesting to know where majority of that 98M is > >going. Memory leak? profligate memory use? or just a huge > >amount of data? > > I have no idea. IMHO, Mirror should really be re-written in C, SUP > does a similar job in 1/10th the space, and SUP is not very efficient. > As far as I can remember it builds an array with the entire ls -lRAT listing in it... :-) --- Alain From owner-freebsd-hackers Fri Sep 29 14:03:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA02671 for hackers-outgoing; Fri, 29 Sep 1995 14:03:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA02656 ; Fri, 29 Sep 1995 14:03:53 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA15335; Fri, 29 Sep 1995 13:58:26 -0700 From: Terry Lambert Message-Id: <199509292058.NAA15335@phaeton.artisoft.com> Subject: Re: SYSCONS PROBLEM IDENTIFIED To: jmb@kryten.Atinc.COM (Jonathan M. Bresler) Date: Fri, 29 Sep 1995 13:58:26 -0700 (MST) Cc: terry@lambert.org, sos@FreeBSD.ORG, ache@astral.msk.su, hackers@FreeBSD.ORG In-Reply-To: from "Jonathan M. Bresler" at Sep 29, 95 03:32:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 686 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > Hmm, do you have a "machine readable" version of the latest SCO > > > console specs ? Mine went away with our last 3.2.2 system > > > here at work :( > > > > I'll see if I can find one. I certainly have SCO manuals; I guess I can > > type one in if I have to. > > ackkk!!! if this information is available on a SCO 3.2.2 system. > i can get it. give me the filename! If there is a machine readable version, I didn't get it from an SCO distribution, I got it elsewhere. My opinion is that a machine readable version does not exist. 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 Fri Sep 29 14:22:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03440 for hackers-outgoing; Fri, 29 Sep 1995 14:22:45 -0700 Received: from rocky.sri.MT.net (sri.MT.net [204.94.231.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03434 for ; Fri, 29 Sep 1995 14:22:41 -0700 Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id PAA25384; Fri, 29 Sep 1995 15:22:19 -0600 Date: Fri, 29 Sep 1995 15:22:19 -0600 From: Nate Williams Message-Id: <199509292122.PAA25384@rocky.sri.MT.net> To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: SYSCONS PROBLEM IDENTIFIED In-Reply-To: <199509292058.NAA15335@phaeton.artisoft.com> References: <199509292058.NAA15335@phaeton.artisoft.com> Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Terry Lambert writes: [ SCO console specs ] > My opinion is that a machine readable version does not exist. Unless the machine is a scanner. :) { Sorry, couldn't resist. I'm leaving work now since I'm no good for anything... } Nate From owner-freebsd-hackers Fri Sep 29 14:51:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA04542 for hackers-outgoing; Fri, 29 Sep 1995 14:51:02 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA04533 for ; Fri, 29 Sep 1995 14:50:54 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id WAA23329 ; Fri, 29 Sep 1995 22:50:35 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id WAA02664 ; Fri, 29 Sep 1995 22:50:33 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7/keltia-uucp-2.5.1) id WAA07716; Fri, 29 Sep 1995 22:42:53 +0100 (MET) From: Ollivier Robert Message-Id: <199509292142.WAA07716@keltia.freenix.fr> Subject: Re: -stable: tuucp1061: tproto, so fast ! To: andreas@knobel.gun.de (Andreas Klemm) Date: Fri, 29 Sep 1995 22:42:53 +0100 (MET) Cc: hackers@freebsd.org In-Reply-To: <199509282202.XAA04055@knobel.gun.de> from "Andreas Klemm" at Sep 28, 95 11:02:28 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1141 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that Andreas Klemm said: > Never saw such transmission speeds using uucp via ppp. 16550er UART, > Zyxel 1496EG+. Well done ! Maybe the quality of ppp increased, too. > Anyway ... good work ! The 'i' works well on TCP too. You get bidirectionnal transferts :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Mon Sep 25 02:02:31 MET 1995 From owner-freebsd-hackers Fri Sep 29 15:22:55 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05740 for hackers-outgoing; Fri, 29 Sep 1995 15:22:55 -0700 Received: from muse.microunity.com (muse1.microunity.com [192.216.206.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id PAA05730 for ; Fri, 29 Sep 1995 15:22:52 -0700 Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA06279; Fri, 29 Sep 95 15:22:15 PDT Received: from gallifrey (gallifrey.microunity.com) by gaea.microunity.com (4.1/muse1.3) id AA26222; Fri, 29 Sep 95 15:22:13 PDT Received: by gallifrey (931110.SGI.ANONFTP/muse-sgi.2) for @gaea.microunity.com:freebsd-hackers@freebsd.org id AA29660; Fri, 29 Sep 95 15:22:12 -0700 Date: Fri, 29 Sep 95 15:22:12 -0700 From: deborah@gallifrey.microunity.com (Deborah Gronke Bennett) Message-Id: <9509292222.AA29660@gallifrey> To: freebsd-hackers@freebsd.org Subject: spl'ing to a specific interrupt level Sender: owner-hackers@freebsd.org Precedence: bulk I'm writing a device driver for a device which is not a bio device, not a tty device and not a net device. Thus when I config the device I use none of these keywords, and my interrupt level is not added to any of the masks. What I want to know is how I can spl to my specific interrupt level around critical sections. I'm most recently familiar with SunOS, where I did something like this: saved_ipl = splx(spl_level_of_my_device); ... critical section here ... (void) splx(saved_ipl) The effect of this was to raise the interrupt level mask to the level of my device while I was in a critical section, and restore it to whatever it was before at the end. I've perused the FreeBSD 2.0.5 source tree, and all I can find is the splbio, spltty, etc macros defined with GENSPL in /include/spl.h, which are all for specific group classes. Am I forced to add myself of one of the bio, tty or net classes if I want to block interrupts during a critical section in this way? Or have I missed something? (Pointers to which source file to find this in are welcome). Thanks for your help, -deborah bennett ---------- Deborah Gronke Bennett (WD5HJH) kernel and device drivers engineer deborah@microunity.com (408)-734-8100 MicroUnity Systems Eng., 255 Caspian Drive, Sunnyvale, CA 94089-1015 USA I'm still looking to buy source code for the cscope program or the C programmer's toolchest containing it. UNIX is a trademark of whoever bought it this week . . . From owner-freebsd-hackers Fri Sep 29 15:31:22 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA05983 for hackers-outgoing; Fri, 29 Sep 1995 15:31:22 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA05977 for ; Fri, 29 Sep 1995 15:31:19 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA15486; Fri, 29 Sep 1995 15:26:49 -0700 From: Terry Lambert Message-Id: <199509292226.PAA15486@phaeton.artisoft.com> Subject: Re: spl'ing to a specific interrupt level To: deborah@gallifrey.microunity.com (Deborah Gronke Bennett) Date: Fri, 29 Sep 1995 15:26:49 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <9509292222.AA29660@gallifrey> from "Deborah Gronke Bennett" at Sep 29, 95 03:22:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 714 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > I'm writing a device driver for a device which is not a bio device, > not a tty device and not a net device. Thus when I config the device > I use none of these keywords, and my interrupt level is not added to > any of the masks. Uh... what kind of device is it, then? 8-). > I'm still looking to buy source code for the cscope program or > the C programmer's toolchest containing it. Available directly from AT&T, catalog on 'research.att.com'. $300 last time I looked. > UNIX is a trademark of whoever bought it this week . . . SCO, owned by Novell and Microsoft. 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 Fri Sep 29 16:52:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA07660 for hackers-outgoing; Fri, 29 Sep 1995 16:52:32 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA07654 for ; Fri, 29 Sep 1995 16:52:30 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA09425; Fri, 29 Sep 1995 16:51:43 -0700 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: luigi@labinfo.iet.unipi.it, nate@rocky.sri.MT.net, hackers@freebsd.org Subject: Re: Bulletins for 2.1.0-950922-SNAP: In-reply-to: Your message of "Fri, 29 Sep 1995 20:38:52 BST." <199509291938.UAA04997@uriah.heep.sax.de> Date: Fri, 29 Sep 1995 16:51:43 -0700 Message-ID: <9423.812418703@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > > The fixit floppy was reborn in a slightly different (but more powerful > > and flexible) mechanism with the last snapshot. Take a look at it! > > Did you put more on it? Last time i've built one, it missed several > essential things (a cut-down termcap, mt(8) come immediately to mind). Well, I added a little to it but more importantly, I fundamentally changed the way it works. There is now no kernel on the fixit floppy, leaving room for a LOT more stuff! Jordan From owner-freebsd-hackers Fri Sep 29 17:02:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07980 for hackers-outgoing; Fri, 29 Sep 1995 17:02:26 -0700 Received: (from jkh@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA07960 ; Fri, 29 Sep 1995 17:02:22 -0700 Date: Fri, 29 Sep 1995 17:02:22 -0700 From: "Jordan K. Hubbard" Message-Id: <199509300002.RAA07960@freefall.freebsd.org> To: announce Subject: 2.1.0-950928-SNAP now available for testing Cc: hackers Sender: owner-hackers@FreeBSD.org Precedence: bulk FreeBSD 2.1 (pre-release) 950928-SNAP is now available for testing on freefall.freebsd.org and ftp.cdrom.com: ftp://freefall.freebsd.org/pub/FreeBSD/2.1.0-950928-SNAP ftp://ftp.cdrom.com/pub/FreeBSD/2.1.0-950928-SNAP This fixes all currently open bugs from 950922-SNAP. Feedback on this snapshot to me, please. I do realize that loading these snaps is something of a chore for those of you kind enough to dedicate a machine to such testing, but this process is also vital to ensuring that the final release of 2.1 is as solid and bullet-proof as it is possible for us to make it, and for this you deserve the sincere thanks of FreeBSD users and developers everywhere! I've probably been somewhat remiss in saying so before, so I'll say it now: THANK YOU! Jordan From owner-freebsd-hackers Fri Sep 29 17:20:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09072 for hackers-outgoing; Fri, 29 Sep 1995 17:20:12 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09066 for ; Fri, 29 Sep 1995 17:20:09 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA09489; Fri, 29 Sep 1995 17:08:59 -0700 To: Bakul Shah cc: hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-reply-to: Your message of "Fri, 29 Sep 1995 12:54:26 PDT." <199509291954.MAA05143@netcom22.netcom.com> Date: Fri, 29 Sep 1995 17:08:59 -0700 Message-ID: <9487.812419739@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > It'd be interesting to know where majority of that 98M is > going. Memory leak? profligate memory use? or just a huge > amount of data? It is probably spending half its time > paging. 318:39 for syslogd? Hmm... Profligate memory use. The mirror scripts use Perl's associative arrays to suck in entire file trees from both systems and laboriously compare them. While perl's assoc arrays are no doubt quite powerful, their internal implementation is not very compact. The mirror stuff desperately needs to be re-written in carefully coded C. The first person to do so will undoubtedly be canonized by ftp adminstrators everywhere! :-) Jordan From owner-freebsd-hackers Fri Sep 29 17:33:13 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09351 for hackers-outgoing; Fri, 29 Sep 1995 17:33:13 -0700 Received: from schizo.cdsnet.net (mrcpu@schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09346 ; Fri, 29 Sep 1995 17:33:11 -0700 Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.9) id RAA23857; Fri, 29 Sep 1995 17:33:10 -0700 Date: Fri, 29 Sep 1995 17:33:10 -0700 (PDT) From: Jaye Mathisen To: "Jordan K. Hubbard" cc: hackers@freefall.freebsd.org Subject: Re: 2.1.0-950928-SNAP now available for testing In-Reply-To: <199509300002.RAA07960@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk What's the relationship between -stable, and a 9/28 snap? The same modulo changes in install utilities? From owner-freebsd-hackers Fri Sep 29 17:38:26 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA09460 for hackers-outgoing; Fri, 29 Sep 1995 17:38:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA09454 ; Fri, 29 Sep 1995 17:38:22 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id RAA09655; Fri, 29 Sep 1995 17:38:12 -0700 To: A.C.P.M.Kalker@student.utwente.nl cc: "Justin T. Gibbs" , Bakul Shah , hackers@freefall.freebsd.org Subject: Re: A moment in the life of ftp.cdrom.com In-reply-to: Your message of "Fri, 29 Sep 1995 21:55:26 BST." Date: Fri, 29 Sep 1995 17:38:12 -0700 Message-ID: <9652.812421492@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > As far as I can remember it builds an array with the entire ls -lRAT > listing in it... :-) *two* arrays! :-* Jordan From owner-freebsd-hackers Fri Sep 29 18:01:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10140 for hackers-outgoing; Fri, 29 Sep 1995 18:01:02 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA10134 ; Fri, 29 Sep 1995 18:00:59 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA09749; Fri, 29 Sep 1995 18:00:48 -0700 To: Jaye Mathisen cc: "Jordan K. Hubbard" , hackers@freefall.freebsd.org Subject: Re: 2.1.0-950928-SNAP now available for testing In-reply-to: Your message of "Fri, 29 Sep 1995 17:33:10 PDT." Date: Fri, 29 Sep 1995 18:00:48 -0700 Message-ID: <9747.812422848@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > What's the relationship between -stable, and a 9/28 snap? The same modulo > changes in install utilities? The snaps, until 2.1 is released, are snapshots of -stable. -stable is what will become 2.1 and anything following on the 2.1.x line. Jordan From owner-freebsd-hackers Fri Sep 29 18:10:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10382 for hackers-outgoing; Fri, 29 Sep 1995 18:10:06 -0700 Received: from muse.microunity.com (muse1.microunity.com [192.216.206.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA10376 for ; Fri, 29 Sep 1995 18:10:02 -0700 Received: from gaea.microunity.com by muse.microunity.com (4.1/ericm1.1) id AA09498; Fri, 29 Sep 95 18:09:10 PDT Received: from gallifrey (gallifrey.microunity.com) by gaea.microunity.com (4.1/muse1.3) id AA28270; Fri, 29 Sep 95 18:09:08 PDT Received: by gallifrey (931110.SGI.ANONFTP/muse-sgi.2) for @gaea.microunity.com:freebsd-hackers@freebsd.org id AA29818; Fri, 29 Sep 95 18:09:07 -0700 From: deborah@microunity.com (Deborah Gronke Bennett) Message-Id: <9509291809.ZM29816@gallifrey.microunity.com> Date: Fri, 29 Sep 1995 18:09:07 -0700 In-Reply-To: Terry Lambert "Re: spl'ing to a specific interrupt level" (Sep 29, 4:37pm) References: <199509292337.QAA15601@phaeton.artisoft.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Terry Lambert Subject: Re: spl'ing to a specific interrupt level Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-hackers@freebsd.org Precedence: bulk > > > > It's a programmed I/O device which is a bridge from the PC > > to a proprietary serial communications bus. It's kind of like > > a generic programmed port device, so we can use a program > > on the PC to write stuff onto this proprietary serial bus. > > If it gets an interrupt, it gets a priority level. > > > If I have to add it to an interrupt class, I suppose it's > > closest to a tty-style device (I notice that the lpt device > > uses tty). However, I am still wondering if there's any way > > to just block interrupts at my level and below, rather than > > block out everything which is on the ttytab list. > > I don't think I understand; you want to prioritize your driver below > the standard tty drivers? I don't think that's wise; I'd just use > spltty. > Here is what I understand about the FreeBSD interrupt system: (btw, my device is an isa device) from isa_configure, via config_isadev_c, my driver probe routine is called. If it succeeds, (id_alive is true) then some time later my attach routine is called. Just before register_intr is called to add my interrupt service routine to the proper level, INTRMASK is called to add my irq level to one of tty_imask, bio_imask, net_imask or SWI_CLOCK_MASK. (Which one depends on the keyword in my config line). My understanding of the splXXX routines is that you call them to block critical sections which could somehow depend on each other - that's why you have the classes of bio (disk devices), net (network) and tty (serial devices). My quandry is that I don't want to block anything else I don't need to - I just want a routine to call to raise the spl level to my level (whatever I put after the "irq" on my config line). Is my only solution in this case to call splsoftclock? So, to answer your question, what I want to do is not to prioritize my device with respect to any other device - I just want a way to block my critical sections. Am I making this any clearer now? -deborah bennett From owner-freebsd-hackers Fri Sep 29 18:26:12 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10630 for hackers-outgoing; Fri, 29 Sep 1995 18:26:12 -0700 Received: from icicle (root@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA10625 for ; Fri, 29 Sep 1995 18:26:10 -0700 Received: from subzero (glen@subzero.winternet.com [198.174.169.6]) by icicle (8.6.12/8.6.12) with ESMTP id UAA02587; Fri, 29 Sep 1995 20:25:54 -0500 Received: (from glen@localhost) by subzero (8.6.12/8.6.12) id UAA13977; Fri, 29 Sep 1995 20:25:53 -0500 Date: Fri, 29 Sep 1995 20:25:53 -0500 From: Glen Overby Posted-Date: Fri, 29 Sep 1995 20:25:53 -0500 Message-Id: <199509300125.UAA13977@subzero> To: jkh@time.cdrom.com Subject: Re: 2.1.0-950928-SNAP now available for testing Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan wrote: > The snaps, until 2.1 is released, are snapshots of -stable. -stable > is what will become 2.1 and anything following on the 2.1.x line. and the process of going from -current to -stable is... ?? (if this is written somewhere, just tell me where ;-) Non Boot Report: 16mhz 386sx (Megatronics MB), 4MB RAM, Adaptec 1542CF + Maxtor + Seagate, cheapo Trident VGA, 3Com Elite16C try 1: system reset a while after uncompress message. try 2: boots, probes, panics: rootfs is 1075Kbyte compiled in MFS /stand/sysinstall running as init panic: kmem_malloc: kmem_map too small *SIGH* The last SNAP runs OK after I manually untared it on top of my old system. Glen From owner-freebsd-hackers Fri Sep 29 18:41:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA10951 for hackers-outgoing; Fri, 29 Sep 1995 18:41:07 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA10936 for ; Fri, 29 Sep 1995 18:41:02 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA09880; Fri, 29 Sep 1995 18:40:39 -0700 To: Glen Overby cc: hackers@freefall.freebsd.org Subject: Re: 2.1.0-950928-SNAP now available for testing In-reply-to: Your message of "Fri, 29 Sep 1995 20:25:53 CDT." <199509300125.UAA13977@subzero> Date: Fri, 29 Sep 1995 18:40:39 -0700 Message-ID: <9878.812425239@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk Damn. Looks like taking the SYSV* options out of the boot kernel didn't make it small enough. Time to look at this again. Thanks for the bug report! Jordan > Jordan wrote: > > The snaps, until 2.1 is released, are snapshots of -stable. -stable > > is what will become 2.1 and anything following on the 2.1.x line. > > and the process of going from -current to -stable is... ?? > (if this is written somewhere, just tell me where ;-) > > > Non Boot Report: 16mhz 386sx (Megatronics MB), 4MB RAM, Adaptec 1542CF + > Maxtor + Seagate, cheapo Trident VGA, 3Com Elite16C > > try 1: system reset a while after uncompress message. > try 2: boots, probes, panics: > > rootfs is 1075Kbyte compiled in MFS > /stand/sysinstall running as init > panic: kmem_malloc: kmem_map too small > > *SIGH* > > The last SNAP runs OK after I manually untared it on top of my old system. > > Glen From owner-freebsd-hackers Fri Sep 29 19:05:58 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA12762 for hackers-outgoing; Fri, 29 Sep 1995 19:05:58 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA12753 for ; Fri, 29 Sep 1995 19:05:54 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA15937; Fri, 29 Sep 1995 19:01:17 -0700 From: Terry Lambert Message-Id: <199509300201.TAA15937@phaeton.artisoft.com> Subject: Re: spl'ing to a specific interrupt level To: deborah@microunity.com (Deborah Gronke Bennett) Date: Fri, 29 Sep 1995 19:01:17 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <9509291809.ZM29816@gallifrey.microunity.com> from "Deborah Gronke Bennett" at Sep 29, 95 06:09:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3472 Sender: owner-hackers@freebsd.org Precedence: bulk > Here is what I understand about the FreeBSD interrupt system: > (btw, my device is an isa device) > from isa_configure, via config_isadev_c, my driver probe routine is called. > If it succeeds, (id_alive is true) then some time later my attach routine > is called. Just before register_intr is called to add my interrupt > service routine to the proper level, INTRMASK is called to add my > irq level to one of tty_imask, bio_imask, net_imask or SWI_CLOCK_MASK. > (Which one depends on the keyword in my config line). > > My understanding of the splXXX routines is that you call them to block > critical sections which could somehow depend on each other - that's > why you have the classes of bio (disk devices), net (network) > and tty (serial devices). My quandry is that I don't want to block > anything else I don't need to - I just want a routine to call > to raise the spl level to my level (whatever I put after the "irq" > on my config line). Is my only solution in this case to call splsoftclock? OK, you're saying that your serail board driver code takes an interrupt, but you are not going to provide tty (cannonical processing) device entry points for it, you're writing everything from scratch, including all behaviours. If this is the case, you will either need to take the collision with one of the existing classes (relatively easy) or add another class (relatively hard, from a cursory look at the code). The block is there to prevent reentrance of the support routines called at interrupt level that aren't reentrant on another interrupt. If you are planning on using the tty cannonical processing, you will probably need to add in arbitration for the device. This will also include using the calling unit abstraction. I suppose it's possible that the serial device won't be used for tty I/O or net I/O. If not, you'll need to pick something close or add a class. My last choice would be to add a class. If I were to do that, my first impulse would be to generalize the adding of classes and modify the current class-using mechanisms to use the more general routine as well (potentially a lot of work). > So, to answer your question, what I want to do is not to prioritize > my device with respect to any other device - I just want a way > to block my critical sections. > > Am I making this any clearer now? Yes. I assume you can critical code your own sections, so the problem you face is that without a class, you don't get an interrupt and you don't like the existing classes because of the concurrency penalty for what will essentially be unshared code. The "correct" answer is "make a class". The expidient answer, as above, is to overload one of the existing classes. If you don't expect to be doing serial I/O except through the board, I'd think overloading the tty would be an acceptable thing. If the serial board is sensitive to other people blocking it, and you will be running X or some other control/monitoring system, then you should still be safe with tty, if you make sure to use a bus or PS/2 mouse (and deconfigure the serial ports to make sure). Otherwise, it's off to add a class. 8-(. David Greenman and several others have written multiport serial board drivers and would be a good source of information if they'll let you pick their brains. Good luck on the project. 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 Fri Sep 29 20:04:21 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA14996 for hackers-outgoing; Fri, 29 Sep 1995 20:04:21 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA14988 for ; Fri, 29 Sep 1995 20:04:18 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id UAA17894; Fri, 29 Sep 1995 20:03:41 -0700 From: Julian Elischer Message-Id: <199509300303.UAA17894@ref.tfs.com> Subject: Re: spl'ing to a specific interrupt level To: deborah@microunity.com (Deborah Gronke Bennett) Date: Fri, 29 Sep 1995 20:03:41 -0700 (PDT) Cc: terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <9509291809.ZM29816@gallifrey.microunity.com> from "Deborah Gronke Bennett" at Sep 29, 95 06:09:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2490 Sender: owner-hackers@freebsd.org Precedence: bulk you've hit on one of the things I don't like about the present system.. it's hard to ad a new 'class' which is what you want to do.. (needs changes in autoconf, and even in config itself) the joke is, that if you have config'd slip, the tty and net masks get Or'd anyway so effectively we only have 2 masks :( go for tty for now and as we fiddle with the kernel you can use something else when it's easier :) > > > > > > > > It's a programmed I/O device which is a bridge from the PC > > > to a proprietary serial communications bus. It's kind of like > > > a generic programmed port device, so we can use a program > > > on the PC to write stuff onto this proprietary serial bus. > > > > If it gets an interrupt, it gets a priority level. > > > > > If I have to add it to an interrupt class, I suppose it's > > > closest to a tty-style device (I notice that the lpt device > > > uses tty). However, I am still wondering if there's any way > > > to just block interrupts at my level and below, rather than > > > block out everything which is on the ttytab list. > > > > I don't think I understand; you want to prioritize your driver below > > the standard tty drivers? I don't think that's wise; I'd just use > > spltty. > > > > Here is what I understand about the FreeBSD interrupt system: > (btw, my device is an isa device) > from isa_configure, via config_isadev_c, my driver probe routine is called. > If it succeeds, (id_alive is true) then some time later my attach routine > is called. Just before register_intr is called to add my interrupt > service routine to the proper level, INTRMASK is called to add my > irq level to one of tty_imask, bio_imask, net_imask or SWI_CLOCK_MASK. > (Which one depends on the keyword in my config line). > > My understanding of the splXXX routines is that you call them to block > critical sections which could somehow depend on each other - that's > why you have the classes of bio (disk devices), net (network) > and tty (serial devices). My quandry is that I don't want to block > anything else I don't need to - I just want a routine to call > to raise the spl level to my level (whatever I put after the "irq" > on my config line). Is my only solution in this case to call splsoftclock? > > So, to answer your question, what I want to do is not to prioritize > my device with respect to any other device - I just want a way > to block my critical sections. > > Am I making this any clearer now? > > -deborah bennett > > > > > From owner-freebsd-hackers Fri Sep 29 21:06:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA16162 for hackers-outgoing; Fri, 29 Sep 1995 21:06:45 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA16157 for ; Fri, 29 Sep 1995 21:06:42 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id OAA01183; Sat, 30 Sep 1995 14:06:21 +1000 From: michael butler Message-Id: <199509300406.OAA01183@asstdc.scgt.oz.au> Subject: Re: A moment in the life of ftp.cdrom.com To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 30 Sep 1995 14:06:20 +1000 (EST) Cc: hackers@freefall.freebsd.org In-Reply-To: <8554.812400870@time.cdrom.com> from "Jordan K. Hubbard" at Sep 29, 95 11:54:30 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 452 Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > As a periodic reminder of what FreeBSD is doing on ftp.cdrom.com, I > thought I'd paste in the first page of the `top' listing I just ran > now.. [ .. ] > Whoa, momma! Check out the size of that PERL mirror job! :-) There is a very substantial memory leak in mirror .. the author sent me replacement ftp.pl and chat.pl modules (~12 months ago) but I suspect that they are still not a part of any release :-( michael From owner-freebsd-hackers Fri Sep 29 23:26:44 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA18733 for hackers-outgoing; Fri, 29 Sep 1995 23:26:44 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA18728 for ; Fri, 29 Sep 1995 23:26:40 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id XAA13355; Fri, 29 Sep 1995 23:26:35 -0700 To: hackers@freefall.FreeBSD.org cc: jdc@crab.xinside.com, info@conetic.com Reply-to: jkh@freebsd.org Subject: Calling all commercial software demo folks! Deadlines approach. Date: Fri, 29 Sep 1995 23:26:34 -0700 Message-ID: <13353.812442394@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk Barring any unforseen delays, the FreeBSD 2.1 release will be burned onto CDROM and released simultaneously onto the net on Sunday, the 8th of October. If you would like to see a commercial demo of some sort make it onto the CD, then the time to submit it is ASAP! "Commercial" in this instance is defined any as software for sale, shareware, or a limited functionality/time-bombed demo. All submissions should be accompanied by whatever advertising or promotional information you would like distributed with the product. If your product has a fancy installation script, please include that as well. Thank you! Jordan From owner-freebsd-hackers Sat Sep 30 00:02:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19314 for hackers-outgoing; Sat, 30 Sep 1995 00:02:05 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19309 for ; Sat, 30 Sep 1995 00:02:01 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA15230 for ; Sat, 30 Sep 1995 00:01:57 -0700 To: hackers@freefall.FreeBSD.org Subject: FreeBSD 2.1 will require a minimum of 8MB for installation. Date: Sat, 30 Sep 1995 00:01:57 -0700 Message-ID: <15228.812444517@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk Well folks, we've hit that wall we all knew was there and heading for us at 120Mph.. The GENERIC kernel has simply gotten too big to fit within 4MB now and no amount of paring back will deny a basic fact of life: To fit in all the drivers we need to cover a reasonable set of devices required at installation-time, we need more than 4MB and if we didn't need it today, we'd need it tomorrow. Now some of you will immediately go "ARGH! What about my custom router! What about my 4MB laptop!" and I know how you feel, so please don't write me 5 page impassioned letters in defense of the last of the 4MB users. If it were easy for us to continue to support 4MB installs you may rest assured that we *would*, and we have in fact worked very hard up to now to continue doing so for as long as it was humanly possible. But we all also knew that we couldn't keep doing it forever and that *someday* we'd face this decision. It looks like someday just got here! :-( It's not like there isn't precedent. Even Windows '95, so pointedly an OS for the masses, apparently will no longer even run in less than 8MB. We, at least, aren't saying *that*. It's still perfectly possible to generate a custom, stripped-down kernel that'll run on a 4MB box (though not very fast), you'll just have to lay your hands on an extra 4MB to get it through the installation. I'm sorry about this, and if I could have forstalled this event even longer without crippling or excessively complicating the installation for others (and myself) you may rest assured that I'd have done so. I'm no masochist, and I certainly was never looking forward to the prospect of having groups of 4MB users throw tomatoes at me for this kind of decision. Sometimes that's just life. Just FYI.. You can at least say I warned you.. :( Jordan From owner-freebsd-hackers Sat Sep 30 00:08:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA19524 for hackers-outgoing; Sat, 30 Sep 1995 00:08:19 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA19519 for ; Sat, 30 Sep 1995 00:08:12 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id JAA17203 for ; Sat, 30 Sep 1995 09:07:57 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id JAA21165 for ; Sat, 30 Sep 1995 09:07:55 +0200 Message-Id: <199509300707.JAA21165@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: hackers@freebsd.org Subject: Netscape security problem - /dev/random? Date: Sat, 30 Sep 1995 09:07:54 +0200 From: Mark Murray Sender: owner-hackers@freebsd.org Precedence: bulk Hi With the well-publicised crack of Netscape's security, I am of the opinion that the system (in fact the kernel) should cooperate in providing decent random numbers. In this particular case, "decent" could mean a couple of things - - Unguessable. In tthe past folks used to seed their random number generators with the time-of-day to get a different start to the otherwise predidicable sequence. For security purposes this is no good, as an attacker who knows approximately whn you started, has a small set of numbers to play with to crack you. If the kernel could provide a toutally unpredictable value, this would protect the random generator seed. - Uniform. the above is assuming that each caller is only looking for a very small number of values. Such values may be useless if the caller actually needs a large number of uniformly distributed, totally random numbers. These two scenarios are addressed in a pice of code that I have that was written for Linux by Theodore Ts'o, and it provides 2 new devices - /dev/random and /dev/urandom which address these concerns. Those folks interested in exponential key exchange (Diffie-Hellman) and other crypto concerns will be interested. I would like to get this code into the kernel (in a few days). Is anyone else interested? M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-hackers Sat Sep 30 00:25:23 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA20205 for hackers-outgoing; Sat, 30 Sep 1995 00:25:23 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA20197 for ; Sat, 30 Sep 1995 00:25:19 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25571; Sat, 30 Sep 1995 08:25:15 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA16241; Sat, 30 Sep 1995 08:25:15 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id HAA13824; Sat, 30 Sep 1995 07:55:30 +0100 From: J Wunsch Message-Id: <199509300655.HAA13824@uriah.heep.sax.de> Subject: Re: -stable: tuucp1061: tproto, so fast ! To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sat, 30 Sep 1995 07:55:28 +0100 (MET) Cc: andreas@knobel.gun.de, hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199509292142.WAA07716@keltia.freenix.fr> from "Ollivier Robert" at Sep 29, 95 10:42:53 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 430 Sender: owner-hackers@freebsd.org Precedence: bulk As Ollivier Robert wrote: > > The 'i' works well on TCP too. You get bidirectionnal transferts :-) Watch out, i've experienced SIGFPE's when transfering large files simultaneously in both directions. I've reported it to the Taylor UUCP list, so i thinks it's on the way to be fixed. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 30 00:25:31 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA20232 for hackers-outgoing; Sat, 30 Sep 1995 00:25:31 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA20200 for ; Sat, 30 Sep 1995 00:25:19 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25575; Sat, 30 Sep 1995 08:25:17 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA16242; Sat, 30 Sep 1995 08:25:16 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA13893; Sat, 30 Sep 1995 08:02:28 +0100 From: J Wunsch Message-Id: <199509300702.IAA13893@uriah.heep.sax.de> Subject: Re: Bulletins for 2.1.0-950922-SNAP: To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 30 Sep 1995 08:02:27 +0100 (MET) Cc: hackers@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9423.812418703@time.cdrom.com> from "Jordan K. Hubbard" at Sep 29, 95 04:51:43 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 633 Sender: owner-hackers@freebsd.org Precedence: bulk As Jordan K. Hubbard wrote: > (fixit.flp) > > Did you put more on it? Last time i've built one, it missed several > > essential things (a cut-down termcap, mt(8) come immediately to mind). > > Well, I added a little to it but more importantly, I fundamentally changed > the way it works. There is now no kernel on the fixit floppy, leaving > room for a LOT more stuff! I noticed this. I think i gonna rebuild a snap next week. (That's easier for me than ftp'ing the official one.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 30 00:31:02 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA20417 for hackers-outgoing; Sat, 30 Sep 1995 00:31:02 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA20408 for ; Sat, 30 Sep 1995 00:30:59 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25654 for ; Sat, 30 Sep 1995 08:30:56 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA16280 for hackers@freefall.freebsd.org; Sat, 30 Sep 1995 08:30:56 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA14138 for hackers@freefall.freebsd.org; Sat, 30 Sep 1995 08:28:46 +0100 From: J Wunsch Message-Id: <199509300728.IAA14138@uriah.heep.sax.de> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: hackers@freefall.freebsd.org Date: Sat, 30 Sep 1995 08:28:46 +0100 (MET) Reply-To: hackers@freefall.freebsd.org In-Reply-To: <15228.812444517@time.cdrom.com> from "Jordan K. Hubbard" at Sep 30, 95 00:01:57 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 658 Sender: owner-hackers@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > To fit in all the drivers we need to cover a reasonable set > of devices required at installation-time, we need more than > 4MB and if we didn't need it today, we'd need it tomorrow. But why doubling it instead of successively increasing? My notebook has 5 MB, and the last private 2.1-snap installed fine. (Don't assume there ain't wierd memory sizes, 4 MB is 4x256K + 4x1M; i've got another box with 6 MB around. 8 MB is not necessarily the next logical step above 4 MB.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat Sep 30 01:15:45 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id BAA21896 for hackers-outgoing; Sat, 30 Sep 1995 01:15:45 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id BAA21891 for ; Sat, 30 Sep 1995 01:15:42 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id BAA18393; Sat, 30 Sep 1995 01:15:22 -0700 From: Julian Elischer Message-Id: <199509300815.BAA18393@ref.tfs.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 30 Sep 1995 01:15:21 -0700 (PDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <15228.812444517@time.cdrom.com> from "Jordan K. Hubbard" at Sep 30, 95 00:01:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2349 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Well folks, we've hit that wall we all knew was there and heading for > us at 120Mph.. The GENERIC kernel has simply gotten too big to fit > within 4MB now and no amount of paring back will deny a basic fact of > life: > > To fit in all the drivers we need to cover a reasonable set > of devices required at installation-time, we need more than > 4MB and if we didn't need it today, we'd need it tomorrow. > > Now some of you will immediately go "ARGH! What about my custom > router! What about my 4MB laptop!" and I know how you feel, so please > don't write me 5 page impassioned letters in defense of the last of > the 4MB users. If it were easy for us to continue to support 4MB > installs you may rest assured that we *would*, and we have in fact > worked very hard up to now to continue doing so for as long as it was > humanly possible. But we all also knew that we couldn't keep doing it > forever and that *someday* we'd face this decision. It looks like > someday just got here! :-( > > It's not like there isn't precedent. Even Windows '95, so pointedly > an OS for the masses, apparently will no longer even run in less than > 8MB. We, at least, aren't saying *that*. It's still perfectly > possible to generate a custom, stripped-down kernel that'll run on a > 4MB box (though not very fast), you'll just have to lay your hands on > an extra 4MB to get it through the installation. > > I'm sorry about this, and if I could have forstalled this event even > longer without crippling or excessively complicating the installation > for others (and myself) you may rest assured that I'd have done so. > I'm no masochist, and I certainly was never looking forward to the > prospect of having groups of 4MB users throw tomatoes at me for this > kind of decision. Sometimes that's just life. > > Just FYI.. You can at least say I warned you.. :( > Jordan. for the cdrom there should be an instal floppy with NO NETWORKING THAT would make it smaller.. i.e. has CDroms and disk support for all known devices but no networking at all.. that waythey can at least install fromthe cdrom and make a kernel that suits them.. you've certainly got enough room on the cdrom for 1 extra floppy image.. I think this is REALLY IMPORTANT If you don't, the linux crew are going to have a field day over this one! > Jordan > From owner-freebsd-hackers Sat Sep 30 02:37:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA24016 for hackers-outgoing; Sat, 30 Sep 1995 02:37:09 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA24007 for ; Sat, 30 Sep 1995 02:37:06 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id CAA18581 for hackers@freebsd.org; Sat, 30 Sep 1995 02:36:52 -0700 From: Julian Elischer Message-Id: <199509300936.CAA18581@ref.tfs.com> Subject: correctness of isa.c To: hackers@freebsd.org Date: Sat, 30 Sep 1995 02:36:51 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1673 Sender: owner-hackers@freebsd.org Precedence: bulk in isa_device.h, in struct isa_device{} one field , is defined as: caddr_t id_maddr; /* physical i/o memory address on bus (if any)*/ ok so this is the Physical address of ram on the device.. so why does isa.c pass it into the device as: if (!reconfig && isdp->id_maddr) { isdp->id_maddr -= 0xa0000; /* XXX should be a define */ isdp->id_maddr += atdevbase; which is the kvm mapped address of it.. BUT ONLY IF THE DEVICE IS in the 640K-1MB hole! I have a device at 2GB needless to say, I need to 'undo' this mess when I'm probed, to find my original address.. sure it's a nice idea to do it in one place, but it doesn't cover all bases.. then to add insult to injury: further down.. we see. if (isdp->id_maddr) printf(" maddr 0x%lx", kvtop(isdp->id_maddr)); where the field is Assumed to hold a kernel virtual address.. naturally, 2GB+addevbase-0xa0000 gives a rather strange answer.. and what if I didn't want to map that memory all at once, but use it page by page? I'd have to zero this field, but then I wouldn't get a message about it.. grrrrr If I were to 'fix' this for all our drivers, does anyone here see a really important reason for this field to hold physical and virtual addresses at different times? I have a pass over all drivers coming up to add devfs stuff.. I could add this to the list of things to fix.. not that many drivers have shared memory, and with frame buffers mapped into high memory becoing more common, this kludge should go.. (also while we're about it, why is id_irq a bitfield? it's almost believable, but is there a really good reason?) julian From owner-freebsd-hackers Sat Sep 30 03:42:19 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA25458 for hackers-outgoing; Sat, 30 Sep 1995 03:42:19 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA25449 for ; Sat, 30 Sep 1995 03:42:09 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA20453; Sat, 30 Sep 1995 11:47:08 +0100 From: Luigi Rizzo Message-Id: <199509301047.LAA20453@labinfo.iet.unipi.it> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: julian@ref.tfs.com (Julian Elischer) Date: Sat, 30 Sep 1995 11:47:08 +0100 (MET) Cc: jkh@time.cdrom.com, hackers@freefall.freebsd.org In-Reply-To: <199509300815.BAA18393@ref.tfs.com> from "Julian Elischer" at Sep 30, 95 01:15:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1670 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > It's not like there isn't precedent. Even Windows '95, so pointedly > > an OS for the masses, apparently will no longer even run in less than > > 8MB. We, at least, aren't saying *that*. It's still perfectly > > possible to generate a custom, stripped-down kernel that'll run on a > > 4MB box (though not very fast), you'll just have to lay your hands on > > an extra 4MB to get it through the installation. For some machines (e.g. laptops) it is too expensive to add memory, often they use special modules or just don't have the slots. I think we can manage by making it not too hard for 4MB users to build their own boot floppy (on a guest system, if it cannot be supplied as default). > Jordan. > for the cdrom there should be an instal floppy with NO NETWORKING I believe the networking code is fundamental -- all system have a network port, the serial port! And you can probably save much more space by removing the SCSI stuff. I think most portables and other small, old systems have IDE disks. If a separate floppy must exist (on the CDROM), I would not sacrifice the networking code. > I think this is REALLY IMPORTANT > If you don't, > the linux crew are going to have a field day over this one! Agreed. I am more worried about the users we loose. 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 Sat Sep 30 03:59:17 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA25700 for hackers-outgoing; Sat, 30 Sep 1995 03:59:17 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA25695 for ; Sat, 30 Sep 1995 03:59:13 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA02108; Sat, 30 Sep 1995 03:57:52 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id DAA01827; Sat, 30 Sep 1995 03:59:08 -0700 Message-Id: <199509301059.DAA01827@corbin.Root.COM> To: Julian Elischer cc: hackers@freebsd.org Subject: Re: correctness of isa.c In-reply-to: Your message of "Sat, 30 Sep 95 02:36:51 PDT." <199509300936.CAA18581@ref.tfs.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 30 Sep 1995 03:59:07 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >grrrrr > >If I were to 'fix' this for all our drivers, >does anyone here see a really important reason for this field >to hold physical and virtual addresses at different times? >I have a pass over all drivers coming up to add devfs stuff.. >I could add this to the list of things to fix.. >not that many drivers have shared memory, and with frame buffers mapped >into high memory becoing more common, this kludge should go.. >(also while we're about it, why is id_irq a bitfield? >it's almost believable, but is there a really good reason?) Yes, you're right, it's quite ugly. I started out trying to 'fix' this about 5 months ago, but then got sidetracked with the 2.0.5/2.1 release stuff. The way that I envision this, the 1MB physical memory mapping that starts at KERNBASE should completely go away, and each driver should allocate it's own kernel VA using pmap_mapdev() and then use that to talk to the shared memory. This makes the scheme completely flexible and allows you to map cards that are in unusual physical memory areas (like the 15-16MB range). The only thing I haven't yet figured out is what to do with the console drivers; these need a kernel VA before the VM system is initialized, so you pretty much have to kludge up something, at least temporarily during the early startup. -DG From owner-freebsd-hackers Sat Sep 30 04:06:30 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA26019 for hackers-outgoing; Sat, 30 Sep 1995 04:06:30 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA26010 for ; Sat, 30 Sep 1995 04:06:19 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA31420; Sat, 30 Sep 1995 21:04:14 +1000 Date: Sat, 30 Sep 1995 21:04:14 +1000 From: Bruce Evans Message-Id: <199509301104.VAA31420@godzilla.zeta.org.au> To: jkh@time.cdrom.com, julian@ref.tfs.com Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Well folks, we've hit that wall we all knew was there and heading for >> us at 120Mph.. The GENERIC kernel has simply gotten too big to fit >> within 4MB now and no amount of paring back will deny a basic fact of >> life: >> >> To fit in all the drivers we need to cover a reasonable set >> of devices required at installation-time, we need more than >> 4MB and if we didn't need it today, we'd need it tomorrow. >> >> Now some of you will immediately go "ARGH! What about my custom >> router! What about my 4MB laptop!" and I know how you feel, so please ARGH! What about my quality control principles :-). >> don't write me 5 page impassioned letters in defense of the last of >> the 4MB users. If it were easy for us to continue to support 4MB >> installs you may rest assured that we *would*, and we have in fact >> worked very hard up to now to continue doing so for as long as it was >> humanly possible. But we all also knew that we couldn't keep doing it It's not easy, but we have barely tried to keep the kernel small. I knew of the following bloat: 1) The gzipped installation kernel. Saves space on install disks, wastes space in the running kernel. 2) Using mfs to get a temporary file system for the installation kernel. 3) 32K allocated for DMA bounce buffers, 512 bytes used. 4) 1K allocated for kernelname[], normally 8 bytes used. and a few minutes with `nm -n /kernel | less' showed the following 5) 32K statically allocated normally-unused nfs log buffer `nfsdrt'. 6) 5.5K statically allocated normally-unused nfs log buffer `nfsrtt'. 7) 48K statically allocated normally-unused matcd table `matcd_data' (enough for 16 drives!). 8) 3.5K of `struct tty's for ptys. 9) 3K statically allocated normally-unused mcd table `mcd_data' (only enough for 2 drives :-). 10) 4K statically allocated table `iso_ihead' for cd9660. 11) 4K statically allocated table `sl_softc' for slip. 12) numerous statically allocated tables in the 512 byte to 2K range. >> 8MB. We, at least, aren't saying *that*. It's still perfectly >> possible to generate a custom, stripped-down kernel that'll run on a >> 4MB box (though not very fast), you'll just have to lay your hands on >> an extra 4MB to get it through the installation. Not long ago we aimed at running stripped kernels (not very fast) in 2MB. >Jordan. >for the cdrom there should be an instal floppy with NO NETWORKING >THAT would make it smaller.. >i.e. has CDroms and disk support for all known devices >but no networking at all.. >that waythey can at least install fromthe cdrom >and make a kernel that suits them.. > you've certainly got enough room on the cdrom for 1 extra floppy image.. I think that goes too far. Perhaps nfs could be left out, saving 200K. Bruce From owner-freebsd-hackers Sat Sep 30 04:31:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA28183 for hackers-outgoing; Sat, 30 Sep 1995 04:31:59 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA28170 for ; Sat, 30 Sep 1995 04:31:42 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA32657; Sat, 30 Sep 1995 21:30:38 +1000 Date: Sat, 30 Sep 1995 21:30:38 +1000 From: Bruce Evans Message-Id: <199509301130.VAA32657@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, julian@ref.tfs.com Subject: Re: correctness of isa.c Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >caddr_t id_maddr; /* physical i/o memory address on bus (if any)*/ >ok so this is the Physical address of ram on the device.. >so why does isa.c pass it into the device as: > if (!reconfig && isdp->id_maddr) { > isdp->id_maddr -= 0xa0000; /* XXX should be a define */ > isdp->id_maddr += atdevbase; >which is the kvm mapped address of it.. >BUT ONLY IF THE DEVICE IS in the 640K-1MB hole! >I have a device at 2GB >needless to say, I need to 'undo' this mess when >I'm probed, to find my original address.. 2GB isn't in the isa address space :-). You have a better case for 15MB. Note that atdevbase already has 0xa0000 in it and subtracting 0xa0000 is just to compensate for that braindamage. The end result is that addresses in the 640K-1MB hole are correctly relocated by adding KERNBASE. Addresses outside the hole aren't handled automatically by the vm system. Some drivers (especially video drivers) aren't passed a valid id_maddr and do their own relocations on fixed addresses. >If I were to 'fix' this for all our drivers, >does anyone here see a really important reason for this field >to hold physical and virtual addresses at different times? It should always hold the physical address. >I have a pass over all drivers coming up to add devfs stuff.. Please wait until after I've finished prototyping everything, and run gcc -Wall and indent on you changes (all the old devfs attachments have an unused variable and inconsistent formatting). >(also while we're about it, why is id_irq a bitfield? >it's almost believable, but is there a really good reason?) There is no good reason, at least now. The bitmap is more general except it doesn't allow out of bounds values, but nothing uses the flexibility, and lots of things assume that only one bit is set (things that do ffs(id_irq) won't work right if multiple bits are set). Bruce From owner-freebsd-hackers Sat Sep 30 04:47:56 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA28359 for hackers-outgoing; Sat, 30 Sep 1995 04:47:56 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA28353 for ; Sat, 30 Sep 1995 04:47:51 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA20709; Sat, 30 Sep 1995 12:54:27 +0100 From: Luigi Rizzo Message-Id: <199509301154.MAA20709@labinfo.iet.unipi.it> Subject: Unreliable networks... To: hackers@freebsd.org Date: Sat, 30 Sep 1995 12:54:27 +0100 (MET) Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2164 Sender: owner-hackers@freebsd.org Precedence: bulk Hi, the growth of the internet in the last year, possibly together with some management problems somewhere, has caused the quality of the connection between Europe and the US (at least as seen from our site) to decay dramatically. In the last few months, it is common to see a packet loss in the range 10..50% when pinging a host overseas (things go much better for hosts in France or UK). This means that the connection is there, it's simply overloaded (or misconfigured: at times we regularly loose every second or third packet!) Such a large loss rate almost completely defeats the algorithms used by TCP to determine the RTT, to the point that ftp-ing a file larger than 100K takes a huge amount of time if it succeeds at all. While it is clear that this behaviour lies in the configuration or management of routers, there is not much I can do to improve the situation. So I start to feel the need for countermeasures which allow a connection to stay up and perform reasonably even in presence of large packet losses. One idea might be to tunnel the TCP connection using a couple of processes in the sender and the receiver. The processes could negotiate the expected bandwidth, transfer length and have an idea of the packet loss, and send packets using UDP. On the receiving side, incoming packets are buffered (possibly using a large enough buffer), requests are sent for missing packets, and the collected data are sent up to the receiving process via TCP. This is probably something that must be tailored to the specific application (e.g. FTP), but would have, IMHO, some advantages for the servers because it would avoid many many failed connections. Any ideas on such an approach, or on something that already exist to solve this problem ? Thanks 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 Sat Sep 30 04:52:04 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA28540 for hackers-outgoing; Sat, 30 Sep 1995 04:52:04 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA28526 for ; Sat, 30 Sep 1995 04:51:55 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA00595; Sat, 30 Sep 1995 21:48:49 +1000 Date: Sat, 30 Sep 1995 21:48:49 +1000 From: Bruce Evans Message-Id: <199509301148.VAA00595@godzilla.zeta.org.au> To: davidg@Root.COM, julian@ref.tfs.com Subject: Re: correctness of isa.c Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >The way that I envision this, the 1MB physical memory mapping that starts >at KERNBASE should completely go away, and each driver should allocate it's >own kernel VA using pmap_mapdev() and then use that to talk to the shared >memory. This makes the scheme completely flexible and allows you to map cards >that are in unusual physical memory areas (like the 15-16MB range). The only >thing I haven't yet figured out is what to do with the console drivers; these >need a kernel VA before the VM system is initialized, so you pretty much have >to kludge up something, at least temporarily during the early startup. Fake pmap_mapdev() early. It should probably remap the address to somewhere that can remain valid forever. The final address could be attached in cninit_finish() after VM is initialized, but the old address has to remain valid until then for debugging. Shouldn't pmap_mapdev() be declared in a machine-independent header and used in future drivers in other systems? It has no i386 dependencies except for the type of a physical address. How did old versions of BSD handle mapping physical addresses for device drivers? Why doesn't VM distinguish between the types of physical and virtual addresses? Bruce From owner-freebsd-hackers Sat Sep 30 05:01:16 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA28729 for hackers-outgoing; Sat, 30 Sep 1995 05:01:16 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA28724 for ; Sat, 30 Sep 1995 05:01:14 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id EAA02183; Sat, 30 Sep 1995 04:59:52 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id FAA01914; Sat, 30 Sep 1995 05:01:08 -0700 Message-Id: <199509301201.FAA01914@corbin.Root.COM> To: Bruce Evans cc: julian@ref.tfs.com, hackers@freebsd.org Subject: Re: correctness of isa.c In-reply-to: Your message of "Sat, 30 Sep 95 21:48:49 +1000." <199509301148.VAA00595@godzilla.zeta.org.au> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 30 Sep 1995 05:01:03 -0700 Sender: owner-hackers@freebsd.org Precedence: bulk >Shouldn't pmap_mapdev() be declared in a machine-independent header and >used in future drivers in other systems? It has no i386 dependencies >except for the type of a physical address. How did old versions of BSD >handle mapping physical addresses for device drivers? Why doesn't VM >distinguish between the types of physical and virtual addresses? It has no i386 dependencies as far as the interface of the function, but the function itself has almost no independencies. :-) > How did old versions of BSD handle mapping physical addresses for device >drivers? Why doesn't VM I don't know how old versions of BSD worked in this regard. They probably did something really VAX specific and disgusting (like plugging the page tables in the device driver). > Why doesn't VM distinguish between the types of physical and virtual >addresses? I don't understand this question. Different types? Do you mean kernel/user or managed/unmanaged, or what? -DG From owner-freebsd-hackers Sat Sep 30 05:52:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA29405 for hackers-outgoing; Sat, 30 Sep 1995 05:52:39 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA29400 for ; Sat, 30 Sep 1995 05:52:24 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA02664; Sat, 30 Sep 1995 22:50:18 +1000 Date: Sat, 30 Sep 1995 22:50:18 +1000 From: Bruce Evans Message-Id: <199509301250.WAA02664@godzilla.zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Subject: Re: correctness of isa.c Cc: hackers@freebsd.org, julian@ref.tfs.com Sender: owner-hackers@freebsd.org Precedence: bulk > It has no i386 dependencies as far as the interface of the function, but the >function itself has almost no independencies. :-) This makes it (pmap_mapdev()) like cpu_switch() - machine-dependent internally but worth having for all arch's. >> Why doesn't VM distinguish between the types of physical and virtual >>addresses? > I don't understand this question. Different types? Do you mean kernel/user >or managed/unmanaged, or what? The same C type, vm_offset_t, is used for both physical and virtual addresses. This is bad if physical addresses have a different number of bits than virtual addresses and the type big enough for both is too inefficient or isn't a scalar type. E.g., i386 virtual addresses really have 16 bits of segment info and 32 bits of offset. We can get away with not supporting them generally only because there is no way the general case can be efficient so no one wants it. Bruce From owner-freebsd-hackers Sat Sep 30 07:07:11 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA01093 for hackers-outgoing; Sat, 30 Sep 1995 07:07:11 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA01088 for ; Sat, 30 Sep 1995 07:07:01 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA05291; Sun, 1 Oct 1995 00:02:32 +1000 Date: Sun, 1 Oct 1995 00:02:32 +1000 From: Bruce Evans Message-Id: <199509301402.AAA05291@godzilla.zeta.org.au> To: deborah@microunity.com, julian@ref.tfs.com Subject: Re: spl'ing to a specific interrupt level Cc: freebsd-hackers@freebsd.org, terry@lambert.org Sender: owner-hackers@freebsd.org Precedence: bulk >go for tty for now and as we fiddle with the kernel >you can use something else when it's easier :) This seems best. Class tty is already used for all the tty drivers, lpt, mse, psm, pca, gp, gsc, labpc, tw and asc, although this is bogus for pca (it uses clock interrupts), gp and gsc (these don't use interrupts and use splbio() to guard the dma registers). Alternative, worse, methods include: - don't use a driver class, and use splhigh() to block interrupts. This method is used by the sound drivers. It only works if interrupts are only splhigh() off for short periods. It has the advantage or disadvantage that hardware interrupts don't block other drivers. - manage the interrupt masks yourself, then use the GENSPL() macro. This method is used by the npx driver, except it needs stronger masking than is provided by splany() so it doesn't actually use GENSPL(). >> is called. Just before register_intr is called to add my interrupt >> service routine to the proper level, INTRMASK is called to add my >> irq level to one of tty_imask, bio_imask, net_imask or SWI_CLOCK_MASK. >> (Which one depends on the keyword in my config line). >> >> My understanding of the splXXX routines is that you call them to block >> critical sections which could somehow depend on each other - that's >> why you have the classes of bio (disk devices), net (network) >> and tty (serial devices). My quandry is that I don't want to block >> anything else I don't need to - I just want a routine to call >> to raise the spl level to my level (whatever I put after the "irq" >> on my config line). Is my only solution in this case to call splsoftclock? Don't call splsoftclock(). It lowers the ipl to a fixed level and isn't good for much (its use is currently disabled even in the place that it was designed for, in hardclock(), because calling it from there allowed unbounded interrupt nesting). SWI_CLOCK_MASK is added to the level for your interrupt (in intr_mask[your_interrupt]), not the other way round. Bruce From owner-freebsd-hackers Sat Sep 30 08:01:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA02442 for hackers-outgoing; Sat, 30 Sep 1995 08:01:10 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id IAA02417 for ; Sat, 30 Sep 1995 08:01:02 -0700 Received: by sequent.kiae.su id AA11932 (5.65.kiae-2 ); Sat, 30 Sep 1995 18:54:58 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Sat, 30 Sep 95 18:54:58 +0300 Received: (from ache@localhost) by ache.dialup.demos.ru (8.6.11/8.6.9) id RAA00795; Sat, 30 Sep 1995 17:29:25 +0300 To: Terry Lambert Cc: hackers@FreeBSD.ORG, S0ren Schmidt References: <199509290125.SAA13960@phaeton.artisoft.com> In-Reply-To: <199509290125.SAA13960@phaeton.artisoft.com>; from Terry Lambert at Thu, 28 Sep 1995 18:25:13 -0700 (MST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Sat, 30 Sep 1995 17:29:25 +0300 (MSK) X-Mailer: Mail/@ [v2.40 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (aka Andrey A. Chernov, Black Mage) X-Class: Fast Subject: Re: SYSCONS PROBLEM IDENTIFIED Lines: 19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 852 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk In message <199509290125.SAA13960@phaeton.artisoft.com> Terry Lambert writes: >> Advantage of "erase with background color" is that you can quickly >> fill whole screen with any color without putting lots of damn spaces. >Agreed, *if* you set the color. The point is, the attribute and the >color state are maintained seperately on SCO and Xenix 2.3.1, but >not on FreeBSD. Ok, I agree with you now. We'll need to fix syscons to go this way. It involves additional state fields handling in syscons driver. Soren, did you see an easiest way to do it? -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849 From owner-freebsd-hackers Sat Sep 30 08:50:39 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA05049 for hackers-outgoing; Sat, 30 Sep 1995 08:50:39 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA05044 for ; Sat, 30 Sep 1995 08:50:34 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA05513; Sat, 30 Sep 1995 11:53:01 -0400 Date: Sat, 30 Sep 1995 11:53:01 -0400 Message-Id: <199509301553.LAA05513@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >Well folks, we've hit that wall we all knew was there and heading for >us at 120Mph.. The GENERIC kernel has simply gotten too big to fit >within 4MB now and no amount of paring back will deny a basic fact of >life: > > To fit in all the drivers we need to cover a reasonable set > of devices required at installation-time, we need more than > 4MB and if we didn't need it today, we'd need it tomorrow. > >Now some of you will immediately go "ARGH! What about my custom >router! What about my 4MB laptop!" and I know how you feel, so please >don't write me 5 page impassioned letters in defense of the last of >the 4MB users. Boo. Hiss. Boo. Its time to have more than one boot floppy type...or to have a limited device boot floppy for the most popular devices. Please, please don't make me open every machine and install more ram just to load the system....or we'll just keep 2.0.5 alive forever...... I don't think its unreasonable to have a net and CD boot floppy. I don't care whats on the CD...just make one available. dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Sep 30 08:54:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA05204 for hackers-outgoing; Sat, 30 Sep 1995 08:54:50 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA05199 for ; Sat, 30 Sep 1995 08:54:45 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA05520; Sat, 30 Sep 1995 11:57:03 -0400 Date: Sat, 30 Sep 1995 11:57:03 -0400 Message-Id: <199509301557.LAA05520@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Bruce Evans From: dennis@etinc.com (dennis) Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk > >I think that goes too far. Perhaps nfs could be left out, saving 200K. > NO!!!!!!!! NFS is the best and fastest way to load semi-custom systems. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Sep 30 09:31:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA06365 for hackers-outgoing; Sat, 30 Sep 1995 09:31:29 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA06360 for ; Sat, 30 Sep 1995 09:31:27 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA20374 for ; Sat, 30 Sep 1995 09:31:23 -0700 To: hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 08:28:46 BST." <199509300728.IAA14138@uriah.heep.sax.de> Date: Sat, 30 Sep 1995 09:31:23 -0700 Message-ID: <20372.812478683@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > But why doubling it instead of successively increasing? > > My notebook has 5 MB, and the last private 2.1-snap installed fine. David and I talked about this. Yes, you can install in 5MB now and I suppose we could even mention this in passing someplace, but by making 8MB the recommendation we accomplish two things: 1. We leave ourselves a decent margin for growth. Continually "raising the bar" simply looks bad. 2. We're recommending a size that's actually usable, rather than something you can just barely squeak by with. Jordan From owner-freebsd-hackers Sat Sep 30 09:34:06 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA06517 for hackers-outgoing; Sat, 30 Sep 1995 09:34:06 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA06512 for ; Sat, 30 Sep 1995 09:34:03 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA20412; Sat, 30 Sep 1995 09:33:56 -0700 To: Julian Elischer cc: hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 01:15:21 PDT." <199509300815.BAA18393@ref.tfs.com> Date: Sat, 30 Sep 1995 09:33:56 -0700 Message-ID: <20409.812478836@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > for the cdrom there should be an instal floppy with NO NETWORKING > THAT would make it smaller.. > i.e. has CDroms and disk support for all known devices > but no networking at all.. > that waythey can at least install fromthe cdrom > and make a kernel that suits them.. I'm sorry, but that would require a lot of shuffling and 7 days before release is NOT the time to be thinking about such things. Jordan From owner-freebsd-hackers Sat Sep 30 09:44:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA06956 for hackers-outgoing; Sat, 30 Sep 1995 09:44:32 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA06951 for ; Sat, 30 Sep 1995 09:44:30 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA20484; Sat, 30 Sep 1995 09:44:05 -0700 To: Luigi Rizzo cc: julian@ref.tfs.com (Julian Elischer), hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 11:47:08 BST." <199509301047.LAA20453@labinfo.iet.unipi.it> Date: Sat, 30 Sep 1995 09:44:05 -0700 Message-ID: <20482.812479445@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > For some machines (e.g. laptops) it is too expensive to add memory, > often they use special modules or just don't have the slots. I > think we can manage by making it not too hard for 4MB users to > build their own boot floppy (on a guest system, if it cannot be > supplied as default). Alternately, and I'm not fundamentally opposed to this, if someone out there wants to sit down and build a boot floppy that WILL work in 4MB by ripping some large piece of its component anatomy out, well, I certainly won't stand in their way and will even go as far as sticking it on the CDROM and the FTP areas with a little note to the effect that it's to be considered a solution of last resort for 4MB folks. I just don't want to have to go down that road myself - I have too many larger install issues to worry about between now and next Sunday. Jordan From owner-freebsd-hackers Sat Sep 30 09:49:46 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA07076 for hackers-outgoing; Sat, 30 Sep 1995 09:49:46 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA07071 for ; Sat, 30 Sep 1995 09:49:44 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA20504; Sat, 30 Sep 1995 09:49:18 -0700 To: Bruce Evans cc: julian@ref.tfs.com, hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 21:04:14 +1000." <199509301104.VAA31420@godzilla.zeta.org.au> Date: Sat, 30 Sep 1995 09:49:18 -0700 Message-ID: <20502.812479758@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > It's not easy, but we have barely tried to keep the kernel small. I > knew of the following bloat: > > 1) The gzipped installation kernel. Saves space on install disks, wastes > space in the running kernel. Well, do bear in mind that the installation kernel is overlayed by a *non* gzipped kernel in the bindist. We're only talking about trying to make the initial bootstrap kernel small enough to be able to uncompress itself in 4MB. That's the holdup here, and why it's crashing on 4MB systems. > 2) Using mfs to get a temporary file system for the installation kernel. Well, this was Poul-Henning's opus and it works rather well, but now that Poul has sort of gone on extended walkabout I don't know of anyone else willing or able to revisit the issue of providing alternatives. > 3) 32K allocated for DMA bounce buffers, 512 bytes used. > 4) 1K allocated for kernelname[], normally 8 bytes used. Any comments, David? All I can say is this: If we can get things back to below the 4MB boundry then that will be fine and dandy, but we WILL be back here again. We really need to get the dynamic device driver issue on the road if we're to ever have any hope at all in running on small memory machines for the forseeable future. Perhaps one or more of the last 4MB hold-outs will see necessity as the mother of invention and start working on this? :) Jordan From owner-freebsd-hackers Sat Sep 30 09:51:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA07188 for hackers-outgoing; Sat, 30 Sep 1995 09:51:48 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA07170 for ; Sat, 30 Sep 1995 09:51:21 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id RAA28252 ; Sat, 30 Sep 1995 17:51:13 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id RAA04614 ; Sat, 30 Sep 1995 17:51:12 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7/keltia-uucp-2.5.1) id NAA10098; Sat, 30 Sep 1995 13:30:22 +0100 (MET) From: Ollivier Robert Message-Id: <199509301230.NAA10098@keltia.freenix.fr> Subject: Re: A moment in the life of ftp.cdrom.com To: imb@scgt.oz.au (michael butler) Date: Sat, 30 Sep 1995 13:30:22 +0100 (MET) Cc: jkh@time.cdrom.com, hackers@freefall.freebsd.org In-Reply-To: <199509300406.OAA01183@asstdc.scgt.oz.au> from "michael butler" at Sep 30, 95 02:06:20 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#1141 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk It seems that michael butler said: > There is a very substantial memory leak in mirror .. the author sent me > replacement ftp.pl and chat.pl modules (~12 months ago) but I suspect that > they are still not a part of any release :-( Can we get our hands on these ones please ? I know of a few people who would kill for an even only slighly smaller mirror... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Mon Sep 25 02:02:31 MET 1995 From owner-freebsd-hackers Sat Sep 30 09:52:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA07219 for hackers-outgoing; Sat, 30 Sep 1995 09:52:36 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA07214 for ; Sat, 30 Sep 1995 09:52:32 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id RAA28248 ; Sat, 30 Sep 1995 17:51:12 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id RAA04611 ; Sat, 30 Sep 1995 17:51:11 +0100 Received: (from roberto@localhost) by keltia.freenix.fr (8.7/keltia-uucp-2.5.1) id NAA10088; Sat, 30 Sep 1995 13:26:44 +0100 (MET) From: Ollivier Robert Message-Id: <199509301226.NAA10088@keltia.freenix.fr> Subject: Re: -stable: tuucp1061: tproto, so fast ! To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 30 Sep 1995 13:26:44 +0100 (MET) Cc: andreas@knobel.gun.de, hackers@freebsd.org In-Reply-To: <199509300655.HAA13824@uriah.heep.sax.de> from "J Wunsch" at Sep 30, 95 07:55:28 am X-Operating-System: FreeBSD 2.2-CURRENT ctm#1141 X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk It seems that J Wunsch said: > Watch out, i've experienced SIGFPE's when transfering large files > simultaneously in both directions. I've reported it to the Taylor > UUCP list, so i thinks it's on the way to be fixed. Did you get them only when using TCP or is it a general "behaviour" of the "i" protocol ? What are "large" files in your book ? I exchange news daily (average size 50-150 KB) without problem. I haven't tried to transfert Xemacs in both ways simultaneously yet :-) -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia.freenix.fr 2.2-CURRENT #2: Mon Sep 25 02:02:31 MET 1995 From owner-freebsd-hackers Sat Sep 30 10:06:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA07884 for hackers-outgoing; Sat, 30 Sep 1995 10:06:32 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA07877 for ; Sat, 30 Sep 1995 10:06:23 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id DAA27750; Sun, 1 Oct 1995 03:04:52 +1000 From: michael butler Message-Id: <199509301704.DAA27750@asstdc.scgt.oz.au> Subject: Re: A moment in the life of ftp.cdrom.com To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sun, 1 Oct 1995 03:04:50 +3400 (EST) Cc: hackers@freebsd.org In-Reply-To: <199509301230.NAA10098@keltia.freenix.fr> from "Ollivier Robert" at Sep 30, 95 01:30:22 pm X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 14763 Sender: owner-hackers@freebsd.org Precedence: bulk Ollivier Robert writes: > > There is a very substantial memory leak in mirror .. the author sent me > > replacement ftp.pl and chat.pl modules (~12 months ago) but I suspect > > that they are still not a part of any release :-( > Can we get our hands on these ones please ? I know of a few people > who would kill for an even only slighly smaller mirror... I must admit that I wasn't aware that so many people had this problem ! Apparently, there is a leak, whether actually in 'chat2.pl' from the mirror 2.3 archive or in perl (4.036) and simply triggered by this module, is unclear. However the following archive includes a replacement module, called 'lchat.pl' and a new 'ftp.pl' to call it. From all reports, these seem to solve most of the memory problems, michael begin 664 mirror-2.3-fixes.tar.gz M'XL(`````````\P\_5?;QK+]U?XK%L-%=F*,30AM("3A!=)P&I)<(*>]I[0^ M0EK;NLB2*\DXOBGO;W_SL;M:R1]`0_HN#<66=F=F9V;G:T?J9:/6*/SNF_YT MVNV==EM\)_"G_%?L=)ZTOQ?BZ<[.TR=/=YYVVD)TVMM/=KX3[6]+%O^,T\Q- MA/@NB>-LV;C)0,IOS*?_CY_5C4<;(YF$\*>Z*LX'02K@GRLFB3N"ZR*+13:0 M(O0&;@:*(I)XG`613.&JFXFA>P7W@IX4TDT#F0`(F.#'HI>-1#8=23&)DZL6 M7#Z)TRR">E./'>Q>/^(`PB\3P<_GOXRH^]5N"U7*\UOGH!PR_=5/HB MCD274=+R8L`@>G$BAN,P"S8&\1`0#8"ZM+H*\_X'UN&)<>KV MY2Y\%6NPDNXH3C*Q+[8Z>W0ID5DR[7IN&,)%="N?` M$;O".79$8Z^$KB^S.BYH&&>RVP/`D3O$U88Q+,^ZT%Y(!$`0.*Y$QA_C(*LC M.A+.VK&_B\L'16Q>BZW6CN@\>[:]V=Z!?Z+SP^Z3[^&?0(421Y]'_&$-Y[V+ M^]9$O'0JKP/2)X1B@\GAT'P8>C8),F^@>(7[0&S`!DG'ERG0'/<$;0U4.5#% M":F6PYP0`QF.G%1$DB>/W"25M)WPADBS)(CZL-\BN@8BA9TU=E&HH(OB$XQ- M)+`/-8?`CI+X\]02?5K$ZB4$ MX@Y)Y*31(LY:['BJV;&]N?5,B*WV;J>SV]XV['@=1[`7,UX2`DYZ7J>S]60& MT+8&U-G<0KYN[SY]MMO.^7K@^P#D\$=890I[$E2%`:]$$L+;J#\L%-$_IX&8V(V\M@_4#T#)XMPO-DL[.U MV4'"8;K;WMH%MZ@QO!F#/<%AB0S!FDK2^6HB80L`5">=IIL&K8/;Q-AD,MCI2'H! M++&HEUMXGTRU>QT'?@J4#Z48@GHF4P%HKH!.@T(#!.C5ZLCUKL`(XJZ!K\I8 MC5P4^+[8:>]55L5'^G8I>VK9R90TCPU*JUI%`^'+'K@+'VSAT`TBY^.;[O'[ MHW,V`Y6U4:\+=]&V%F[OP2U<:Q?T6;I#<_OLP^N?NF?GIT<')S"$C$M]39D: M-PR`:2D:NR3.X@9,`IM"GR^G.*8NG,P;D?&JK,&G+MV#83QAKWI3E2&L!^A: M%;_\\HL8N(D_`<;X8DW1!<`M$IH,$(=?CC,Q&<1J;WM7X/;&H'7`SZA/.Q[@ MNM%TXDY?BOKN1J.P]*W9Y7;*-.X@>2#SXQ[A4/8%/8'OPN<(?*Y,(R?#O32* M8>^#S1J080'ER`*0^0AW&?P-P,?XTO4!&&@LJ@,.[+>J:S@,O#NBWVKO(;9S M=<5%0^2#P1?'@`C1H+GVW;M\>C*[3T5'`OG#6]-[:)1N^YC!`$\'4^F%\Z88U6#'95E"@E&,9 M-]5\`K&0+2SQ%)SF-04SN*G'M/.%3!+)F($!T`W`9F^BU>%D`*_L-6'!3_"@W;I62Y M`%V3!&(?X!A$J2`'-[PB1+$%$U>3+XW(AU_P"`1V7VRWG^T0!]^",8M["`Q= M%K@HE/_`30<"Y-!D#+Z\'/=AD_<9$-Z5`':*NM/>VD96?!AG(U*=2$X@SI/* M]N8Z0I-21@*3`4U,4Y!R@A7&\`FGICF6"$.N[UD[CXG!8'I2&KWD";C6 MP)-:E]2L'HPO>U($%-$.ANUW3&X7@M6D,"Q11WX&RY^U1*[Z?53U3/MEF(6:)".?0PLR5L>PDT"[QQ': M@2!3V@1A?P"HP&:[X)#!)/A)/.K&412`,5X' MWKK9`.TM7AVZ(X0..A23$5&*J(>TF#TP:AP%G]GV.,`<=37"JT&D+EJ;^]^0 MM`&\+'$]\CB!SY"ZR&@CZ9\EJ@>2<27E:";&,GL9MBC=Q%@9UA&!XL57`EPF M7!PR+0B@6PC0#)9/$7.7>$CBB1$"J`'PR.P3C!,HH*4K==@EZ(>JX*R%N5I% MCVBMXE7WU_9OX`C0C>;77XAGY#LK:^BM>:;R&#?H(S1("`*ZRG@B8':68$]C MT2#8,%ZI$YAUO+QO6]N*Y0W6T#E6%EOFRG(K7Z*?:&>S8N^-&F6,"J<*W#2, M"\Q.>'5F>4A%UPW=9(BKHV1"C=XE$U#;LYF!MWRBW.;%W5,RQ3`]46W.K@*@ MOU*:V+#&`3@2!2:S364$;+7<&T6-$W#XSXE8:9 M";\QD)L%6%G4=%LS@9?8$%\T\I7R`M4]B,-@55$,C@0W/IDRT"2Z59H!)AQ0 MRP0"L`UUS:*+T/+&TJ#GD#I.D3=,G?(TM.>+J)J"`<^#`":F)!JU?":CH&8J M3LT![Q6&J`I%"1R/L3T7R5%S6(>[F4*``:1W66X29',G/6<[`?'VW;QTPVJH84=X;'&Y&>Z7(, M[A![P?.I4_:V;2C$7S(2^^P:6`[:$ZL4[$TI)J4,R^S+:LY) M4SR"B2P3BAZPA&*Q!_$J8MAO5)1O8W;-63"F>JCNES*;2%@T"BV0J=+7-`3_ M:$3)26*#`>=K5N:8$CGD"S"J#_F1'T(X6C#*_5F#.TSY(C!^W!^@[S\[_I&& M]D*7'*PM2#^>$%T+@L#<@@$;^^#SB5WR&I+GVKIUO2XN&+'Q/K9OY8I":IRV M@J4(7P/ZO@CGX_''(T?<(.6E)==40G'=Z M`JS->:TN*%Y?6!%"S09%/AD&*7GGD4$=4DJDT+D3B;A:Y=7;7%(H4Z&)1N3$ M^E=B_W_%YN]J;V^RVJG]L<'[L)IO9([QYFBP'JEFXN!"K$.VP6:[*LNJ4K#Z MAA7A29SXAME"_AZD6IEENCEXA)HF?4OV$(H_ M4U'^NN8YV7&?#;E:"W.],*VC^?Y.TPV(#L;$:I:JPY]_%M"YD^CRGSN:)"FCGLL/E1K116C[-NL(1WC,6M/@B% MDOIC43H?F>/)BC1H1S#/X90\L;59Z1I.+9QVW`/0JGC-148_P%I_G$RKJ[I. MT,$8)!U[$)BFO7$(-]JU[=WQV#K$DUQ4:&!1D;H(PNHU9_6/UH[AF@0(" M-V:R<\.0!9I8N;\JKN0GLEU<;Y>+L_7&G!D*?$Y&V=60U/3MY5X)AYH1MZMK MIQ#Q%]3UK^NIXI4)+=:-^;%9L3>'#>"]Y`A(?'_6%&<@CC__Y,-;OJX-Y=H* MA5FK`G]-B3ME]W\I=;$;-'0,KB2>P#`$GIMBC!S!FE&Q$R-XLWC6:#HBI+*C MJ9%K;5YH\7*5FZ=PQO9^E8EC(7%UD0#BNN9(.!>PCK0LLP0[*4KQ:!96-`HE MALD(K)C7_'790[@R`,M+7(W'BLXXGJ0G6859S2^@L"7!7_!!>V_$SE MOJ)"ISA72A2M=Y4.=#TZ=^,UORK<(2NZ+^KW%JV]A?_YZ?C\+MY&%-S--Y7K M'-=SQL$D!9I\0.7ZAI'X95')%._5[@*$\R6Z]&6VKDE;@9BD:$NG*5YCX['& M!T[F`YT\Z3#F,*:0>$P=$A!M87T.1:A:`;`\*V6,2@I[#FP'LJB+#8GJ$?&FJP90-RL9#Z# MOZ$8[`&#CQR^D'^(6DT%POE5DJDBQPY!;HE:;BE/LANF&:I:MYRV2`IGP]$9 MX)L@8M^F#Y_Q,W!&MVO!H)PSQ+*NRUPCFG$(SBQ@($NF3!YS>7V],/T%2`XN MK:LC=KQH:1*U8;1KY+:7:EX@V&,2AW>V=[ MNSE#6:DRGJ/@NNTX"H/H:G9!-[=E/$:V2_,>2R&=WH+LY_3H_-32E9I2R%O] MDAU7>C*X1O.:@_GZ^D->>UY0P4>QP)9T2@MP="!'"DIZ=VN\LB1@*2OXMXM? M*=9;%;S1*,-B,\;LA!O@Y#U0N@C3+.XRH+5`Y*/4"D`V!6D;G6G'$")A*X<2 MQ@K7)=^\;8JZ4<27PGGQ@CHQ7S@-T2HHXFT6P:,6`\O:6K._#?--[9?V+G4B MH77`#Y95O9QFU+J%K3G8Y@$?57L(#JZWFP+_-?C`/=4=5=D@D9([1)"EF*7Z M'$4,W&LV`,IS-L39O\[.CT[$ZX-W[[`(M(JC$X&=S]0Y06TDHY%TD]3T0EA= MP06$$GN].Y?'51?7Q/!S$UB5]$%U? M"ZG:M%Z,L^J-!IEET"_VSV9)AL/:.[/AC;$IDA@VB5E$K6KE6GIU*W"AON`8 M-Z9HD&E2=GP1*3818(1(:<1C6#*,,SXECS[8?N>-3AB_I9L7R>9F7]OY>:?L M^D2>P;]`,I16BL>BV.ZD_="<'>>L.GM\\IS/WB]-5P-8TQ\_YJ](4EUK_S_R M&5'80+O?V3#!*90X:N.+//02,$ M`+#`W`-27R_I`)XVLB:SBNL=BOV#!=5IS5-2^_B$"YY(?&/O(=)94JSGFI=S MET\)`7:DY348@+.BC62Q1E*IEC0)`QJM/VVKH4.)%6XO$O%*+N+E[1'&L$I/ M64DRKANVJR%9I3,ZX\._;>']X<+0PZ-W1^4P]%Z".B0V^`\0@Q9830<_97YCC?]+ MU3[@++*;;JV:4[D`-0?=,R0,?.?TY)`3V4\?#P_.C\3)T0K]*(.G'#@9>MH# M^B$,W?[JT6,3V*]LR!H56_.*^>="?<@=W']5&CJW>/Z--?#L_,.\1.B^->A2 M34CAN"6%0A(H@3*<>P"3LF*=X#Y@%/Z-:_A+DZ"93*;V/&=9[?:4A<#^;0E+ MQ42?S]^\?9%[[H4[S(Y^U"H@G&58A;"EX13W`A$\J'7UXLSB*J2QTE'GRP<$M10'>S$:ZQ:+`\N(J13Q%=\I!T"@&E,V\VLM=17_U#.#T"$_\ M"K!K.B(EZ4I,T3AM@V30G=[%'3Y1TA!4EM%%`=QC14P/>4J@>LYH/QD=P"<^ M\S(_?K$82L_R?CT'S__U\8B!?3WC9ZK M'T-4`_*HNMC,!&"P_7SBWS^)*O2Y_7SXD";+ZD,"S?OZTGOAF1'KN40\L=RZ M\.&_]%&MWGK4J%VDK4=KF[H,@'R!@-_JA-/6#^X4!=&A?:'.U["UD5 MI8+MW/ABA_]RX:1DL'J8[:%!>OWVY,.A^$>LY)4OXN$$1]Q2<)EZ8B\WOSZ@ M_"@%=OD8-8]E*6WZ4FQ]5T6!2$ZZ?TN-2.-<*K:_?G.8K>+A8&;+- M#S]]33L41Q@!YUXU)0IT?341>]XXP8?^XZN%]K7,L$HNFF4;4_L&D`F0S<;9$Z`FS_/8J*3 MUGX>KNP5NV?+KUK#V5UVK?EQXSE^5 M']_2-Q(?Z\8E:FCQT\8U)*3=[ M4Z-YX(GM5LOP$#5JG`Z*"VZ*VJ^M/R^BWQ[]7D>\$*Y>7+0[3R\P_^#3I7ES MUHU^HY'MJ*=NGCW3'==5:@L"@O`5+"*^O`[B<5I\W5*K>@LY%Q!!T[^-UJ,_ M?_T=/OPV0]T]B.NTV[7"\]\H#M)[E/.,E"HD=Y#Q[PY_BRG)A^$^ M1ON/\PB?9YJ5F/-#_:2,/7'YK!POHF#<-XN$@A#J-6Q/(03PER:W1.U.4J7L M>3[O$*C%'MU6;\LX&@])X\SV0!I2.MP!D&'@!?@N.GS-@Z1GM^XN_EF=O(?4 MV_D!Q3E:+H'//(\C?#]'/PJPPY%[6=R2=BY`\GO](520R'%]7^_?5)P?GQQ] M^'1.IU=4AIX'U5&CG+OA=#77OZZ!GW,V&X70\/2.SHJZ^0W MD7#+X#=GS7SA47#+:2V?-3?@(C>'L5**)Q&XH""V_%+Y_*[P@"Y<`56@-P:6 MWV6!)57,MJ9J@`N_EUA9@5^_,'(XM>#TW&$03K&?*Z!62^V]]!`T)V<"W,2V M^/P#ON4%`A2W"9`!\)J/$1@:A?;^.CN<0<[!"GV?PR+^P7W[=NC9+8 M(S3JB%)@%[-ZX593V._:PGYI\YJM_%B,Y^WR@5CE,L#0$F$0IO]K[VJ;VCB2 M\&?S*\:@LJ5X6?0"Y@(Z9 MG17@C%(>N=8!MGOO#\U7GDZF*,$"E^9L\-#\[>&>6*:BV9S.,3PI`)R MAI?>8S4AT8IX_:9["<-/L<>>I5M/2@NGUQ MMN4X8?I>,=RUIB_.?C876S+OMN=G7,_=LBX_?6SI?&'W`#?XI/9#)Q'Y/ZTK'AQ MZ+EQ<^C>>.?%S96K\_5\%E&-5&'C1[-K@+4DI[:+>)(N16@(>,.X^/KXRYTO M<7FSM;PUY^,\F24?8ER]3)/K)(NFR]``J5]"'<9.OZK5X"HH6TSH4-.:%ZC'&Q)TVO9MA2W<8!\VY3O$I:\ M!*:8T_A=M%HX>[D*QI4:]&?3I6"%H8`=5$RU1=E#!=!'B^:MZ2YI3A>">H9' MK5MJIVL4GK1OS7$!QK')>^UT+-LIE]*Y-2_F=)7WI"A:M7I)7L*S%]JUY MD_')8YC$N.*WV+DU7\/2ER^)F5PS+%ZKU03.)_M%7T?3]W;80X:8-=0RN4R$ M(TH@=Q?@E$A/XD74%Z@-2(5I/)PI7)[FG,`.VY^GT;3P!>*V[L.H=3W/Q3%P M3S]__>+B.[.D1(1X34D?"T(@F,$KE:P@.^X6YV%JJ.=M.4Z>&QHC.5N/WT7+?1#V< M."UJ\:!<+$]?F\2G8^79R!/RL[9[AJGQ/+$"Z#CBZ3"=XP#'2C`OI;G';\?\FC;?(/,BA9G*>LL,V#* M"H$KKN8L@JH`>1U'#/;(-U8+8M+U[*TL(=<_KB]8GM*@2UL$1__!;`@!DU9Y@(3*Q\[!2?A1)%S*=: MP(L<_B@DN9^R-$-D.^[/,1M<\QV*PDZ6Q3=%V^@4;[_P/$N8'?BT()4I1@.H MAF3U:$)+A;:)2*?W'M(4DLS&!552XRG7.SKXR>RUG_.-8NN_>T^E%[2XB(/@ M((B9CZ1D[V)J'9TB=@$Z%)]US>DJA<6%\_9(2FI(O;OF!-P;%9]'-(C$2U_C M(%P?M8)1.QAU@M%V,&D%D[9DZ#29/130%X'=,_CU3O.!AF+9!,Y_1S_>Q39_ M^0WF?5V59`(CVNFTI!J>=\G+Z-06N8/WH$Z;-H!XVA-\^V)2)RHO#^90W M0&^OXLJW/6+`RHX^D-08]=*RU]$#M'$IN*%+N9HA:P0W![-E8<$?NG6(*MYG MXYN"!/N&[`#PX+NCJ+WL>N M*\QAYIGKOJG'X;LPT$N1\WS9D`);7H%:EE:XIPYQHN03F@>Y*CO>WFG?S7JG M&:^R?,[<@#TXB!,"[9EW$Y9/BTUVA[BTO^L';L2=[N)6!J$T44G63^<#Q4>% M9PN4,P4"12K>,6.&>64)I-DJ58]N7S^X#XAKSOFJXBD2HQ# MUN>[B]:+1MYO/Y1=E0"TO[CJ.0H>88%(8TNT8=/JQY!(YTLQ.SIR"-*07C\ M*;-%-I51KPLS]]AN<5A.>3S3-G8^M_]R!W7,NK'Q#;.MM0V),\&[O84EM]XA MTWF\1F+]_SJ,QO]MLICO?V8=GX[_TMIN=3I%_)<.D/B;NYW=*O[+7Y$*4.4T MF%<9.US$RRT.ZYKL\S+=\2@T"6!4$"0>)^.&/HYN8Y58,9E M3(EM(#P!'UK%"G$4P5O,M7TW@A>>C^=3V1/*H1"@.]4%L<>_B,M@5*"7?*6= MVC/_:(?-5ABEDU$4[IHO6PCLT'H.[8%T]?NPZ&T=XW%P'4_397:4T+-)"/S9 M-*0MZ1"(21R,!K%HH(I/%*?[H?`UZ+&+.;$UB#]L`9)0AEOV;<[\[3@V+\?S M29:\-P??7KP\.CX.WW3?A"7P[@H:>BG<\(WH&*=S\5O,-%T$`W]]?6 MYAF18>XB8I@G13",7]<4?A2:KA>7E^97T]PW'Q'+P[PZO3SY7A]`(S88WXT% M`K5_%6SC#PZVL?:@C:(_&@/M%O+(2"RBO]3Q"\LNO_T&&0XW,3/^7?](&Z9] MR&L53JR_L/%W;6/C#G#RNG":$/42N:P'K+A_*\8$."1LJ&TG8E%I(&ZQ>$F_ M7QZ?6T[%2E-7+-$/99S,>VG2=W,I7ZK5815S5=^RR4%_QR%#/;C^&=NSF!=% M*Q"=D+#,)N36Q7Q"K+(?R[%J@:7$AX-!K%8;'=WUJZ;\6S?6GH/*Z`U;/SSC M1YN1`%Q>=14RMKFB]*Y?#9XUGEV%_+/\H[8ET+=>]VPM:E]JT7^JI=:A_]ML M9#/.*T6&YFBA](XY5W+7\MR%V\?F:*$F0)54&9['6?I*U=<6/V[_)/IU;ZCO M[[TU$14%H$[A+::N]J[/,G[CV6([A<;W;$#=(1F+K"NB`R2.! M"WF\=J=''XOZV5)F#65,+W]")7I&YWH\ROSC:F+ZQMJ)!\65`3EQZ[*T%TU> MG/XK*!21,W#[&]$\>!(1G1^'.%7?Q`H6@6-Z$:ZC/TV@!V?'=MP*NX[Z([[& MD%NYP"XO;LNK<^Q4)$(,1+TX#(`V06MMH=TES74E[8UL*H?P?%XBGL MBQZ-^09*#-WO78\;]EH;_#TV=:Z$%ZP]TAO_=?W9;5#>W\""&S\V?T)=UJM9 MW.<8%I8?K%C%';P5?@;XD/V,L79[X\&RQ2'O9FW]DWX"5*/!!?HY[:4/_KT> M)VJW2<7VH>%S[!F7J^+S+8E?O7R*5HE)QPNXEN#,SX*%3*!,)%\?1HQCIG09.?%F+;/B3M0,;R'=" MA`JO$0FW1&V'@GN39@@KA%4$1#2]J$?R6)R)[HPU2U18&F^R/VB.K1C1/@A5N2P3LS6,C4GCSPLYZ''CA"Q[@5T/;*.>C(J/!/6+3 M3]R?0Q&A"D,[5?Q*%!ZK!<$AY=.%6+,.[7*0Q=GJAT+X3A'3E?.OD?!`K/?@ M<3R/;,P@.OIDL;M+/IX.X-("O%=>XT264DS.9R2-*(42!,HUM8%[-#CG#2-M M]&)67K/(J1R422.:IHD6AR+XL"77@&V[+DNXFYC[IXXP$GO:DGA%)8A.V^UB M0D.HV;$"L*R*Q])KU@.-$`YT)CFG^%V-821D8/+E0!CU^\D`=K@T788&DITT ME#EWJ4DT*;J:BY4(!6)F8NJ*K$8U_J&`>R@??HZ]F$-=L4PM%+%U9M69L.L@ MT!F$*_;&+8(W414A28^`/R$A3+W"UX5S`;FGR6D=FQ(CH,L%CE[9;U<^OU=N M(_[*X![63=`3VJQK1(W:P-M@*V@5KCDUH-C'S/?EM^+-]#K*WP<6'S`0-@FK MJ#+WWGQ8*D>%?R%I'`A8IX<-67K,^X8V%,`WPFUIC=IG!^9YL_FV*?]%J*1= M4_W;)7#33>PB9ZJC+P<3PUCMK17B0*T8Y)HZ2.F37[7#P=';CR(=H)()%`>L M4)3BQEF\!Y'LX;SL:%%4XDTL0'O8:Q,#`G_F@X/UDY<_\-R.Z)`)*TB.$`[9 M4L)A4:T,_<,Q]PS[8#Z5R`ZN!FKG]V=GYWM&_,I,O4EM-W3Z6Z.2UQ2?R-2/ MWFILFKJ;!IV%AMZ_Z\?T4=`,VN*LSV*R?BIR,A%);2NQ(6[N=L)ZB9KZE1`4 M?6@>/;+GVIHC(LHL58M\*^W$D-(JL;AY'XV656Z#4FS1CD\W0S^7;\WO:$H1 MSLIKCHT.XS^<#@(3N8"$EW5]`$8_K@='\=$%/3[H_/-7,#AH13,-(.#SZ&^A>RD@4 MV8ODNY8%]0*A.N["7S'4!@A*I4'+A%;P3"W'V#0.TDAH64ISY)MI]#&+7=HM M6%?`40DEJ[I+%['3RGA:$J#/K&LI1HM57*V5CPX/;0T'!V7L+6TAYSTT3=O( M1T0:N/6@N32#3XJ\:)X]@[0S&!LP`@X@0?Q#C6*T;P$]CKXJ:BL3L\[JG4)L M-#B;JWAIK^_0Q'SOBP.?_+%WE=6.A)R.]+PJ2WQE>0W&CIW9,`56 MTR&.8T>P#C68[\F(EO8Y'63O+LKJ=)6G@?^*!WL\`:577,+'4@,T>`+7+6?" M4MWVS*CW=YXX'67]"\'`S7#S`YBZ])8C<8*1XTGH@&BS<R2%+]!X MO,3N74@+$CD0SS/OH3?2\NIP!2+87U=>P8&?IV&'N[+)5:E*5:I2E:I4I2I5 JJ4I5JE*5JE2E*E6I2E6J4I6J5*4J5:E*5:I2E:KT%Z9_`_JOQ`$`H``` ` end -- imb@scgt.oz.au, imb@asstdc.com.au, 3:712/400@fidonet From owner-freebsd-hackers Sat Sep 30 10:21:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA08226 for hackers-outgoing; Sat, 30 Sep 1995 10:21:05 -0700 Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id KAA08221 for ; Sat, 30 Sep 1995 10:21:02 -0700 Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA18204; Sat, 30 Sep 1995 13:20:30 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 30 Sep 1995 13:20 EDT Received: from lakes (lakes [192.96.3.39]) by ponds.UUCP (8.6.11/8.6.5) with ESMTP id MAA21305; Sat, 30 Sep 1995 12:57:21 -0400 Received: (from rivers@localhost) by lakes (8.6.11/8.6.9) id NAA12691; Sat, 30 Sep 1995 13:07:11 -0400 Date: Sat, 30 Sep 1995 13:07:11 -0400 From: Thomas David Rivers Message-Id: <199509301707.NAA12691@lakes> To: time.cdrom.com!jkh@dg-rtp.dg.com, hackers@freefall.FreeBSD.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Content-Type: text Content-Length: 3107 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > Well folks, we've hit that wall we all knew was there and heading for > us at 120Mph.. The GENERIC kernel has simply gotten too big to fit > within 4MB now and no amount of paring back will deny a basic fact of > life: > > To fit in all the drivers we need to cover a reasonable set > of devices required at installation-time, we need more than > 4MB and if we didn't need it today, we'd need it tomorrow. > > Now some of you will immediately go "ARGH! What about my custom > router! What about my 4MB laptop!" and I know how you feel, so please > don't write me 5 page impassioned letters in defense of the last of > the 4MB users. If it were easy for us to continue to support 4MB > installs you may rest assured that we *would*, and we have in fact > worked very hard up to now to continue doing so for as long as it was > humanly possible. But we all also knew that we couldn't keep doing it > forever and that *someday* we'd face this decision. It looks like > someday just got here! :-( > > It's not like there isn't precedent. Even Windows '95, so pointedly > an OS for the masses, apparently will no longer even run in less than > 8MB. We, at least, aren't saying *that*. It's still perfectly > possible to generate a custom, stripped-down kernel that'll run on a > 4MB box (though not very fast), you'll just have to lay your hands on > an extra 4MB to get it through the installation. > > I'm sorry about this, and if I could have forstalled this event even > longer without crippling or excessively complicating the installation > for others (and myself) you may rest assured that I'd have done so. > I'm no masochist, and I certainly was never looking forward to the > prospect of having groups of 4MB users throw tomatoes at me for this > kind of decision. Sometimes that's just life. > > Just FYI.. You can at least say I warned you.. :( > > Jordan > Well - there is another fact of life that I have to deal with. I still have to install FreeBSD 2.1 on a 4 meg machine. Now, since we know the GENERIC kernel won't do that, can we at least have instructions on how to build the installation system so we can put a customer kernel (without all the drivers needed for the GENERIC case) on some installation floppies? And, yes, I know I can use the makefiles, etc... and build the floppies; etc... but a more novice user would probably appreciate explicit instructions. Now, once we have that set of instructions in-hand, can we take one more step and actually build these for the poor 4meg user, with some cut-down, but common configurations. For instance, typically, the 4meg user is working on ancient hardware, and thus is likely to only need support for the wd drivers, we could lose all the SCSI code. Also, we could eliminate X11 support (that wouldn't gain much), etc... We probably don't need the sound drivers (to install, anyway), and only the "common" ethernet drivers (if we could define what those were.) So, what I'm suggesting is that we identify a cut-down configuration that would let most 4meg people install. - Dave Rivers - From owner-freebsd-hackers Sat Sep 30 10:21:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA08244 for hackers-outgoing; Sat, 30 Sep 1995 10:21:32 -0700 Received: from asstdc.scgt.oz.au (root@asstdc.scgt.oz.au [202.14.234.65]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA08239 for ; Sat, 30 Sep 1995 10:21:29 -0700 Received: (from imb@localhost) by asstdc.scgt.oz.au (8.6.12/BSD-4.4) id DAA28391 for hackers@freebsd.org; Sun, 1 Oct 1995 03:21:26 +1000 From: michael butler Message-Id: <199509301721.DAA28391@asstdc.scgt.oz.au> Subject: Re: A moment in the life of ftp.cdrom.com To: hackers@freebsd.org Date: Sun, 1 Oct 1995 03:21:25 +3400 (EST) In-Reply-To: <199509301704.DAA27750@asstdc.scgt.oz.au> from "michael butler" at Oct 1, 95 03:04:50 am X-Mailer: ELM [version 2.4 PL24beta] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 255 Sender: owner-hackers@freebsd.org Precedence: bulk I wrote: > From all reports, these seem to solve most of the memory problems, I almost forgot .. also note that these modules plug straight into 'ftpmail' and yield the same benefit :-) michael -- imb@scgt.oz.au, imb@asstdc.com.au, 3:712/400@fidonet From owner-freebsd-hackers Sat Sep 30 11:26:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA10417 for hackers-outgoing; Sat, 30 Sep 1995 11:26:59 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA10411 for ; Sat, 30 Sep 1995 11:26:57 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id LAA29816; Sat, 30 Sep 1995 11:26:20 -0700 Message-Id: <199509301826.LAA29816@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: "Jordan K. Hubbard" cc: Bruce Evans , julian@ref.tfs.com, hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 09:49:18 PDT." <20502.812479758@time.cdrom.com> Date: Sat, 30 Sep 1995 11:26:20 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.org Precedence: bulk >All I can say is this: If we can get things back to below the 4MB >boundry then that will be fine and dandy, but we WILL be back here >again. We really need to get the dynamic device driver issue >on the road if we're to ever have any hope at all in running on >small memory machines for the forseeable future. Perhaps one >or more of the last 4MB hold-outs will see necessity as the >mother of invention and start working on this? :) > > Jordan Fixing LKMs (something even people with more than 4MB want) should take care of this. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Sep 30 11:45:52 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA11060 for hackers-outgoing; Sat, 30 Sep 1995 11:45:52 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA11053 for ; Sat, 30 Sep 1995 11:45:49 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id OAA05922; Sat, 30 Sep 1995 14:48:25 -0400 Date: Sat, 30 Sep 1995 14:48:25 -0400 Message-Id: <199509301848.OAA05922@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Justin T. Gibbs" From: dennis@etinc.com (dennis) Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freebsd.org, jkh@time.cdrom.com Sender: owner-hackers@freebsd.org Precedence: bulk >>All I can say is this: If we can get things back to below the 4MB >>boundry then that will be fine and dandy, but we WILL be back here >>again. We really need to get the dynamic device driver issue >>on the road if we're to ever have any hope at all in running on >>small memory machines for the forseeable future. Perhaps one >>or more of the last 4MB hold-outs will see necessity as the >>mother of invention and start working on this? :) >> >> Jordan > >Fixing LKMs (something even people with more than 4MB want) should take >care of this. >-- It really shouldn't. I think that what is needed is a "bootload" kernel and a "generic" kernel. While its ok for the generic kernel to be large, the "bootload" should allow someone to load the system and compile (or load) a custom kernel, which can be much smaller. There's no reason why the generic kernel has to be used on the boot floppy. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Sep 30 11:54:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA11599 for hackers-outgoing; Sat, 30 Sep 1995 11:54:40 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA11593 for ; Sat, 30 Sep 1995 11:54:38 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id LAA29955; Sat, 30 Sep 1995 11:54:16 -0700 Message-Id: <199509301854.LAA29955@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: dennis@etinc.com (dennis) cc: "Justin T. Gibbs" , hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 14:48:25 EDT." <199509301848.OAA05922@etinc.com> Date: Sat, 30 Sep 1995 11:54:16 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >>Fixing LKMs (something even people with more than 4MB want) should take >>care of this. >>-- > >It really shouldn't. I think that what is needed is a "bootload" kernel and >a "generic" >kernel. While its ok for the generic kernel to be large, the "bootload" >should allow someone to >load the system and compile (or load) a custom kernel, which can be much >smaller. There's no >reason why the generic kernel has to be used on the boot floppy. I respectfully disagree. ;-) The "boot kernel" should have enough glue to load LKMs for anything from NFS support to your favorite SCSI driver off of the boot floppy (or even additional floppies). The LKM for device drivers should have an entry point that lets you determine presence of the hardware before committing the whole module to memory. In this way, a "generic" boot floppy could cycle through all LKMs asking them to do the probe and only load the full module (or perhaps unload the module in the event of failure) if the probe is successful. In this way, the only way you'd not be able to install in a low memory configuration is if you had everything but the kitchen sink in your machine. I want to move toward a more dynamic system where in most cases you don't have to recompile the kernel to get the right configuration for you system. LKMs seem the natural solution. >Dennis >---------------------------------------------------------------------------- >Emerging Technologies, Inc. http://www.etinc.com > >Synchronous Communications Cards and Routers For >Discriminating Tastes. 56k to T1 and beyond. Frame >Relay, PPP, HDLC, and X.25 > -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Sep 30 12:11:32 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA12550 for hackers-outgoing; Sat, 30 Sep 1995 12:11:32 -0700 Received: from icicle (root@icicle.winternet.com [198.174.169.5]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA12544 for ; Sat, 30 Sep 1995 12:11:29 -0700 Received: from subzero (glen@subzero.winternet.com [198.174.169.6]) by icicle (8.6.12/8.6.12) with ESMTP id OAA01081 for ; Sat, 30 Sep 1995 14:11:28 -0500 Received: (from glen@localhost) by subzero (8.6.12/8.6.12) id OAA00320 for hackers@freefall.freebsd.org; Sat, 30 Sep 1995 14:11:27 -0500 Date: Sat, 30 Sep 1995 14:11:27 -0500 From: Glen Overby Posted-Date: Sat, 30 Sep 1995 14:11:27 -0500 Message-Id: <199509301911.OAA00320@subzero> To: hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Sender: owner-hackers@FreeBSD.org Precedence: bulk Jordan wrote: >We really need to get the dynamic device driver issue > on the road if we're to ever have any hope at all in running on > small memory machines for the forseeable future. Perhaps one Let's hold on to this thought for a moment: what is preventing this from happening *today*? For the moment, forget the additional problems of doing this in the installation process. Glen From owner-freebsd-hackers Sat Sep 30 12:41:27 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13806 for hackers-outgoing; Sat, 30 Sep 1995 12:41:27 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13800 for ; Sat, 30 Sep 1995 12:41:23 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA12703; Sun, 1 Oct 1995 05:40:41 +1000 Date: Sun, 1 Oct 1995 05:40:41 +1000 From: Bruce Evans Message-Id: <199509301940.FAA12703@godzilla.zeta.org.au> To: glen@winternet.com, hackers@freefall.FreeBSD.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Sender: owner-hackers@FreeBSD.org Precedence: bulk >>We really need to get the dynamic device driver issue >> on the road if we're to ever have any hope at all in running on >> small memory machines for the forseeable future. Perhaps one >Let's hold on to this thought for a moment: what is preventing this >from happening *today*? For the moment, forget the additional >problems of doing this in the installation process. 150000 lines of old drivers that don't support hot probing, attaching or detaching. Bruce From owner-freebsd-hackers Sat Sep 30 12:42:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA13873 for hackers-outgoing; Sat, 30 Sep 1995 12:42:36 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA13868 for ; Sat, 30 Sep 1995 12:42:32 -0700 Received: from trumpet.etnet.com (trumpet.etnet.com [129.45.17.35]) by etinc.com (8.6.11/8.6.9) with SMTP id PAA06042; Sat, 30 Sep 1995 15:45:04 -0400 Date: Sat, 30 Sep 1995 15:45:04 -0400 Message-Id: <199509301945.PAA06042@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Justin T. Gibbs" From: dennis@etinc.com (dennis) Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: jkh@time.cdrom.com, hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >>>Fixing LKMs (something even people with more than 4MB want) should take >>>care of this. >>>-- >> >>It really shouldn't. I think that what is needed is a "bootload" kernel and >>a "generic" >>kernel. While its ok for the generic kernel to be large, the "bootload" >>should allow someone to >>load the system and compile (or load) a custom kernel, which can be much >>smaller. There's no >>reason why the generic kernel has to be used on the boot floppy. > >I respectfully disagree. ;-) > >The "boot kernel" should have enough glue to load LKMs for anything from >NFS support to your favorite SCSI driver off of the boot floppy (or even >additional floppies). The LKM for device drivers should have an entry >point that lets you determine presence of the hardware before committing >the whole module to memory. In this way, a "generic" boot floppy could >cycle through all LKMs asking them to do the probe and only load the full >module (or perhaps unload the module in the event of failure) if the probe >is successful. In this way, the only way you'd not be able to install >in a low memory configuration is if you had everything but the kitchen >sink in your machine. > >I want to move toward a more dynamic system where >in most cases you don't have to recompile the kernel to get the right >configuration for you system. LKMs seem the natural solution. This is a lofty goal that requires not only that LKMs be substantially improved, but that every driver (almost) be implemented as a loadable module and that the modules be extremely clean and non-destrucitve. While this is certainly possible, its not a solution for today or even a very near tomorrow. I still don't think that the wavelengths are in sync here. What you've described is a pretty neat "smart kernel" that could be used generically by just about anyone, and it is an excellent goal. It seems, however, that the problem at hand is that the basic requirement for loading a system initially is greater than that of the systems that many of us will be running. The goal of the initial load of a unix system is to get a running system with enough tools to build an appropriate system for a growing number of devices. The generic kernel has little value after the load as no-one who knows what they're doing is going to use it. While requiring that those that can't build a kernel to have 8MB is OK, making it a basic requirement is creates a major problem. If it were unavoidable, that is one thing, but the "I can't do it by Sunday" is another. My guess is that everyone who "has to have 2.1" already has it or something close to it, so it seems that forcing something out that is clearly not ready to meet some sort of self-imposed deadline will defeat its own purpose in the long run. From a purely marketing standpoint, there is a mindset about memory requirements (created mostly by Microsoft) that the "minimum requirement" is not enough. If you have a product that "requires 8MB" it will be assumed that you need 12 or 16. There is a significant marketing advantage to be able to say that it will run with 4MB (which it will)...saying "but you need 8 to load it" is pretty hard to explain. Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Sep 30 12:46:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA14017 for hackers-outgoing; Sat, 30 Sep 1995 12:46:37 -0700 Received: from aslan.cdrom.com (aslan.cdrom.com [192.216.223.142]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA14012 for ; Sat, 30 Sep 1995 12:46:36 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by aslan.cdrom.com (8.6.12/8.6.9) with SMTP id MAA00312; Sat, 30 Sep 1995 12:46:09 -0700 Message-Id: <199509301946.MAA00312@aslan.cdrom.com> X-Authentication-Warning: aslan.cdrom.com: Host localhost.cdrom.com didn't use HELO protocol To: dennis@etinc.com (dennis) cc: "Justin T. Gibbs" , jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 15:45:04 EDT." <199509301945.PAA06042@etinc.com> Date: Sat, 30 Sep 1995 12:46:08 -0700 From: "Justin T. Gibbs" Sender: owner-hackers@freebsd.org Precedence: bulk >>>>Fixing LKMs (something even people with more than 4MB want) should take >>>>care of this. >>>>-- >>> >>>It really shouldn't. I think that what is needed is a "bootload" kernel and >>>a "generic" >>>kernel. While its ok for the generic kernel to be large, the "bootload" >>>should allow someone to >>>load the system and compile (or load) a custom kernel, which can be much >>>smaller. There's no >>>reason why the generic kernel has to be used on the boot floppy. >> >>I respectfully disagree. ;-) >> >>The "boot kernel" should have enough glue to load LKMs for anything from >>NFS support to your favorite SCSI driver off of the boot floppy (or even >>additional floppies). The LKM for device drivers should have an entry >>point that lets you determine presence of the hardware before committing >>the whole module to memory. In this way, a "generic" boot floppy could >>cycle through all LKMs asking them to do the probe and only load the full >>module (or perhaps unload the module in the event of failure) if the probe >>is successful. In this way, the only way you'd not be able to install >>in a low memory configuration is if you had everything but the kitchen >>sink in your machine. >> >>I want to move toward a more dynamic system where >>in most cases you don't have to recompile the kernel to get the right >>configuration for you system. LKMs seem the natural solution. > >This is a lofty goal that requires not only that LKMs be substantially >improved, but that every >driver (almost) be implemented as a loadable module and that the modules be >extremely clean and non-destrucitve. While this is certainly possible, its >not a solution for today I never said that it was a solution for today... only that fixing LKMs properly should make this problem "go-away". How Jordan deals with making 2.1 install in 4MB is his business. The rest of us can work on making my "lofty goal" a reality for 2.2 or 2.3. -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Sat Sep 30 13:54:37 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA16872 for hackers-outgoing; Sat, 30 Sep 1995 13:54:37 -0700 Received: from Wit401402.student.utwente.nl (Wit401402.student.utwente.nl [130.89.236.162]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA16863 for ; Sat, 30 Sep 1995 13:54:32 -0700 Received: (from alain@localhost) by Wit401402.student.utwente.nl (8.6.12/8.6.9) id VAA00655; Sat, 30 Sep 1995 21:54:16 +0100 Date: Sat, 30 Sep 1995 21:54:16 +0100 (MET) From: Alain Kalker Reply-To: A.C.P.M.Kalker@student.utwente.nl To: Bruce Evans cc: hackers@freebsd.org, julian@ref.tfs.com Subject: Re: correctness of isa.c In-Reply-To: <199509301130.VAA32657@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Sat, 30 Sep 1995, Bruce Evans wrote: > >(also while we're about it, why is id_irq a bitfield? > >it's almost believable, but is there a really good reason?) > > There is no good reason, at least now. The bitmap is more general > except it doesn't allow out of bounds values, but nothing uses the > flexibility, and lots of things assume that only one bit is set > (things that do ffs(id_irq) won't work right if multiple bits are > set). > > Bruce > Any chance of making id_drq a bitfield as well? This would solve the problems that will arise when writing drivers for the next generation multimedia add-on boards which use multiple DMA channels. In fact the problem already exists in the sound driver, which currently (ab)uses id_flags for a second DMA channel. --- Alain From owner-freebsd-hackers Sat Sep 30 15:09:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA20352 for hackers-outgoing; Sat, 30 Sep 1995 15:09:20 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA20345 for ; Sat, 30 Sep 1995 15:09:18 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA18818; Sat, 30 Sep 1995 15:03:56 -0700 From: Terry Lambert Message-Id: <199509302203.PAA18818@phaeton.artisoft.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: glen@winternet.com (Glen Overby) Date: Sat, 30 Sep 1995 15:03:56 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <199509301911.OAA00320@subzero> from "Glen Overby" at Sep 30, 95 02:11:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3854 Sender: owner-hackers@FreeBSD.org Precedence: bulk > >We really need to get the dynamic device driver issue > > on the road if we're to ever have any hope at all in running on > > small memory machines for the forseeable future. Perhaps one > > Let's hold on to this thought for a moment: what is preventing this > from happening *today*? For the moment, forget the additional > problems of doing this in the installation process. 1) There is adamant opposition to a symbol resolution facility in the kernel itself. 2) Without a symbol resoloution facility in the kernel itself, there is no way to cause demand loading short of a fully running system causing a daemon to do the loading. 3) Symbol resoloution implies that the exported kernel interfaces must have symbol information available to the resolver. Actually, I see no reason why kernel level file I/O can not be used to get this information from the kernel file, though keeping in the kernel itself will accomplish two worth goals: a) It will be faster b) It will be possible to limit the exported interfaces to less than the full list of kernel symbols, making less risky to make large scal kernel changes by reducing the exposed entry points. Typically, I believe that one of the largest exposures is in disk and CD ROM drivers. The disk interface lends itself to a "fallback" BIOS-based interface for initial load, to be followed by demand-loading of controller specific drivers. This facility would greatly reduce kernel size, but would require that the VM86() interface be expanded sufficiently to support BIOS-based single-threaded disk drivers to allow loading up to the point of loading the protected mode drivers via the VM86 int21 and/or int13 interfaces. The cdrom facility is problematic, since CDROMs do not typically hook a defined interface at POST time. Therefore, there must be static kernels available for CDROM loading, or a DOS-based facility for assembling a non-CDROM boot disk with apropriate loadable drivers on an FDC file system (the FDC *must* remain statically there, unless it, too, is accessed via BIOS). This second option would mean that a 4M "bootable" CDROM was not a possibility. Because of the inability to mount MFS over static configuration areas, both because of the configuration architecture itself and the lack of fully functional file system interfaces for doing this, a bootable CDROM is not currently an option in any case (unless it does not support net operation at all). The operation of the demand loading facility requires the ability to load-probe-unload to keep the kernel size small. This in general has the effect of implying that the kernel lives in a virtual map, and that one can logically seperate by zone the driver load location from the physical load address. This makes it easy to discard a driver, or even cause the kernel to accept page faults to get the driver in for media which is non-system critical. The resolves the issue of needing to do a load of probe code seperate from the driver code itself. Further, using segment designation, the probe code and possibly the attach code can be discarded after use (depending on how seriously one want to take the idea of plug-n-play device dynamic configuration -- ie: PCMCIA cards). Similarly, the detach routine may in fact be left unloaded until such time as it is needed, assuming segment designation in the object format. In short, it is possible to do, but how much effort would be required is dependent on how agressively the issues are to be attacked. I'd like to see some mechanism for kernel virtual address space zone designation and kernel page fault handling, as well as more VM86() work before the idea demand loading is taken very seriously. 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 Sep 30 15:20:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA20732 for hackers-outgoing; Sat, 30 Sep 1995 15:20:33 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA20727 for ; Sat, 30 Sep 1995 15:20:31 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA18839; Sat, 30 Sep 1995 15:14:39 -0700 From: Terry Lambert Message-Id: <199509302214.PAA18839@phaeton.artisoft.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: dennis@etinc.com (dennis) Date: Sat, 30 Sep 1995 15:14:39 -0700 (MST) Cc: gibbs@freefall.freebsd.org, jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: <199509301945.PAA06042@etinc.com> from "dennis" at Sep 30, 95 03:45:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1333 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > but that every > driver (almost) be implemented as a loadable module and that the modules be > extremely clean and non-destrucitve. In theory, with the recent SYSINT changes are fully propagated, there will be no code differences between a set of driver objects "ld -r"'ed into a single object for later static linking in a kernel and a set of driver objects "ld -r"'ed into a single object for later dynamic loading. The issue in this regard is the devfs registration mechanism and whether or not the need for a backing store can be completely removed from the devfs. Part of the support for this is the support for multiple "root" device mounts (a relatively trivial set of changes, though somewhat broadly strewn) and loopback mounting -- required to have the ability to mount the devfs first thing, but not as the file system root, an then mount the file system root using the devfs name space, then loopback mount the devfs onto /dev. An alternate approach might be to support a "frame" file system that is implicitly mounted, and then loopback/union mount / on its /, leaving the /dev intact in the process and falling through to the devfs as a covered vnode of /dev in the frame. 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 Sep 30 15:22:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA20848 for hackers-outgoing; Sat, 30 Sep 1995 15:22:53 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA20843 for ; Sat, 30 Sep 1995 15:22:52 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id PAA01183; Sat, 30 Sep 1995 15:22:33 -0700 From: Julian Elischer Message-Id: <199509302222.PAA01183@ref.tfs.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 30 Sep 1995 15:22:33 -0700 (PDT) Cc: luigi@labinfo.iet.unipi.it, hackers@freefall.freebsd.org In-Reply-To: <20482.812479445@time.cdrom.com> from "Jordan K. Hubbard" at Sep 30, 95 09:44:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 208 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I just don't want to have to go down that road myself - I have too > many larger install issues to worry about between now and next Sunday. nope.. this just became the largest issue > > Jordan > From owner-freebsd-hackers Sat Sep 30 15:27:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA21053 for hackers-outgoing; Sat, 30 Sep 1995 15:27:14 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA21048 for ; Sat, 30 Sep 1995 15:27:13 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id PAA01200; Sat, 30 Sep 1995 15:26:32 -0700 From: Julian Elischer Message-Id: <199509302226.PAA01200@ref.tfs.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: dennis@etinc.com (dennis) Date: Sat, 30 Sep 1995 15:26:32 -0700 (PDT) Cc: gibbs@freefall.freebsd.org, hackers@freebsd.org, jkh@time.cdrom.com In-Reply-To: <199509301848.OAA05922@etinc.com> from "dennis" at Sep 30, 95 02:48:25 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1535 Sender: owner-hackers@freebsd.org Precedence: bulk > > >>All I can say is this: If we can get things back to below the 4MB > >>boundry then that will be fine and dandy, but we WILL be back here > >>again. We really need to get the dynamic device driver issue > >>on the road if we're to ever have any hope at all in running on > >>small memory machines for the forseeable future. Perhaps one > >>or more of the last 4MB hold-outs will see necessity as the > >>mother of invention and start working on this? :) > >> > >> Jordan > > > >Fixing LKMs (something even people with more than 4MB want) should take > >care of this. > >-- > > It really shouldn't. I think that what is needed is a "bootload" kernel and > a "generic" > kernel. While its ok for the generic kernel to be large, the "bootload" > should allow someone to > load the system and compile (or load) a custom kernel, which can be much > smaller. There's no > reason why the generic kernel has to be used on the boot floppy. and it already isn't.. the kernel on the floppy is compiled seperatly, using a config file automatically derived from GENERIC.. certainly we can generate a couple of different boot floppies, by just duplicating that code in the Makefile and changing what gets deleted from the GENERIC config.. > > Dennis > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com > > Synchronous Communications Cards and Routers For > Discriminating Tastes. 56k to T1 and beyond. Frame > Relay, PPP, HDLC, and X.25 > > From owner-freebsd-hackers Sat Sep 30 15:29:48 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA21160 for hackers-outgoing; Sat, 30 Sep 1995 15:29:48 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA21155 for ; Sat, 30 Sep 1995 15:29:46 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id PAA01215; Sat, 30 Sep 1995 15:29:41 -0700 From: Julian Elischer Message-Id: <199509302229.PAA01215@ref.tfs.com> Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sat, 30 Sep 1995 15:29:41 -0700 (PDT) Cc: dennis@etinc.com, gibbs@freefall.freebsd.org, hackers@freebsd.org, jkh@time.cdrom.com In-Reply-To: <199509301854.LAA29955@aslan.cdrom.com> from "Justin T. Gibbs" at Sep 30, 95 11:54:16 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1803 Sender: owner-hackers@freebsd.org Precedence: bulk > > agree wioth you, but we're talking about what can be done before 2.1 to save ourselves from certain embarasment and a possible fatal flaw it's not just how much is needed to install. but people ask "How efficiently does it use RAM?" and thelinux people say. "Well FreeBSD doesn't even install in 4MB" and the user goes to Linux.. (misleading, but must marketting is..) > I respectfully disagree. ;-) > > The "boot kernel" should have enough glue to load LKMs for anything from > NFS support to your favorite SCSI driver off of the boot floppy (or even > additional floppies). The LKM for device drivers should have an entry > point that lets you determine presence of the hardware before committing > the whole module to memory. In this way, a "generic" boot floppy could > cycle through all LKMs asking them to do the probe and only load the full > module (or perhaps unload the module in the event of failure) if the probe > is successful. In this way, the only way you'd not be able to install > in a low memory configuration is if you had everything but the kitchen > sink in your machine. > > I want to move toward a more dynamic system where > in most cases you don't have to recompile the kernel to get the right > configuration for you system. LKMs seem the natural solution. > > >Dennis > >---------------------------------------------------------------------------- > >Emerging Technologies, Inc. http://www.etinc.com > > > >Synchronous Communications Cards and Routers For > >Discriminating Tastes. 56k to T1 and beyond. Frame > >Relay, PPP, HDLC, and X.25 > > > > -- > Justin T. Gibbs > =========================================== > Software Developer - Walnut Creek CDROM > FreeBSD: Turning PCs into workstations > =========================================== > From owner-freebsd-hackers Sat Sep 30 16:19:10 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA22693 for hackers-outgoing; Sat, 30 Sep 1995 16:19:10 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA22687 for ; Sat, 30 Sep 1995 16:19:07 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA21810; Sat, 30 Sep 1995 16:18:52 -0700 To: Julian Elischer cc: luigi@labinfo.iet.unipi.it, hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 15:22:33 PDT." <199509302222.PAA01183@ref.tfs.com> Date: Sat, 30 Sep 1995 16:18:51 -0700 Message-ID: <21807.812503131@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > > many larger install issues to worry about between now and next Sunday. > nope.. this just became the largest issue ONLY if we make it the largest issue. I have no desire to do so personally, and if you're really so fired up about it, well, you have the source too! :-) Jordan From owner-freebsd-hackers Sat Sep 30 18:07:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA24888 for hackers-outgoing; Sat, 30 Sep 1995 18:07:50 -0700 Received: from etinc.com (etinc-gw.new-york.net [165.254.13.209]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA24879 for ; Sat, 30 Sep 1995 18:07:47 -0700 Received: from websurfer.etinc.com (websurfer.etinc.com [204.141.95.5]) by etinc.com (8.6.11/8.6.9) with SMTP id VAA06576; Sat, 30 Sep 1995 21:10:30 -0400 Date: Sat, 30 Sep 1995 21:10:30 -0400 Message-Id: <199510010110.VAA06576@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Jordan K. Hubbard" From: dennis@etinc.com (dennis) Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> > many larger install issues to worry about between now and next Sunday. >> nope.. this just became the largest issue > >ONLY if we make it the largest issue. I have no desire to do so >personally, and if you're really so fired up about it, well, you >have the source too! :-) > > Jordan > This is why there's Redhat, Debian, Slackware, etc....... Is FreeBSD going the same route as Linux??????? Dennis ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25 From owner-freebsd-hackers Sat Sep 30 18:23:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA25202 for hackers-outgoing; Sat, 30 Sep 1995 18:23:59 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA25197 for ; Sat, 30 Sep 1995 18:23:51 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id SAA22009; Sat, 30 Sep 1995 18:23:40 -0700 To: dennis@etinc.com (dennis) cc: hackers@freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 1995 21:10:30 EDT." <199510010110.VAA06576@etinc.com> Date: Sat, 30 Sep 1995 18:23:40 -0700 Message-ID: <22006.812510620@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > >ONLY if we make it the largest issue. I have no desire to do so > >personally, and if you're really so fired up about it, well, you > >have the source too! :-) > > > This is why there's Redhat, Debian, Slackware, etc....... Is FreeBSD going > the same route as Linux??????? That's not what was meant. What was meant was that Julian could dive on the problem if he so wished. I hardly expected him to go roll JulianBSD because of it.. :-) Jordan From owner-freebsd-hackers Sat Sep 30 18:32:36 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA25394 for hackers-outgoing; Sat, 30 Sep 1995 18:32:36 -0700 Received: from mercury.unt.edu (mercury.unt.edu [129.120.1.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id SAA25378 ; Sat, 30 Sep 1995 18:32:30 -0700 Received: from gab.unt.edu by mercury.unt.edu with SMTP id AA20948 (5.65c/IDA-1.4.4); Sat, 30 Sep 1995 20:32:28 -0500 Received: from GAB/SpoolDir by gab.unt.edu (Mercury 1.21); 30 Sep 95 20:32:28 CST6CDT Received: from SpoolDir by GAB (Mercury 1.21); 30 Sep 95 20:32:23 CST6CDT From: "John Booth" Organization: University of North Texas To: hackers@freebsd.org, questions@freebsd.org Date: Sat, 30 Sep 1995 20:32:22 CST6CDT Subject: multiple sendmail and inetd's Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1A418243C05@gab.unt.edu> Sender: owner-hackers@freebsd.org Precedence: bulk I'm running the 2.1 950726 Snap and after 10 day or so uptimes the machine dies (pings, but is so slow it won't accept telnets and console is basically dead dont' know how fast this happens) going to the kernel debugger and listing processes shows ~30-50 inetd's and sendmails running. Has anyone else noticed this? Anyone have any ideas? Is this a known problem? ---------------------------------------------------------------------- College of Arts & Sciences Computing Services John A. Booth, john@gab.unt.edu From owner-freebsd-hackers Sat Sep 30 19:59:33 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA28708 for hackers-outgoing; Sat, 30 Sep 1995 19:59:33 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA28702 for ; Sat, 30 Sep 1995 19:59:27 -0700 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id WAA24028 for hackers@freebsd.org; Sat, 30 Sep 1995 22:57:46 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id WAA12297; Sat, 30 Sep 1995 22:54:48 -0400 Date: Sat, 30 Sep 1995 22:54:48 -0400 From: Gene Stark Message-Id: <199510010254.WAA12297@starkhome.cs.sunysb.edu> To: hackers@freebsd.org Subject: Problems with VAT and Sound Code Sender: owner-hackers@freebsd.org Precedence: bulk Even with the sound code now in -stable, I am still unable to get VAT to work with an SB-16. The symptom is that there is no sound. If you select one of the audio tests, you hear nothing until you delete the VAT window, at which time there is a very brief spurt of the test tone. During the time there is no sound in the speakers, VAT appears to operate normally. If you talk into the mike you can see the little level meter bounce around, etc. A ps on VAT indicates it is spending its time in select. On the off chance that I might spot a problem in the audio select() code, I started looking at that part of the drivers. My first impression is that there are a *lot* of potential race conditions due to incorrect positioning of DISABLE_INTR and ENABLE_INTR. For example, in audio.c (line 494) we have: if (wr_buff_no[dev] != -1) return 1; /* There is space in the current buffer */ return DMAbuf_select (dev, file, sel_type, wait); break; However, interrupts are not disabled, leaving the possibility of a race if an interrupt occurs between testing no space in the buffer and sleeping in DMAbuf_select(). In dmabuf.c (line 986) we have: if (!space_in_queue (dev)) { DISABLE_INTR (flags); #if defined(__FreeBSD__) selrecord(wait, &selinfo[dev]); #else dev_sleep_flag[dev].mode = WK_SLEEP; select_wait (&dev_sleeper[dev], wait); #endif RESTORE_INTR (flags); return 0; } return 1; break; Again, the queue space is being checked outside of the critical section, allowing a race and potential indefinite sleep. Of course, my impressions here could be due to the fact that I am not familiar with the code (just started looking at it), but it sure looks like trouble to me. Can anyone confirm or refute the correctness of these observations? I thought by now most of the drivers with incorrect handling of critical sections had been rooted out and fixed. - Gene Stark From owner-freebsd-hackers Sat Sep 30 20:16:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA29308 for hackers-outgoing; Sat, 30 Sep 1995 20:16:20 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA29301 for ; Sat, 30 Sep 1995 20:16:13 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA04542; Sat, 30 Sep 1995 20:14:38 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id UAA05028; Sat, 30 Sep 1995 20:15:51 -0700 Message-Id: <199510010315.UAA05028@corbin.Root.COM> To: Terry Lambert cc: glen@winternet.com (Glen Overby), hackers@freefall.freebsd.org Subject: Re: FreeBSD 2.1 will require a minimum of 8MB for installation. In-reply-to: Your message of "Sat, 30 Sep 95 15:03:56 PDT." <199509302203.PAA18818@phaeton.artisoft.com> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 30 Sep 1995 20:15:50 -0700 Sender: owner-hackers@FreeBSD.org Precedence: bulk >1) There is adamant opposition to a symbol resolution facility > in the kernel itself. There is? Certainly not from me. The only reservation I've ever raised about this is that the symbols consume about 100K of memory and on a 4MB machine, this is a lot. Personally, I'd really like to see the symbols in the kernel address space. This would make things like symbolic tracebacks possible in the standard non-DDB case. This would go a long way toward making it easier to troubleshoot kernel panics. How many times have you seen me say "do an nm /kernel | sort and tell me what function the IP is within"? Dozens, and I'm getting tired of saying it!. -DG From owner-freebsd-hackers Sat Sep 30 21:26:57 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA03657 for hackers-outgoing; Sat, 30 Sep 1995 21:26:57 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA03652 for ; Sat, 30 Sep 1995 21:26:55 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id VAA00283; Sat, 30 Sep 1995 21:25:50 -0700 Message-Id: <199510010425.VAA00283@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Gene Stark cc: hackers@freebsd.org, multimedia@star-gate.com Subject: Re: Problems with VAT and Sound Code In-reply-to: Your message of "Sat, 30 Sep 1995 22:54:48 EDT." <199510010254.WAA12297@starkhome.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 1995 21:25:49 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@freebsd.org Precedence: bulk Hmm... Have you considered using vmix with vat? Amancio >>> Gene Stark said: > Even with the sound code now in -stable, I am still unable to get VAT > to work with an SB-16. The symptom is that there is no sound. If you > select one of the audio tests, you hear nothing until you delete the > VAT window, at which time there is a very brief spurt of the test tone. > During the time there is no sound in the speakers, VAT appears to operate > normally. If you talk into the mike you can see the little level meter > bounce around, etc. A ps on VAT indicates it is spending its time in > select. > > On the off chance that I might spot a problem in the audio select() > code, I started looking at that part of the drivers. My first impression > is that there are a *lot* of potential race conditions due to incorrect > positioning of DISABLE_INTR and ENABLE_INTR. > > For example, in audio.c (line 494) we have: > > if (wr_buff_no[dev] != -1) > return 1; /* There is space in the current buffer */ > > return DMAbuf_select (dev, file, sel_type, wait); > break; > > However, interrupts are not disabled, leaving the possibility of a > race if an interrupt occurs between testing no space in the buffer > and sleeping in DMAbuf_select(). > > In dmabuf.c (line 986) we have: > > if (!space_in_queue (dev)) > { > DISABLE_INTR (flags); > #if defined(__FreeBSD__) > selrecord(wait, &selinfo[dev]); > #else > dev_sleep_flag[dev].mode = WK_SLEEP; > select_wait (&dev_sleeper[dev], wait); > #endif > RESTORE_INTR (flags); > return 0; > } > return 1; > break; > > Again, the queue space is being checked outside of the critical section, > allowing a race and potential indefinite sleep. > > Of course, my impressions here could be due to the fact that I am not > familiar with the code (just started looking at it), but it sure looks > like trouble to me. > > Can anyone confirm or refute the correctness of these observations? > I thought by now most of the drivers with incorrect handling of critical > sections had been rooted out and fixed. > > - Gene Stark > From owner-freebsd-hackers Sat Sep 30 21:55:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id VAA05088 for hackers-outgoing; Sat, 30 Sep 1995 21:55:59 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA05083 for ; Sat, 30 Sep 1995 21:55:57 -0700 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id AAA24127; Sun, 1 Oct 1995 00:54:17 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id AAA12550; Sun, 1 Oct 1995 00:55:20 -0400 Date: Sun, 1 Oct 1995 00:55:20 -0400 From: Gene Stark Message-Id: <199510010455.AAA12550@starkhome.cs.sunysb.edu> To: rah.star-gate.com!hasty@sbstark.cs.sunysb.edu CC: freebsd.org!hackers@sbstark.cs.sunysb.edu, star-gate.com!multimedia@sbstark.cs.sunysb.edu In-reply-to: <199510010425.VAA00283@rah.star-gate.com> (rah.star-gate.com!hasty@sbstark.cs.sunysb.edu) Subject: Re: Problems with VAT and Sound Code Sender: owner-hackers@FreeBSD.org Precedence: bulk >Have you considered using vmix with vat? For what purpose? (Please elaborate...) From owner-freebsd-hackers Sat Sep 30 22:02:28 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA05288 for hackers-outgoing; Sat, 30 Sep 1995 22:02:28 -0700 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA05281 for ; Sat, 30 Sep 1995 22:02:25 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with ESMTP id BAA24131; Sun, 1 Oct 1995 01:00:44 -0400 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.9) with ESMTP id WAA00697; Sat, 30 Sep 1995 22:02:14 -0700 Message-Id: <199510010502.WAA00697@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Gene Stark cc: rah.star-gate.com!hasty@sbstark.cs.sunysb.edu, freebsd.org!hackers@sbstark.cs.sunysb.edu, star-gate.com!multimedia@sbstark.cs.sunysb.edu Subject: Re: Problems with VAT and Sound Code In-reply-to: Your message of "Sun, 01 Oct 1995 00:55:20 EDT." <199510010455.AAA12550@starkhome.cs.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 1995 22:02:13 -0700 From: "Amancio Hasty Jr." Sender: owner-hackers@FreeBSD.org Precedence: bulk >>> Gene Stark said: > >Have you considered using vmix with vat? > > For what purpose? (Please elaborate...) For the purpose of using vat: vat -u /tmp/vatsock vmix vmix communicates with vat via its socket interface for playing and recording. Here is a section of Jim Lowe's posting: ersion 3 of the sound code is now in 2.1-stable and 2.2-current. I also put together the sound code and some other tid bits into a tar file. Both the sound tar file and vmix.0.3 are available from: ftp://ftp.cs.uwm.edu/pub/FreeBSD/ The sound code package is in sound.v30.9-19-95.tar.gz. Vmix is in the file vmix.0.3.tar.gz. If you need tk/tcl, check 2.0.5-RELEASE/packages/All. If you have any further questions, subscribe to the multimedia mailing list: mail majordomo@star-gate.com subscribe multimedia Amancio From owner-freebsd-hackers Sat Sep 30 22:56:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA07661 for hackers-outgoing; Sat, 30 Sep 1995 22:56:54 -0700 Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.10]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA07623 for ; Sat, 30 Sep 1995 22:56:34 -0700 Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma005887; Sun Oct 1 15:53:27 1995 Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail_gw.telecom.com.au via smap (V1.3) id sma021272; Sun Oct 1 15:53:13 1995 Received: from amalfi.trl.OZ.AU (amalfi.trl.OZ.AU [137.147.99.99]) by cdn_mail.dn.itg.telecom.com.au (8.6.11/8.6.9) with ESMTP id PAA15385; Sun, 1 Oct 1995 15:52:56 +1000 Received: from orca1.vic.design.telecom.com.au ([145.136.55.131]) by amalfi.trl.OZ.AU (8.6.10/8.6.12) with SMTP id LAA15844; Sun, 1 Oct 1995 11:34:41 +1000 Received: from netbsd08.dn.itg.telecom.com.au by orca1.vic.design.telecom.com.au with SMTP (1.37.109.4/16.2) id AA19497; Sun, 1 Oct 95 11:33:52 +1000 Received: from netbsd08.dn.itg.telecom.com.au (netbsd08.dn.itg.telecom.com.au [144.139.63.32]) by netbsd08.dn.itg.telecom.com.au (8.6.8/8.6.6) with SMTP id JAA24466; Sun, 1 Oct 1995 09:33:47 +0759 Date: Sun, 1 Oct 1995 09:33:46 +0800 (WST) From: Terry Dwyer To: Sean Kelly Cc: imb@scgt.oz.au, hackers@FreeBSD.ORG Subject: Re: Low end PS laser, or inkjet/bubblejet In-Reply-To: <9509281304.AA09023@emu.fsl.noaa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG Precedence: bulk [ deleted ] > > michael> Whilst not directly related .. I run a pair of HP4s (one > michael> M+ and one MV for A3 printing) with JetDirect cards and, > michael> therefore, an "rm" entry in /etc/printcap. What surprised > michael> me was that I don't seem to be able to get any filters to > michael> preprocess the stuff before shooting it at the printer. > > Ah, yep. The LPD protocol says that filtering of jobs happens on the > printer host. And if the printer host is itself the printer, it's > expected to have enough smarts to know how to convert DVI, troff, > ditroff, cifplot, Fortran Text, etc., to native format. > > michael> Is this what's supposed to happen ? How do I fix it ? :-) > > Oh, I'm sure it's not what you wanted! You can fix it if your > JetDirect card also supports non-server (LPD) mode---if it just has > some data stream mode, where it listens to a certain port number and > prints any data that comes in, rather than emulate a spooling host. > > If it can do that, then set up on of your FreeBSD hosts to be the > printer host. Then you can have the conversion filters for the > formats you want to support. Have them send their results to the > printer. > > Or, use PLP or LPRng, which support filtering of jobs on the > submitting host instead of the printer host---then you can still use > the server mode on the printer. > I saw a tip some time ago. try these printcap entries for an HP LJ4SI: The key is the rp=text|raw l4si_txt|ASCII remote line printer:\ :sh:lp=:rm=144.139.64.98:rp=text:sd=/var/spool/lpd:\ :lf=var/log/lpd-errs:pw#80: l4si_raw|BINARY remote line printer on witg_networks_f1:\ :sh:lp=:rm=144.139.64.98:rp=raw:sd=/var/spool/lpd:\ :lf=var/log/lpd-errs:pw#80: _-_|\ Terry Dwyer E-Mail: tdwyer@netbsd08.dn.itg.telecom.com.au / \ System Administrator Phone: +61 9 491 5161 Fax: +61 9 221 2631 *_.^\_/ Telecom Australia Telstra Corporation MIME capable mailer v Perth WA ( I do not speak for Telstra or Telecom )