From owner-freebsd-arch Mon Sep 10 1:42: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id D832737B401; Mon, 10 Sep 2001 01:41:39 -0700 (PDT) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 183A01D1AD; Mon, 10 Sep 2001 09:41:36 +0100 (BST) Date: Sat, 08 Sep 2001 14:50:51 +0100 From: Paul Richards To: John Baldwin , Mike Barcroft Cc: arch@FreeBSD.org, Alexander Langer Subject: Re: libh src/ import Message-ID: <952460000.999957051@lobster.originative.co.uk> In-Reply-To: References: X-Mailer: Mulberry/2.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Thursday, September 06, 2001 19:59:28 -0700 John Baldwin wrote: > > On 07-Sep-01 Mike Barcroft wrote: >> John Baldwin writes: >>> On 06-Sep-01 Alexander Langer wrote: >>> > Hi! >>> > >>> > How are peoples feelings about an import of libh into our src tree, >>> > in order to push the development? >>> >>> As I said on IRC in an opinion that no one else seems to share, libh is >>> useful >>> in a wider regard than just FreeBSD, and I think it should be a separate >>> project that gets vendor imported into src/contrib. Let's face it guys, >>> FreeBSD doesn't have a lot of GUI people running around, and if libh is >>> going >>> to fly, it needs developers. IMHO, the best way to get developers for >>> it is to >>> not make it look like some FreeBSD-only thing, but instead to make it >>> inviting >>> to other developers. >> [snip] >> >> FreeBSD is more than just a kernel, you know. I don't think we should >> artificially limit ourselves by your imagination. > > Yes, I'm well aware, and I've been involved with libh (mostly earlier on) > for about a year (not much since then) and I can appreciate it's design > and it's role. Can someone outline how libh is going to fit into a roadmap for FreeBSD of some sort? I've been loosely following the libh list but it's not clear to me what the overall goals are. Are we going to have libh be another sysinstall, in that it's one big lump that is useless for developing other tools or is it going to be a set of modules that other admin tools can be built on top of. Likewise, how much abstraction does it provide for a user interface. Is libh basically a load of tcl scripts and TV or is it a framework that other tools can be built on top of or alongside using Perl or C. Bringing in TCL just for an installer would be a mistake, one we've actually made before and corrected. I don't see any reason to make it again unless there's an actual benefit to it. I also don't understand how much of a dependency there is on QT. I think some more information on what the roadmap looks like is needed before we decide whether to pull all this into our code base. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 2: 0:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from infinitive.futureperfectcorporation.com (curie.sunesi.com [196.25.112.244]) by hub.freebsd.org (Postfix) with SMTP id 3335937B408 for ; Mon, 10 Sep 2001 02:00:27 -0700 (PDT) Received: (qmail 20179 invoked by uid 0); 10 Sep 2001 09:00:20 -0000 Received: from choke.sunesi.net (HELO gerund.futureperfectcorporation.com) (196.25.112.242) by infinitive.futureperfectcorporation.com with SMTP; 10 Sep 2001 09:00:20 -0000 Received: (qmail 79883 invoked by uid 1001); 10 Sep 2001 09:00:58 -0000 Date: Mon, 10 Sep 2001 11:00:58 +0200 From: Neil Blakey-Milner To: Paul Richards Cc: John Baldwin , Mike Barcroft , arch@FreeBSD.org, Alexander Langer Subject: Re: libh src/ import Message-ID: <20010910110057.A79802@mithrandr.moria.org> References: <952460000.999957051@lobster.originative.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <952460000.999957051@lobster.originative.co.uk>; from paul@freebsd-services.com on Sat, Sep 08, 2001 at 02:50:51PM +0100 Organization: iTouch Labs X-Operating-System: FreeBSD 4.3-RELEASE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat 2001-09-08 (14:50), Paul Richards wrote: > Can someone outline how libh is going to fit into a roadmap for FreeBSD of > some sort? I've been loosely following the libh list but it's not clear to > me what the overall goals are. > > Are we going to have libh be another sysinstall, in that it's one big lump > that is useless for developing other tools or is it going to be a set of > modules that other admin tools can be built on top of. > > Likewise, how much abstraction does it provide for a user interface. Is > libh basically a load of tcl scripts and TV or is it a framework that > other tools can be built on top of or alongside using Perl or C. > > Bringing in TCL just for an installer would be a mistake, one we've > actually made before and corrected. I don't see any reason to make it again > unless there's an actual benefit to it. I also don't understand how much of > a dependency there is on QT. > > I think some more information on what the roadmap looks like is needed > before we decide whether to pull all this into our code base. I think http://people.FreeBSD.org/~alex/libh/about.html is a good start to answering these questions. Specifically, it's not one big lump, and it's modular and designed to make it easy for people to make modules for other admin tools. The UI is reasonablly well-abstracted, with rendering to TV and qt available (at build-time at the moment, I think). It has C, C++, and tcl interfaces currently. There is no major dependency on QT; it can build without it. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 2:56:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 4B25A37B403 for ; Mon, 10 Sep 2001 02:56:09 -0700 (PDT) Received: from mail.cicely.de (cicely20 [10.1.1.22]) by srv1.cosmo-project.de (8.11.0/8.11.0) with ESMTP id f8A9u2P48370; Mon, 10 Sep 2001 11:56:03 +0200 (CEST) Received: (from ticso@localhost) by mail.cicely.de (8.11.0/8.11.0) id f8A9uK005061; Mon, 10 Sep 2001 11:56:20 +0200 (CEST) Date: Mon, 10 Sep 2001 11:56:20 +0200 From: Bernd Walter To: Bill Fenner Cc: karels@bsdi.com, arch@FreeBSD.ORG Subject: Re: Causing to depend on Message-ID: <20010910115619.A4979@cicely20.cicely.de> References: <200109072125.OAA25298@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200109072125.OAA25298@windsor.research.att.com>; from fenner@research.att.com on Fri, Sep 07, 2001 at 02:25:02PM -0700 X-Operating-System: NetBSD cicely20.cicely.de 1.5 sparc Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 07, 2001 at 02:25:02PM -0700, Bill Fenner wrote: > > Sorry for making people guess what I was talking about. > > Concretely, http://www.ietf.org/internet-drafts/draft-ietf-idmr-msf-api-02.txt > requires that #including results in definitions like > the following: > > > struct group_req { > uint32_t gr_interface; /* interface index */ > struct sockaddr_storage gr_group; /* group address */ > }; > > struct group_source_req { > uint32_t gsr_interface; /* interface index */ > struct sockaddr_storage gsr_group; /* group address */ > struct sockaddr_storage gsr_source; /* source address */ > }; > > struct group_filter { > uint32_t gf_interface; /* interface index */ > struct sockaddr_storage gf_group; /* multicast address */ > uint32_t gf_fmode; /* filter mode */ > uint32_t gf_numsrc; /* number of sources */ > struct sockaddr_storage gf_slist[1]; /* source address */ > }; If it is defined as protocol independend it doesn't belong into a protocol dependend header. E.g. I don't want to include netinet/in.h in an IPv6 only application. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 4:24:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep11-int.chello.nl (amsfep11-int.chello.nl [213.46.243.19]) by hub.freebsd.org (Postfix) with ESMTP id 69F4737B401; Mon, 10 Sep 2001 04:24:20 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep11-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20010910112139.ZULA28612.amsfep11-int.chello.nl@daemon.chronias.ninth-circle.org>; Mon, 10 Sep 2001 13:21:39 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f8ABL1f83523; Mon, 10 Sep 2001 13:21:01 +0200 (CEST) (envelope-from asmodai) Date: Mon, 10 Sep 2001 13:21:00 +0200 From: Jeroen Ruigrok/Asmodai To: Neil Blakey-Milner Cc: Paul Richards , John Baldwin , Mike Barcroft , arch@FreeBSD.org, Alexander Langer Subject: Re: libh src/ import Message-ID: <20010910132100.F67566@daemon.ninth-circle.org> References: <952460000.999957051@lobster.originative.co.uk> <20010910110057.A79802@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010910110057.A79802@mithrandr.moria.org> User-Agent: Mutt/1.3.19i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20010910 11:30], Neil Blakey-Milner (nbm@mithrandr.moria.org) wrote: >Specifically, it's not one big lump, and it's modular and designed to >make it easy for people to make modules for other admin tools. The UI >is reasonablly well-abstracted, with rendering to TV and qt available >(at build-time at the moment, I think). It has C, C++, and tcl >interfaces currently. There is no major dependency on QT; it can build >without it. So libh without Qt and/or Turbovision will not accomplish anything in the FreeBSD's src tree. Thus far everything in the sourcetree is a library or application on which other applications base their workings or to offer the users tools they need to get their work done. And importing either TCL and/or Turbovision seems rather silly in my opinion. I think people are forgetting that not everything needs to be squeezed in src/* to be part of the Project's development effort. You don't see doc under src do you? What's stopping a new gui or whatever you want to call it to be placed under /usr/installer [to name but an example]? -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ A frightened mental vortex we will be, a Sun we seek, a Sun we flee... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 6: 9: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep12-int.chello.nl (amsfep12-int.chello.nl [213.46.243.17]) by hub.freebsd.org (Postfix) with ESMTP id CA36237B405 for ; Mon, 10 Sep 2001 06:08:57 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep12-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20010910130611.PKPT7460.amsfep12-int.chello.nl@daemon.chronias.ninth-circle.org>; Mon, 10 Sep 2001 15:06:11 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f8AD8hi84307; Mon, 10 Sep 2001 15:08:43 +0200 (CEST) (envelope-from asmodai) Date: Mon, 10 Sep 2001 15:08:42 +0200 From: Jeroen Ruigrok/Asmodai To: Terry Lambert Cc: karels@BSDI.COM, Bill Fenner , arch@FreeBSD.ORG Subject: Re: Causing to depend on Message-ID: <20010910150842.G67566@daemon.ninth-circle.org> References: <200109072110.f87LADX15133@redrock.eng.bsdi.com> <3B9A112D.5909ECE@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B9A112D.5909ECE@mindspring.com> User-Agent: Mutt/1.3.19i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20010908 15:00], Terry Lambert (tlambert2@mindspring.com) wrote: >I haven't seen where the sockaddr_storage type is used, yet >(no one has posted anything), 217 occurences in the /usr/src tree. >but it seems to me that if, when it is used, it is used as an opaque >pointer type, where possible, then this avoids the need to pollute the >namespace unless someone is referencing members of the structure, which >means they are actually using it, which means that they can darn well >include a header file to get the non-opaque version of the structure >declaration so that they can instance the thing. It needs to be defined in [as per POSIX and SUS decree]. ``The sockaddr_storage structure solves the problem of declaring storage for automatic variables which is both large enough and aligned enough for storing the socket address data structure of any family.'' It's an opaque type yes, but for all I know just an opaque struct, not a pointer. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ I search the outside, search inside for you... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 6:40:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from r220-1.rz.RWTH-Aachen.DE (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by hub.freebsd.org (Postfix) with ESMTP id 840EB37B405; Mon, 10 Sep 2001 06:40:37 -0700 (PDT) Received: from r220-1.rz.RWTH-Aachen.DE (relay2.RWTH-Aachen.DE [134.130.3.1]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3-2) with ESMTP id f8ADebc18288; Mon, 10 Sep 2001 15:40:37 +0200 (MEST) Received: from kawoserv.kawo2.rwth-aachen.de (root@kawoserv.kawo2.RWTH-Aachen.DE [134.130.180.1]) by r220-1.rz.RWTH-Aachen.DE (8.10.1/8.11.3/5) with ESMTP id f8ADeau18284; Mon, 10 Sep 2001 15:40:37 +0200 (MEST) Received: from fump.kawo2.rwth-aachen.de (root@fump.kawo2.rwth-aachen.de [134.130.181.148]) by kawoserv.kawo2.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id PAA21276; Mon, 10 Sep 2001 15:40:35 +0200 Received: (from alex@localhost) by fump.kawo2.rwth-aachen.de (8.11.3/8.11.3) id f8ADeh658661; Mon, 10 Sep 2001 15:40:44 +0200 (CEST) (envelope-from alex) Date: Mon, 10 Sep 2001 15:40:43 +0200 From: Alexander Langer To: Jeroen Ruigrok/Asmodai Cc: Neil Blakey-Milner , Paul Richards , John Baldwin , Mike Barcroft , arch@FreeBSD.ORG Subject: Re: libh src/ import Message-ID: <20010910154043.B58618@fump.kawo2.rwth-aachen.de> References: <952460000.999957051@lobster.originative.co.uk> <20010910110057.A79802@mithrandr.moria.org> <20010910132100.F67566@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010910132100.F67566@daemon.ninth-circle.org>; from asmodai@wxs.nl on Mon, Sep 10, 2001 at 01:21:00PM +0200 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Jeroen Ruigrok/Asmodai (asmodai@wxs.nl): > So libh without Qt and/or Turbovision will not accomplish anything in > the FreeBSD's src tree. Wrong. :) libh w/o any GUI library but w/ Tcl (Tcl is mandatory) will bring us a new package system (and brings libdisk/libfetch/database/ file access/MD5 stuff into Tcl at the same time, but that's probably not a strong reason to import it :-) ). GUI parts could be build on release-time, depending on their ports, as "make release" does already anyways. JFYI. Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 7:15:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep15-int.chello.nl (amsfep15-int.chello.nl [213.46.243.27]) by hub.freebsd.org (Postfix) with ESMTP id 9D8B837B405 for ; Mon, 10 Sep 2001 07:15:22 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep15-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20010910141225.VBZR12294.amsfep15-int.chello.nl@daemon.chronias.ninth-circle.org>; Mon, 10 Sep 2001 16:12:25 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f8AEAPH84767; Mon, 10 Sep 2001 16:10:25 +0200 (CEST) (envelope-from asmodai) Date: Mon, 10 Sep 2001 16:10:25 +0200 From: Jeroen Ruigrok/Asmodai To: Bill Fenner Cc: jlemon@flugsvamp.com, arch@freebsd.org Subject: Re: Causing to depend on Message-ID: <20010910161025.H67566@daemon.ninth-circle.org> References: <200109072125.OAA25298@windsor.research.att.com> <3B9A134D.3B31C443@mindspring.com> <200109081858.LAA12165@windsor.research.att.com> <20010908141005.R20137@prism.flugsvamp.com> <200109082022.NAA13321@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200109082022.NAA13321@windsor.research.att.com> User-Agent: Mutt/1.3.19i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20010908 22:26], Bill Fenner (fenner@research.att.com) wrote: > >>It seems that the real problem here is that sockaddr_storage is supposed >>to be protocol-neutral (used for appletalk, IPX, etc), but what your >>code really wants is IP-specific sockaddr_storage. > >Well, sockaddr_storage was introduced to support IPv6; it was defined >to be "at least large enough to accommodate sockaddr_in and sockaddr_in6 >and possibly other protocol specific socket addresses too." [RFC 2553 >section 3.10]. I guess the "and possibly other..." part is what's not >working out, especially since IEEE Std 1003.1-200x gets rid of the "possibly" >part. To help people following this thread: ``The header shall define the sockaddr_storage structure. This structure shall be: * Large enough to accommodate all supported protocol-specific address structures * Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol-specific address structures and used to access the fields of those structures without alignment problems The sockaddr_storage structure shall contain at least the following members: sa_family_t ss_family When a sockaddr_storage structure is cast as a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a sockaddr_storage structure is cast as a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol's address family.'' Courtesy latest POSIX draft. Also interesting as background: http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol/metzprotocol_html/node10.html The above is part of a paper on protocol-independent networking programming for BSD sockets based on the latest standards. In effect this means that all AF_* address families should be able to be supported. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Reincarnate and play the game again, and again, and again... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Sep 10 7:42:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id B36DF37B40A for ; Mon, 10 Sep 2001 07:42:23 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id A13434CE20; Mon, 10 Sep 2001 10:42:19 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA28036; Mon, 10 Sep 2001 10:42:15 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA17411; Mon, 10 Sep 2001 07:42:14 -0700 (PDT) Message-Id: <200109101442.HAA17411@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: ticso@mail.cicely.de Subject: Re: Causing to depend on Cc: arch@freebsd.org References: <200109072125.OAA25298@windsor.research.att.com> <20010910115619.A4979@cicely20.cicely.de> Date: Mon, 10 Sep 2001 07:42:14 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >If it is defined as protocol independend it doesn't belong into a >protocol dependend header. >E.g. I don't want to include netinet/in.h in an IPv6 only application. Tough. is an implementation artifact; the standard place to get IPv6-related stuff (e.g. sockaddr_in6) is . Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Sep 11 6:15:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 33A1D37B405 for ; Tue, 11 Sep 2001 06:15:45 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA29518; Tue, 11 Sep 2001 23:15:33 +1000 Date: Tue, 11 Sep 2001 23:14:27 +1000 (EST) From: Bruce Evans X-X-Sender: To: Bill Fenner Cc: , Subject: Re: Causing to depend on In-Reply-To: <200109101442.HAA17411@windsor.research.att.com> Message-ID: <20010911231012.Q3651-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 10 Sep 2001, Bill Fenner wrote: > >If it is defined as protocol independend it doesn't belong into a > >protocol dependend header. > >E.g. I don't want to include netinet/in.h in an IPv6 only application. > > Tough. is an implementation artifact; the standard > place to get IPv6-related stuff (e.g. sockaddr_in6) is . This place will also be Standard according to POSIX.1-200x drafts. Please make it an #error to #include headers that are artifacts of the implementation in userland. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 10:28:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 12E3237B40E; Thu, 13 Sep 2001 10:27:49 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8DHRgQ06496; Thu, 13 Sep 2001 20:27:42 +0300 (EEST) (envelope-from ru) Date: Thu, 13 Sep 2001 20:27:42 +0300 From: Ruslan Ermilov To: arch@FreeBSD.org, freebsd-standards@bostonradio.org Cc: Bruce Evans , Garrett Wollman Subject: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010913202742.C2458@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Bcc'ed to -current in a hope for a more wider auditory] The attached patch fixes the handling of symlinks in chown(8) and chgrp(1). It is currently broken in many different ways. Basically, it is broken because -h is not supported with -RH or -RL. The actual problem lies in the depths of the fts(3) implementation, in particular, how the `fts_stat' is getting initialized. The trick in supporting roughly any combination of command line flags ([-h] [-R [-H | -L | -P]]) was to avoid looking into the `fts_stat' (as we don't know whether it is from lstat(2) or stat(2)), and just call chown(2) or lchown(2) as appropriate. Although it may seem as a big performance degradation, in fact it isn't, as kernel doesn't modify the inode if nothing is to be changed. This work is based on the latest POSIX drafts, and the superior NetBSD implementation (which I had to fix in a number of cases anyway, in particular, handling of dead symlinks in the -h case). The new algorithm of handling a symlink encountered during a file tree traversal works as follows: +-------------+-------------------------------------------------+ | Options | Action | +-------------+-------------------------------------------------+ | -- | chown | | -h | lchown | | | Notes: only FTS_SL symlinks may end up here | +-------------+-------------------------------------------------+ | -RP | SKIP | | -RP -h | lchown | | | Notes: only FTS_SL symlinks may end here | +-------------+-------------------------------------------------+ | -RH | SKIP | | -RH -h | lchown | | | Notes: both FTS_SL and FTS_SLNONE symlinks | | | may end up here. FTS_SLNONE's are deadlinks | | | specified as command line arguments | +-------------+-------------------------------------------------+ | -RL | SKIP | | -RL -h | lchown | | | Notes: only FTS_SLNONE symlinks may end up here | +-------------+-------------------------------------------------+ Or, in a more compact form: : if symlink { : if -R : -h ? lchmod : SKIP : else : -h ? lchmod : chmod : } else : chmod For the testing purposes, I'd suggest creating the following structure, which should be self-explaining: afile alink -> afile deadlink -> nofile dir adir -> dir dir/afile dir/alink -> afile dir/deadlink -> nofile PLEASE TEST THIS PATCH THROUGHLY! NOTE: This implementation is still not quite POSIX compliant, as the latter says to follow a symlink (in the -R case) only if it points to an object of type directory. Our fts(3) routines are unable of doing this. If this patch is accepted, I'm going to revisit and fix the rest of the fts(3) utilities that are listed on the symlink(7) manpage. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: chown.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/chown/chown.c,v retrieving revision 1.19 diff -u -p -r1.19 chown.c --- chown.c 2001/09/13 14:55:59 1.19 +++ chown.c 2001/09/13 16:54:28 @@ -80,6 +80,7 @@ main(argc, argv) int Hflag, Lflag, Rflag, fflag, hflag, vflag; int ch, fts_options, rval; char *cp; + int (*change_owner) __P((const char *, uid_t, gid_t)); cp = strrchr(argv[0], '/'); cp = (cp != NULL) ? cp + 1 : argv[0]; @@ -121,19 +122,15 @@ main(argc, argv) if (argc < 2) usage(); + fts_options = FTS_PHYSICAL; if (Rflag) { - fts_options = FTS_PHYSICAL; - if (hflag && (Hflag || Lflag)) - errx(1, "the -R%c and -h options may not be " - "specified together", Hflag ? 'H' : 'L'); if (Hflag) fts_options |= FTS_COMFOLLOW; else if (Lflag) { fts_options &= ~FTS_PHYSICAL; fts_options |= FTS_LOGICAL; } - } else - fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL; + } uid = (uid_t)-1; gid = (gid_t)-1; @@ -156,6 +153,7 @@ main(argc, argv) err(1, NULL); for (rval = 0; (p = fts_read(ftsp)) != NULL;) { + change_owner = chown; switch (p->fts_info) { case FTS_D: /* Change it at FTS_DP. */ if (!Rflag) @@ -170,31 +168,48 @@ main(argc, argv) warnx("%s: %s", p->fts_path, strerror(p->fts_errno)); rval = 1; continue; - case FTS_SL: case FTS_SLNONE: /* * The only symlinks that end up here are ones that - * don't point to anything and ones that we found - * doing a physical walk. + * don't point to anything. Note that if we are + * doing a physical walk, we never reach here unless + * we asked to follow explicitly. */ - if (hflag) - break; - else + /* FALLTHROUGH */ + case FTS_SL: + /* + * All symlinks we found while doing a physical + * walk end up here. + */ + if (Rflag && !hflag) continue; + /* + * Note that if we follow a symlink, fts_info is + * not FTS_SL but FTS_F or whatever. And we should + * use lchown(2) only for FTS_SL and should use + * chown(2) for others. + */ + if (hflag) + change_owner = lchown; + break; default: break; } - if ((uid == (uid_t)-1 || uid == p->fts_statp->st_uid) && - (gid == (gid_t)-1 || gid == p->fts_statp->st_gid)) - continue; - if ((hflag ? lchown : chown)(p->fts_accpath, uid, gid) == -1) { + if ((*change_owner)(p->fts_accpath, uid, gid) == -1) { if (!fflag) { chownerr(p->fts_path); rval = 1; } } else { if (vflag) +#define DEBUG +#ifdef DEBUG + printf("%s %s\n", + (change_owner == chown) ? "chown" : "lchown", + p->fts_path); +#else printf("%s\n", p->fts_path); +#endif } } if (errno) --2fHTh5uZTiUOsy+g-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 15:41:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by hub.freebsd.org (Postfix) with ESMTP id 5666237B410 for ; Thu, 13 Sep 2001 15:41:29 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by cleitus.hosting.pacbell.net id SAA21723; Thu, 13 Sep 2001 18:41:28 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <010e01c13ca3$6e12b4a0$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: Subject: FD_LOCK, pthreads and drivers Date: Thu, 13 Sep 2001 15:28:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01C13C68.C14A6C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C13C68.C14A6C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I noticed that while testing the driver I wrote for a crypto device, that only one thread can be executing within the context of my driver at a time. The problem is that the pthreads library=20 replaces the ioctl with another that exclusively locks the file descriptor with calls to FD_LOCK/ FD_UNLOCK. Why? I went to extremes to make sure that it would be fully reentrant. The driver/crypto accelerator now suffers from slow performance.=20 ------=_NextPart_000_010B_01C13C68.C14A6C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I noticed that while testing the driver = I=20 wrote
for a crypto device, that only one=20 thread
can be executing within the context = of
my driver at a time.
 
The problem is that the pthreads = library=20
replaces the ioctl with another that=20 exclusively
locks the file descriptor with calls to FD_LOCK/
FD_UNLOCK.
 
Why?
 
 I went to extremes to make sure = that=20 it
would be fully reentrant.
The driver/crypto accelerator now=20 suffers
from slow performance.=20
------=_NextPart_000_010B_01C13C68.C14A6C70-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 16:30:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 0DCEC37B403 for ; Thu, 13 Sep 2001 16:30:29 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id EF0C081D05; Thu, 13 Sep 2001 18:30:28 -0500 (CDT) Date: Thu, 13 Sep 2001 18:30:28 -0500 From: Alfred Perlstein To: mike varga Cc: freebsd-arch@freebsd.org Subject: Re: FD_LOCK, pthreads and drivers Message-ID: <20010913183028.P968@elvis.mu.org> References: <010e01c13ca3$6e12b4a0$4a10a8c0@stcla1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <010e01c13ca3$6e12b4a0$4a10a8c0@stcla1.sfba.home.com>; from mike.varga@cavium.com on Thu, Sep 13, 2001 at 03:28:35PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * mike varga [010913 17:41] wrote: > I noticed that while testing the driver I wrote > for a crypto device, that only one thread > can be executing within the context of > my driver at a time. > > The problem is that the pthreads library > replaces the ioctl with another that exclusively > locks the file descriptor with calls to FD_LOCK/ > FD_UNLOCK. > > Why? > > I went to extremes to make sure that it > would be fully reentrant. > The driver/crypto accelerator now suffers > from slow performance. Under the native FreeBSD threading model there is only one process context. You'll want to use the linuxthreads port to do this. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 17:13: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cleitus.hosting.pacbell.net (cleitus.hosting.pacbell.net [216.100.99.17]) by hub.freebsd.org (Postfix) with ESMTP id 2665A37B41B for ; Thu, 13 Sep 2001 17:13:04 -0700 (PDT) Received: from c1435077a (adsl-64-172-38-74.dsl.snfc21.pacbell.net [64.172.38.74]) by cleitus.hosting.pacbell.net id UAA00517; Thu, 13 Sep 2001 20:13:00 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Message-ID: <014001c13cb0$36eb5e70$4a10a8c0@stcla1.sfba.home.com> Reply-To: "mike varga" From: "mike varga" To: "Alfred Perlstein" , References: <010e01c13ca3$6e12b4a0$4a10a8c0@stcla1.sfba.home.com> <20010913183028.P968@elvis.mu.org> Subject: Re: FD_LOCK, pthreads and drivers Date: Thu, 13 Sep 2001 17:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Are both of the threading models posix complient? Can I replace one with the other, without affecting the operation of the applications using them? This seems to indicate that it is not a kernel requirement; only someone decided to force locking on the file descriptors regardless of whether they where actually needed. Is this true? ----- Original Message ----- From: "Alfred Perlstein" To: "mike varga" Cc: Sent: Thursday, September 13, 2001 4:30 PM Subject: Re: FD_LOCK, pthreads and drivers > * mike varga [010913 17:41] wrote: > > I noticed that while testing the driver I wrote > > for a crypto device, that only one thread > > can be executing within the context of > > my driver at a time. > > > > The problem is that the pthreads library > > replaces the ioctl with another that exclusively > > locks the file descriptor with calls to FD_LOCK/ > > FD_UNLOCK. > > > > Why? > > > > I went to extremes to make sure that it > > would be fully reentrant. > > The driver/crypto accelerator now suffers > > from slow performance. > > Under the native FreeBSD threading model there is only one > process context. You'll want to use the linuxthreads port > to do this. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 17:56: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 5E8AD37B407 for ; Thu, 13 Sep 2001 17:56:02 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id UAA04029; Thu, 13 Sep 2001 20:54:53 -0400 (EDT) Date: Thu, 13 Sep 2001 20:54:53 -0400 (EDT) From: Daniel Eischen To: Alfred Perlstein Cc: mike varga , freebsd-arch@FreeBSD.ORG Subject: Re: FD_LOCK, pthreads and drivers In-Reply-To: <20010913183028.P968@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 13 Sep 2001, Alfred Perlstein wrote: > * mike varga [010913 17:41] wrote: > > I noticed that while testing the driver I wrote > > for a crypto device, that only one thread > > can be executing within the context of > > my driver at a time. > > > > The problem is that the pthreads library > > replaces the ioctl with another that exclusively > > locks the file descriptor with calls to FD_LOCK/ > > FD_UNLOCK. This isn't true for -current. I removed automatic locking of file descriptors many months ago. > > Why? Indeed, it should be up to the application to provide protection for I/O operations on the same file descriptor :-) Or at least the threads library should stay out of the way and let the application and kernel decide... > > I went to extremes to make sure that it > > would be fully reentrant. > > The driver/crypto accelerator now suffers > > from slow performance. > > Under the native FreeBSD threading model there is only one > process context. You'll want to use the linuxthreads port > to do this. You can have multiple I/O requests within libc_r, but they are all converted to non-blocking requests and the thread scheduler periodically polls for I/O completion. If your device driver doesn't support non-blocking operations, then our threads library isn't going to help you much even in -current where FD locking is disabled. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 19: 8:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 1381937B405; Thu, 13 Sep 2001 19:08:13 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id f8E286O27892; Fri, 14 Sep 2001 06:08:06 +0400 (MSD) (envelope-from ache) Date: Fri, 14 Sep 2001 06:08:02 +0400 From: "Andrey A. Chernov" To: Ruslan Ermilov Cc: arch@FreeBSD.ORG, freebsd-standards@bostonradio.org, Bruce Evans , Garrett Wollman Subject: Re: Fixing chown(8) and friends to handle symlinks properly Message-ID: <20010914060800.A27869@nagual.pp.ru> References: <20010913202742.C2458@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010913202742.C2458@sunbay.com> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 13, 2001 at 20:27:42 +0300, Ruslan Ermilov wrote: > NOTE: This implementation is still not quite POSIX compliant, as > the latter says to follow a symlink (in the -R case) only if it > points to an object of type directory. Our fts(3) routines are > unable of doing this. Is there a way to fix fts(3) to implement this? I.e. modify fts(3) to make directory test before following anywhere. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Sep 13 20: 2:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1A75837B401; Thu, 13 Sep 2001 20:02:22 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f8E32La12637; Thu, 13 Sep 2001 20:02:21 -0700 Date: Thu, 13 Sep 2001 20:02:21 -0700 From: Brooks Davis To: net@freebsd.org, arch@freebsd.org Subject: review request: creating cloneable interfaces at boot Message-ID: <20010913200221.A11788@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to commit something like the following patch to create clonable interfaces at boot so they can be configured the normal way. Any one have comments or suggestions? -- Brooks Index: etc/rc.network =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/etc/rc.network,v retrieving revision 1.102 diff -u -r1.102 rc.network --- etc/rc.network 30 Jul 2001 23:12:02 -0000 1.102 +++ etc/rc.network 14 Sep 2001 02:54:15 -0000 @@ -127,6 +127,11 @@ ;; esac =20 + # Attempt to create cloned interfaces. + for ifn in ${cloned_interfaces}; do + ifconfig ${ifn} create + done + # Special options for sppp(4) interfaces go here. These need # to go _before_ the general ifconfig section, since in the case # of hardwired (no link1 flag) but required authentication, you @@ -151,6 +156,9 @@ [Aa][Uu][Tt][Oo]) network_interfaces=3D"`ifconfig -l`" ;; + *) + network_interfaces=3D"${network_interfaces} ${cloned_interfaces}" + ;; esac =20 dhcp_interfaces=3D"" @@ -796,7 +804,8 @@ continue ;; *) - ifconfig $i create tunnel ${peers} + ifconfig $i create >/dev/null 2>&1 + ifconfig $i tunnel ${peers} ;; esac done Index: etc/defaults/rc.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/etc/defaults/rc.conf,v retrieving revision 1.122 diff -u -r1.122 rc.conf --- etc/defaults/rc.conf 2 Sep 2001 23:34:19 -0000 1.122 +++ etc/defaults/rc.conf 12 Sep 2001 20:54:50 -0000 @@ -85,6 +85,8 @@ icmp_drop_redirect=3D"NO" # Set to YES to ignore ICMP REDIRECT packets icmp_log_redirect=3D"NO" # Set to YES to log ICMP REDIRECT packets network_interfaces=3D"auto" # List of network interfaces (or "auto"). +cloned_interfaces=3D"" # List of cloned network interfaces to create. +#cloned_interfaces=3D"gif0" # Restore pre-cloning GENERIC config. ifconfig_lo0=3D"inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0=3D"inet 127.0.0.254 netmask 0xffffffff" # Sample alia= s entry. #ifconfig_ed0_ipx=3D"ipx 0x00010010" # Sample IPX address family entry. Index: share/man/man5/rc.conf.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/share/man/man5/rc.conf.5,v retrieving revision 1.133 diff -u -r1.133 rc.conf.5 --- share/man/man5/rc.conf.5 29 Aug 2001 05:39:06 -0000 1.133 +++ share/man/man5/rc.conf.5 14 Sep 2001 02:45:31 -0000 @@ -598,6 +598,14 @@ .Bd -literal ifconfig_ed0=3D"DHCP" .Ed +.It Va cloned_interfaces +.Pq Vt str +Set to the list of clonable network interfaces to create on this host. +Entries in +.Va cloned_interfaces +are automaticly appended to +.Va network_interfaces +for configuration. .It Va ppp_enable .Pq Vt bool If set to --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7oXM7XY6L6fI4GtQRAjUyAJ4oaqm5nzuq8eOHng6zbeis6CwhjgCdH2aY phfrNOAdiB/5ZqufZKqG1Bg= =fyDE -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 14 4:36:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D6AE437B410; Fri, 14 Sep 2001 04:36:40 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8EBZUS19283; Fri, 14 Sep 2001 14:35:30 +0300 (EEST) (envelope-from ru) Date: Fri, 14 Sep 2001 14:35:30 +0300 From: Ruslan Ermilov To: Brooks Davis Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: review request: creating cloneable interfaces at boot Message-ID: <20010914143530.E12915@sunbay.com> References: <20010913200221.A11788@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010913200221.A11788@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Sep 13, 2001 at 08:02:21PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 13, 2001 at 08:02:21PM -0700, Brooks Davis wrote: > I'd like to commit something like the following patch to create clonable > interfaces at boot so they can be configured the normal way. Any one > have comments or suggestions? > Umm, how about extending the ${network_interfaces} functionality as follows. For each ${network_interfaces} argument, 1. if the value is `auto', add `ifconfig -l' to the list of interfaces 2. for every other argument which is not in the `ifconfig -l' list (ifconfig -l | grep -wq ${ifn} returns non-zero), but in the list of cloners (ifconfig -L) creates the corresponding interface. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Sep 14 8:20:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id DEE4437B403; Fri, 14 Sep 2001 08:20:41 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f8EFKfS08642; Fri, 14 Sep 2001 08:20:41 -0700 Date: Fri, 14 Sep 2001 08:20:41 -0700 From: Brooks Davis To: Ruslan Ermilov Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: review request: creating cloneable interfaces at boot Message-ID: <20010914082041.A7169@Odin.AC.HMC.Edu> References: <20010913200221.A11788@Odin.AC.HMC.Edu> <20010914143530.E12915@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010914143530.E12915@sunbay.com>; from ru@FreeBSD.ORG on Fri, Sep 14, 2001 at 02:35:30PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2001 at 02:35:30PM +0300, Ruslan Ermilov wrote: > Umm, how about extending the ${network_interfaces} functionality as follo= ws. > For each ${network_interfaces} argument, >=20 > 1. if the value is `auto', add `ifconfig -l' to the list of interfaces > 2. for every other argument which is not in the `ifconfig -l' list > (ifconfig -l | grep -wq ${ifn} returns non-zero), but in the > list of cloners (ifconfig -L) creates the corresponding interface. I don't really like that idea very much. If you implement 2) that way you lose ifconfig's auto module loading. You actually have to blindly try if you want that to work (and I do). Because of this, I like having a seperate variable that you only use for clonable interfaces. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7oiBIXY6L6fI4GtQRAux5AJkBfQxcIZP6WrZayPcSWrDCrVxa0wCdH1FC STBlZwq1mhV18Ayu0B/CWnc= =o+Jm -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message