From owner-freebsd-arch Mon Aug 12 13: 1:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E1B637B400; Mon, 12 Aug 2002 13:01:06 -0700 (PDT) Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36EA643E81; Mon, 12 Aug 2002 13:01:05 -0700 (PDT) (envelope-from hottymaria@gosympatico.ca) Received: from [209.226.175.136] by tomts11-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020812200118.SSAN1432.tomts11-srv.bellnexxia.net@[209.226.175.136]>; Mon, 12 Aug 2002 16:01:18 -0400 From: To: Subject: Hey, whats up? Date: Mon, 12 Aug 2002 16:01:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020812200118.SSAN1432.tomts11-srv.bellnexxia.net@[209.226.175.136]> 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

My buddies and I were average people, just like you...Then we had our great idea...
find young hot girls and proposition them to fool around on video tape.
Armed with a camera, a smooth tongue, and a couple of bucks we have made quite a few interesting videos!
BEST OF ALL... MY SITE IS 100% FREE!! If this sounds like something of interest to you, click here You will be glad you did.











If you never want to hear from me again, please click here and I will remove you from all future mailings.

----- Get your free WebMail account from Sympatico-Lycos at www.sympatico.ca ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 12 20:24: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A4237B400 for ; Mon, 12 Aug 2002 20:24:05 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id D25E843E42 for ; Mon, 12 Aug 2002 20:24:04 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020813032403.KNLD23732.sccrmhc01.attbi.com@blossom.cjclark.org>; Tue, 13 Aug 2002 03:24:03 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7D3O2JK001779; Mon, 12 Aug 2002 20:24:02 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7D3NvOn001778; Mon, 12 Aug 2002 20:23:57 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 12 Aug 2002 20:23:57 -0700 From: "Crist J. Clark" To: Antoine Beaupre Cc: freebsd-arch@FreeBSD.ORG Subject: Re: implementation differences between inet_aton() and inet_pton() Message-ID: <20020813032357.GA1675@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <3A565436-ABC5-11D6-BAC6-0050E4A0BB3F@anarcat.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A565436-ABC5-11D6-BAC6-0050E4A0BB3F@anarcat.ath.cx> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ 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, Aug 09, 2002 at 02:24:22PM -0400, Antoine Beaupre wrote: > Hi > > I just stumbled upon some differences between the results given by > inet_aton() and inet_pton(). > > inet_aton() converts substrings to numbers using strtoul(). This means > that an address like "127.0x0.0.01" will be parsed as "127.0.0.1". > > On the other hand, inet_pton() parses the number directly, using a > clever hack: > > u_int new = *tp * 10 + (pch - digits); > > This assumes the number is in base 10. This means that an address like > "127.0x0.0.01" will result in a parse error. (more precisely: 0 if the > address wasn't parseable in the specified address family). > > Is this difference there by design or accident? I think I went through this a few months ago when I noticed that "127.0x0.0.01" and "127.1" don't work with inet_pton(3). > In either case it should be documented how each function parses the > numbers, because it is rather important. Did you read the whole page? inet_pton(3) says, STANDARDS The inet_ntop() and inet_pton() functions conform to X/Open Networking Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept 1-, 2-, or 3-part dotted addresses; all four parts must be specified and are interpreted only as decimal values. This is a narrower input set than that accepted by inet_aton(). -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 13 18:57:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFA2F37B400; Tue, 13 Aug 2002 18:57:19 -0700 (PDT) Received: from aeimail.aei.ca (aeimail.aei.ca [206.123.6.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD8643E4A; Tue, 13 Aug 2002 18:57:18 -0700 (PDT) (envelope-from anarcat@anarcat.ath.cx) Received: from shall.anarcat.ath.cx (auvbcco6ymwp98za@dsl-59-246.aei.ca [216.221.59.246]) by aeimail.aei.ca (8.11.6/8.10.1) with ESMTP id g7E1vC520775; Tue, 13 Aug 2002 21:57:13 -0400 (EDT) Received: from lenny.anarcat.ath.cx (lenny.anarcat.ath.cx [192.168.0.4]) by shall.anarcat.ath.cx (Postfix) with SMTP id 624AF425; Tue, 13 Aug 2002 21:58:21 -0400 (EDT) Received: by lenny.anarcat.ath.cx (sSMTP sendmail emulation); Tue, 13 Aug 2002 21:53:41 -0400 Date: Tue, 13 Aug 2002 21:53:41 -0400 From: The Anarcat To: "Crist J. Clark" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: implementation differences between inet_aton() and inet_pton() Message-ID: <20020814015341.GA305@lenny.anarcat.ath.cx> References: <3A565436-ABC5-11D6-BAC6-0050E4A0BB3F@anarcat.ath.cx> <20020813032357.GA1675@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20020813032357.GA1675@blossom.cjclark.org> User-Agent: Mutt/1.5.1i 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 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon Aug 12, 2002 at 08:23:57PM -0700, Crist J. Clark wrote: [snip] >=20 > Did you read the whole page? inet_pton(3) says, >=20 > STANDARDS > The inet_ntop() and inet_pton() functions conform to X/Open Networki= ng > Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not acc= ept > 1-, 2-, or 3-part dotted addresses; all four parts must be specified= and > are interpreted only as decimal values. This is a narrower input set > than that accepted by inet_aton(). Hmmm.. I guess I must provide an explanation here. I must admit have read quickly through the man page, but there was a misinterpretation here on my part. "Decimal" has a special meaning in french, and doesn't explicitly mean "base 10 integer" as in english, but more "number with a decimal part" (as opposed with "integer"). Which is quite confusing. I guess the man page survives the test then. I'll shut up now. :) A. --=20 The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9WbgkttcWHAnWiGcRAjslAKCfXi5IIxjC3ak1FbloqFUJZeaTiwCgjX6k aqK4d84fWU1WlQi0Ahl1bxM= =nEJU -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 14 9:53: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3048F37B400 for ; Wed, 14 Aug 2002 09:52:59 -0700 (PDT) Received: from mail.bluesocket.com (mail01.bluesocket.com [65.196.44.131]) by mx1.FreeBSD.org (Postfix) with SMTP id 6644C43E65 for ; Wed, 14 Aug 2002 09:52:58 -0700 (PDT) (envelope-from sdowlati@bluesocket.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: Intel XScale Port support Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C243B2.FDB1023E" Disposition-Notification-To: "Soroor Dowlati" Date: Wed, 14 Aug 2002 12:52:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel XScale Port support Thread-Index: AcJDsv1adq8IEQ6oQKS8gZAr/0KS7Q== From: "Soroor Dowlati" To: 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_001_01C243B2.FDB1023E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, =20 I was wondering if FreeBSD has already been ported to Intel XScale = architecture, a quick search of your website does not indicate it as a = supported platform. I'll be working soon on a project using both Intel = 80321 (IOP321 - IO Processor, XScale) and IXP2400 (Intel Network = Processor - XScale), so I am in search of an operating system which I = could use with these two processors. =20 Thanks in advance for a reply, Regards, =20 Bluesocket, Inc. 7 New England Executive Park, 8th Floor Burlington, MA 01803 Tel: (781) 328-0888 x232 Fax: (781) 494-1082 sdowlati@bluesocket.com =20 =20 ------_=_NextPart_001_01C243B2.FDB1023E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

I was wondering if FreeBSD has = already been ported to Intel XScale architecture, a quick search of your website does = not indicate it as a supported platform. I’ll be working soon on a = project using both Intel 80321 (IOP321 – IO Processor, XScale) and IXP2400 = (Intel Network Processor – XScale), so I am in search of an operating = system which I could use with these two = processors.

 

Thanks in advance for a = reply,

Regards,

 

Bluesocket, Inc.

7 = New England Executive Park, 8th Floor

Burlington, MA 01803

Tel:  (781) 328-0888 = x232

Fax: (781) = 494-1082

sdowlati@bluesocket.com

 

 

=00 ------_=_NextPart_001_01C243B2.FDB1023E-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 14 10:19:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB1D237B400 for ; Wed, 14 Aug 2002 10:19:35 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6F543E6A for ; Wed, 14 Aug 2002 10:19:34 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from hades.videotron.ca ([24.203.254.196]) by relais.videotron.ca (Videotron-Netscape Messaging Server v4.15 MTA-PRD4) with ESMTP id H0UG5301.QCB for ; Wed, 14 Aug 2002 13:19:51 -0400 Received: from hades.videotron.ca. (localhost [127.0.0.1]) by hades.videotron.ca. (8.12.5/8.12.5) with ESMTP id g7EIFvEB023658 for ; Wed, 14 Aug 2002 14:15:58 -0400 (EDT) (envelope-from spotvin@hades.videotron.ca) Received: (from spotvin@localhost) by hades.videotron.ca. (8.12.5/8.12.5/Submit) id g7EIFvPU023657 for freebsd-arch@FreeBSD.ORG; Wed, 14 Aug 2002 14:15:57 -0400 (EDT) Date: Wed, 14 Aug 2002 14:15:57 -0400 From: "Stephane E. Potvin" To: freebsd-arch@FreeBSD.ORG Subject: Re: Intel XScale Port support Message-ID: <20020814181557.GB244@hades.videotron.ca.> Mail-Followup-To: freebsd-arch@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i 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 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2002 at 12:52:35PM -0400, Soroor Dowlati wrote: >=20 > Hi there, >=20 >=20 > I was wondering if FreeBSD has already been ported to Intel XScale > architecture, a quick search of your website does not indicate it as a > supported platform. I'll be working soon on a project using both Intel > 80321 (IOP321 - IO Processor, XScale) and IXP2400 (Intel Network > Processor - XScale), so I am in search of an operating system which I > could use with these two processors. >=20 There is currently an effort underway to port FreeBSD to the ARM family of processors. The initial target processor is the StrongArm from Intel. I guess it will be relatively easy to add support later on for the XScale family. The bad news is that this effort is far from complete and not even in the main FreeBSD repository yet. OTH, if you have some free time and want to help it would be very appreciated. Steph --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9Wp5dmdOXtTCX/nsRAvscAKC8ZL0wddzvJf9nB6BtWHKh2zMk3wCeLoO6 QwLytV99HNFlNl0PJNPC2ME= =Pj+P -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 0: 7:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AB1D37B400; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6740E43E4A; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7F77Lr24724; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 00:07:21 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Subject: RFC: new mbuf flag bit needed Message-ID: <20020815000720.B24495@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 [Bcc to -arch in case they have some comments] Hi, we have the following problem: both ipfw and ipfw2 can sometimes generate new packets (e.g. in response to an "unreach" or "reset" action, or simply keepalives) which in turn get reinjected in the stack and the firewall itself, starting from the beginning. This has the potential of causing loops, unless we break them in some way. ipfw does this using two specific hacks: + ICMP packets will not generate a response even on "unreach" rules; + TCP packets with the RST bit set will not generate a response on "unreach" rules) ipfw2 has a harder time because keepalives have nothing very distinguishable in them (except sequence numbers which refer to old data; but to detect them requests a lookup of the stateful entry). So my proposal is to use a different method, and use one of the m_pkthdr.flags bits as a marker that the packet should bypass the firewall. I can restrict the change to just ip_fw2.c so no other parts of the system will need to be modified, except sys/mbuf.h for the definition of the new bit if we want to give it a meaningful name. sys/mbuf.h contains definitions for M_PROTO1..M_PROTO5; the first one is used to mark that rcvif is valid on vlan packets (btw should we rename it to indicate its real use ?). The others are used in the KAME code in netinet6/ -- i guess that leaves me with using one of the two unused bits, 0x4000 and 0x8000 ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 8:23:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E749137B400 for ; Thu, 15 Aug 2002 08:23:25 -0700 (PDT) Received: from mx1.FreeBSD.org (host-66-133-58-214.verestar.net [66.133.58.214]) by mx1.FreeBSD.org (Postfix) with SMTP id 50D4743E77 for ; Thu, 15 Aug 2002 08:23:01 -0700 (PDT) (envelope-from augustine1@myself.com) From: "AUGUSTINE CHIDI" Date: Thu, 15 Aug 2002 16:22:52 To: freebsd-arch@FreeBSD.org Subject: CALL ME MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20020815152301.50D4743E77@mx1.FreeBSD.org> 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 ATTN: My name is Mr. AUGUSTINE CHIDI, the manager, credit and foreign bills of Ecobank Plc. I am writing in respect of a foreign customer of my bank with account number 14-255-2004/utb/t who perished in a plane crash [Korean Air Flight 801] with the whole passengers aboard on August 6, 1997. Since the demise of this our customer, I personally has watched with keen interest to see the next of kin but all has proved abortive as no one has come to claim his funds of usd.20.5 m, [twenty million five Hundred thousand United States dollars] which has been with my branch for a very long time. On this note, I decided to seek for whom his name shall be used as the next of kin as no one has come up to be the next of kin. And the banking ethics here does not allow such money to stay more than five years, because money will be recalled to the bank treasury as unclaimed after this period. In view of this I got your contact through a trade journal after realizing that your name and country is similar to the deceased. I will give you 25% of the total. Upon the receipt of your response, I will send you by fax or e-mail the application, bank’s fax number and the next step to take. I will not fail to bring to your notice that this business is hitch free and that you should not entertain any fear as all modalities for fund transfer can be finalized within five banking days, after you apply to the bank as a relation to the deceased. When you receive this letter. Kindly send me an e-mail signifying your decision including your private Tel/Fax numbers for quick communication. Respectfully submitted, AUGUSTINE CHIDI N.B These are my numbers 234-803-3279244,for futher discussion you can contact me immediately. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 12:26:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8985A37B400 for ; Thu, 15 Aug 2002 12:26:44 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1775843E86 for ; Thu, 15 Aug 2002 12:26:44 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7FJQgwu029478 for ; Thu, 15 Aug 2002 12:26:42 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7FJQgoK029477 for arch@freebsd.org; Thu, 15 Aug 2002 12:26:42 -0700 Date: Thu, 15 Aug 2002 12:26:42 -0700 From: Brooks Davis To: arch@freebsd.org Subject: kernel strlcpy Message-ID: <20020815122641.B21334@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3lcZGd9BuhuYXNfi" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu 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 --3lcZGd9BuhuYXNfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to import strlcpy into libkern. It's obviously the right function for setting the if_xname member of struct ifnet from the device. Most network drivers would use something of the form: strlcpy(ifp->if_xname, device_get_nameunit(dev), IFNAMSIZ); in their attach function. It's possiable to do this with strncpy, but it's rather lame to have to write: strncpy(ifp->if_xname, device_get_nameunit(dev), IFNAMSIZ-1); ifp->if_xname[IFNAMSIZ-1] =3D '\0'; Due to effiencies created by the if_xname change, GENERIC is actually 483 bytes _smaller_ with my current patch set including strlcpy. The ability to create very stripped kernels will be slightly reduced by this addition, but the stripped object file is only 532 bytes on the i386. I believe the function will be used enough to justify the bloat as I have 29 consumers in sys/dev alone and that's less then half of the interfaces. At a glance, there also appear to be other places where the use of strlcpy would be appropriate. For instance, kern/kern_proc.c contains a number of cases like: strncpy(kp->ki_comm, p->p_comm, sizeof(kp->ki_comm) - 1); where using strlcpy would eliminate the unsightly -1 and assure the reader that the string would always be null terminated without having to think about it too much. I am not advocating introducing strlcat because strncat is bairly used (only 9 times in the whole kernel.) Comments? -- 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 --3lcZGd9BuhuYXNfi 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 iD8DBQE9XABwXY6L6fI4GtQRAuXfAJ4h2AAV2mtR1TQ3MSnftvIs7tX2KACeM70S fQD+Hx8/Z82bGnOIjUZ5U3Q= =IyZM -----END PGP SIGNATURE----- --3lcZGd9BuhuYXNfi-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 12:30:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3641937B400 for ; Thu, 15 Aug 2002 12:30:29 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2CD043E70 for ; Thu, 15 Aug 2002 12:30:28 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id B76E7AE03F; Thu, 15 Aug 2002 12:30:28 -0700 (PDT) Date: Thu, 15 Aug 2002 12:30:28 -0700 From: Maxime Henrion To: arch@FreeBSD.org Cc: Brooks Davis Subject: Re: kernel strlcpy Message-ID: <20020815193028.GF14155@elvis.mu.org> References: <20020815122641.B21334@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020815122641.B21334@Odin.AC.HMC.Edu> User-Agent: Mutt/1.3.27i 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 Brooks Davis wrote: > I'd like to import strlcpy into libkern. It's obviously the right > function for setting the if_xname member of struct ifnet from the > device. Yes, please! We waited far too long for this, there are a lot of places in the kernel that really need strlcpy(). Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 14:54:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97CE037B400; Thu, 15 Aug 2002 14:54:37 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 551D943E65; Thu, 15 Aug 2002 14:54:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0454.cvx21-bradley.dialup.earthlink.net ([209.179.193.199] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fSZd-0004AQ-00; Thu, 15 Aug 2002 14:54:34 -0700 Message-ID: <3D5C22E2.33A82B55@mindspring.com> Date: Thu, 15 Aug 2002 14:53:38 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxime Henrion Cc: arch@FreeBSD.org, Brooks Davis Subject: Re: kernel strlcpy References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Maxime Henrion wrote: > Brooks Davis wrote: > > I'd like to import strlcpy into libkern. It's obviously the right > > function for setting the if_xname member of struct ifnet from the > > device. > > Yes, please! We waited far too long for this, there are a lot of places > in the kernel that really need strlcpy(). No, please. It encourages idiots to do string processing in the kernel, when you should be carrying around this crap in user space, instead. I think Linux did the right thing when they limited string copied in the kernel to file path name components. Other than "mount" (the system call that ate the world), and "sysctl" (the debug subsystem that ate the world), there's not a lot of real valid use for string manipulation in the kernel. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 15:38:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CE3537B400; Thu, 15 Aug 2002 15:38:50 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2ACA43E70; Thu, 15 Aug 2002 15:38:49 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id BC640AE03F; Thu, 15 Aug 2002 15:38:49 -0700 (PDT) Date: Thu, 15 Aug 2002 15:38:49 -0700 From: Maxime Henrion To: arch@FreeBSD.org Cc: Terry Lambert , brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020815223849.GH14155@elvis.mu.org> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5C22E2.33A82B55@mindspring.com> User-Agent: Mutt/1.3.27i 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 Terry Lambert wrote: > Maxime Henrion wrote: > > Brooks Davis wrote: > > > I'd like to import strlcpy into libkern. It's obviously the right > > > function for setting the if_xname member of struct ifnet from the > > > device. > > > > Yes, please! We waited far too long for this, there are a lot of places > > in the kernel that really need strlcpy(). > > No, please. It encourages idiots to do string processing in > the kernel, when you should be carrying around this crap in > user space, instead. It doesn't encourage people to do string processing in the kernel any more, since we already have strcpy() and strncpy(). Yes, generally speaking, string processing in the kernel is bad, but using str?cpy() is not necessarily bad. Whatever you do, we have some information represented by strings in the kernel, and we sometimes need to copy these strings. We're not parsing files here. :-) Going against strlcpy() doesn't help at all here; everywhere we need to copy strings we're forced to work around strncpy() which is a broken interface, and there is still the risk someone will write code using strncpy() without taking care of that problem, thus creating a possible security flaw. > I think Linux did the right thing when they limited string > copied in the kernel to file path name components. > > Other than "mount" (the system call that ate the world), > and "sysctl" (the debug subsystem that ate the world), there's > not a lot of real valid use for string manipulation in the > kernel. I tend to agree; I think there are cases of string manipulation in the kernel that would be avoided. But as you already said, there *are* valid uses for these functions. That's why we shouldn't make life so hard for these subsystems. Forcing them to use strncpy() while they could use strlcpy() doesn't make people more conscious of the problems we have with other subsystems using string manipulation when they shouldn't. It just makes programming harder for the valid cases. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 16: 3:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2B6F37B400; Thu, 15 Aug 2002 16:03:40 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6093A43E6A; Thu, 15 Aug 2002 16:03:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.245.131.82.dial1.sanjose1.level3.net ([209.245.131.82] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fTeN-0002jJ-00; Thu, 15 Aug 2002 16:03:34 -0700 Message-ID: <3D5C32F8.484AECD3@mindspring.com> Date: Thu, 15 Aug 2002 16:02:16 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxime Henrion Cc: arch@FreeBSD.org, brooks@freebsd.org Subject: Re: kernel strlcpy References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Maxime Henrion wrote: [ ... adding strlcpy ... ] > > No, please. It encourages idiots to do string processing in > > the kernel, when you should be carrying around this crap in > > user space, instead. > > It doesn't encourage people to do string processing in the kernel any > more, since we already have strcpy() and strncpy(). Those should be removed in any case, if strlcpy will so magically save us from "all those" kernel buffer overflow exploits out there, and we should change libc so that the compiler whines "This program uses strcpy, which is unsafe". Or maybe just "This program was written by a someone other than me, which is unsafe". 8-). > Yes, generally speaking, string processing in the kernel is bad, > but using str?cpy() is not necessarily bad. Whatever you do, we > have some information represented by strings in the kernel, and we > sometimes need to copy these strings. We're not parsing files here. > :-) UFS Quotas. We *are* parsing files here. And we're parsing command line options to "mount". And names of things for /etc/exports. We started down this slippery slope years ago, and haven't bothered looking back since. > Going against strlcpy() doesn't help at all here; everywhere we need to > copy strings we're forced to work around strncpy() which is a broken > interface, and there is still the risk someone will write code using > strncpy() without taking care of that problem, thus creating a possible > security flaw. Gug. Might as well cvs import OpenBSD and be done with it. 8^P. How about deleting strncpy() when you import strlcpy()? > I tend to agree; I think there are cases of string manipulation in the > kernel that would be avoided. But as you already said, there *are* > valid uses for these functions. That's why we shouldn't make life so > hard for these subsystems. Forcing them to use strncpy() while they > could use strlcpy() doesn't make people more conscious of the problems > we have with other subsystems using string manipulation when they > shouldn't. It just makes programming harder for the valid cases. I think it encourages "more of the same", by example. In any case, if this is supposed to replace strncpy, it should, in fact, replace it, not add yet another function. "The wonderful thing about standards is there are so many to choose from" - Andy Tannenbaum -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 17:22:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C62E37B400; Thu, 15 Aug 2002 17:22:41 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0501B43E6E; Thu, 15 Aug 2002 17:22:41 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id C0FFFAE162; Thu, 15 Aug 2002 17:22:40 -0700 (PDT) Date: Thu, 15 Aug 2002 17:22:40 -0700 From: Maxime Henrion To: Terry Lambert Cc: arch@freebsd.org, brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020816002240.GI14155@elvis.mu.org> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org> <3D5C32F8.484AECD3@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5C32F8.484AECD3@mindspring.com> User-Agent: Mutt/1.3.27i 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 Terry Lambert wrote: > Maxime Henrion wrote: > [ ... adding strlcpy ... ] > > > No, please. It encourages idiots to do string processing in > > > the kernel, when you should be carrying around this crap in > > > user space, instead. > > > > It doesn't encourage people to do string processing in the kernel any > > more, since we already have strcpy() and strncpy(). > > Those should be removed in any case, if strlcpy will so magically > save us from "all those" kernel buffer overflow exploits out there, > and we should change libc so that the compiler whines "This program > uses strcpy, which is unsafe". It's not that easy, as you already admitted, there are valid cases for their use. So we can't just remove them. > Or maybe just "This program was written by a someone other than me, > which is unsafe". > 8-). > > > Yes, generally speaking, string processing in the kernel is bad, > > but using str?cpy() is not necessarily bad. Whatever you do, we > > have some information represented by strings in the kernel, and we > > sometimes need to copy these strings. We're not parsing files here. > > :-) > > UFS Quotas. We *are* parsing files here. And we're parsing > command line options to "mount". And names of things for > /etc/exports. > > We started down this slippery slope years ago, and haven't > bothered looking back since. Yes, that's awful. But this is an argument against string processing in the kernel, not against strlcpy(). > > Going against strlcpy() doesn't help at all here; everywhere we need to > > copy strings we're forced to work around strncpy() which is a broken > > interface, and there is still the risk someone will write code using > > strncpy() without taking care of that problem, thus creating a possible > > security flaw. > > Gug. Might as well cvs import OpenBSD and be done with it. 8^P. > > How about deleting strncpy() when you import strlcpy()? That would require that the person who does the import also converts all consumers at the same time. Maybe that extra pain is not necessary, and we could do the transition in a more smooth way. Of course, then there is the risk that people will forget about that and live with both functions forever. > > I tend to agree; I think there are cases of string manipulation in the > > kernel that would be avoided. But as you already said, there *are* > > valid uses for these functions. That's why we shouldn't make life so > > hard for these subsystems. Forcing them to use strncpy() while they > > could use strlcpy() doesn't make people more conscious of the problems > > we have with other subsystems using string manipulation when they > > shouldn't. It just makes programming harder for the valid cases. > > I think it encourages "more of the same", by example. > > In any case, if this is supposed to replace strncpy, it should, > in fact, replace it, not add yet another function. I agree, but as I said, maybe it's not worth doing all that at once. Anyways, we are now discussing how it should be done, and not if it should be done. Let's not go off-topic. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 15 17:33:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B5237B400; Thu, 15 Aug 2002 17:33:09 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99BEB43E65; Thu, 15 Aug 2002 17:33:08 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7G0X6wu007383; Thu, 15 Aug 2002 17:33:06 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7G0X6Ap007382; Thu, 15 Aug 2002 17:33:06 -0700 Date: Thu, 15 Aug 2002 17:33:06 -0700 From: Brooks Davis To: Maxime Henrion Cc: Terry Lambert , arch@freebsd.org, brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020815173306.A6719@Odin.AC.HMC.Edu> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org> <3D5C32F8.484AECD3@mindspring.com> <20020816002240.GI14155@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020816002240.GI14155@elvis.mu.org>; from mux@freebsd.org on Thu, Aug 15, 2002 at 05:22:40PM -0700 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu 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 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2002 at 05:22:40PM -0700, Maxime Henrion wrote: > Terry Lambert wrote: > > How about deleting strncpy() when you import strlcpy()? >=20 > That would require that the person who does the import also converts all > consumers at the same time. Maybe that extra pain is not necessary, and > we could do the transition in a more smooth way. Of course, then there > is the risk that people will forget about that and live with both > functions forever. I'm definatly not planning to do that. I'm sure a good portion of the 320 instances of strncpy in /sys are canidates for strlcpy, but I wouldn't bet on all of them, espeicaly since APCI defines an APCI_STRNCPY macro. -- 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 --EeQfGwPcQSOJBaQU 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 iD8DBQE9XEhBXY6L6fI4GtQRAvMZAJ0RIH1dNy4CD+IpVql8WUNXCTe5zQCgukjm QPet76kX1gQkzudaR2wW7WE= =FmTr -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 12:58:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E78D737B400; Fri, 16 Aug 2002 12:58:20 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C2B43E3B; Fri, 16 Aug 2002 12:58:20 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 18F982A7D6; Fri, 16 Aug 2002 12:58:20 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxime Henrion Cc: arch@FreeBSD.org, Brooks Davis Subject: Re: kernel strlcpy In-Reply-To: <20020815193028.GF14155@elvis.mu.org> Date: Fri, 16 Aug 2002 12:58:20 -0700 From: Peter Wemm Message-Id: <20020816195820.18F982A7D6@canning.wemm.org> 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 Maxime Henrion wrote: > Brooks Davis wrote: > > I'd like to import strlcpy into libkern. It's obviously the right > > function for setting the if_xname member of struct ifnet from the > > device. > > Yes, please! We waited far too long for this, there are a lot of places > in the kernel that really need strlcpy(). Yes. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 13:16: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51DE337B400 for ; Fri, 16 Aug 2002 13:15:59 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3158543E6E for ; Fri, 16 Aug 2002 13:15:58 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7GKFpQe003827; Fri, 16 Aug 2002 14:15:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 16 Aug 2002 14:15:48 -0600 (MDT) Message-Id: <20020816.141548.17599527.imp@bsdimp.com> To: brooks@one-eyed-alien.net Cc: arch@FreeBSD.ORG Subject: Re: kernel strlcpy From: "M. Warner Losh" In-Reply-To: <20020815122641.B21334@Odin.AC.HMC.Edu> References: <20020815122641.B21334@Odin.AC.HMC.Edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 In message: <20020815122641.B21334@Odin.AC.HMC.Edu> Brooks Davis writes: : I'd like to import strlcpy into libkern. YES YES YES! : I am not advocating introducing strlcat because strncat is bairly used : (only 9 times in the whole kernel.) I think it would be reasonable. In fact, if we ELIMINATE strncat and strncpy in the kernel, then that would be enough to justify bringing them in. Since this isn't a hosted environment, we can do that if we want. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 13:16:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3527F37B400; Fri, 16 Aug 2002 13:16:44 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 519DA43E75; Fri, 16 Aug 2002 13:16:43 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7GKGfQe003836; Fri, 16 Aug 2002 14:16:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 16 Aug 2002 14:16:38 -0600 (MDT) Message-Id: <20020816.141638.44921947.imp@bsdimp.com> To: tlambert2@mindspring.com Cc: mux@FreeBSD.ORG, arch@FreeBSD.ORG, brooks@FreeBSD.ORG Subject: Re: kernel strlcpy From: "M. Warner Losh" In-Reply-To: <3D5C32F8.484AECD3@mindspring.com> References: <3D5C22E2.33A82B55@mindspring.com> <20020815223849.GH14155@elvis.mu.org> <3D5C32F8.484AECD3@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 In message: <3D5C32F8.484AECD3@mindspring.com> Terry Lambert writes: : and we should change libc so that the compiler whines "This program : uses strcpy, which is unsafe". I have this in my tree. Are you sure you want that :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 14:47: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64D4937B400; Fri, 16 Aug 2002 14:47:01 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D873843E77; Fri, 16 Aug 2002 14:47:00 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.3/8.12.3) with ESMTP id g7GLkuwu028231; Fri, 16 Aug 2002 14:46:56 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.3/8.12.3/Submit) id g7GLkukp028230; Fri, 16 Aug 2002 14:46:56 -0700 Date: Fri, 16 Aug 2002 14:46:56 -0700 From: Brooks Davis To: "M. Warner Losh" Cc: mjacob@freebsd.org, brooks@one-eyed-alien.net, arch@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020816144656.A24332@Odin.AC.HMC.Edu> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020816.141548.17599527.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020816.141548.17599527.imp@bsdimp.com>; from imp@bsdimp.com on Fri, Aug 16, 2002 at 02:15:48PM -0600 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu 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 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 16, 2002 at 02:15:48PM -0600, M. Warner Losh wrote: > In message: <20020815122641.B21334@Odin.AC.HMC.Edu> > Brooks Davis writes: > : I'd like to import strlcpy into libkern. >=20 > YES YES YES! >=20 > : I am not advocating introducing strlcat because strncat is bairly used > : (only 9 times in the whole kernel.) It's a bit more then that due to a macro, but those are all in one function. > I think it would be reasonable. >=20 > In fact, if we ELIMINATE strncat and strncpy in the kernel, then that > would be enough to justify bringing them in. Since this isn't a > hosted environment, we can do that if we want. Removing strncat is probably not too hard. A quick look shows the following users: - ficl uses it correctly but would probably be happier with strlcat - ACPI goes to a lot of trouble to define an ACPI_STRNCAT macro and then doesn't use it. I think ACPI would compile fine without strncat defined, but it would break if someone started using it. ACPI does provide a way to use internal versions of standard functions, but the granularity is use libc or don't so we'd have to patch to use their functions only when our libkern lacks them. Perhaps someone should talk to Intel about that. - isp(4) uses it where it should use strlcat. This one is problematic because mjacob needs portable source. Simply changing the existing STRNCAT macro to use strlcat would correct the minor bug under FreeBSD and would work. It would be evil though. Removing strncpy is more then I want to do at this point. I'd be happy to do part of it, but I'd like to get if_xname done first. -- 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 --7AUc2qLy4jB3hD7Z 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 iD8DBQE9XXLNXY6L6fI4GtQRArPKAJ9ywiTC5EBTRx64Cd7FH8lMZYJ2qQCfUe/a 4S4O0/gUjleHgwiF7KAkgQU= =vSCR -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 15:25: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCB2737B400 for ; Fri, 16 Aug 2002 15:25:04 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4223343E42 for ; Fri, 16 Aug 2002 15:25:04 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 43890 invoked by uid 1000); 16 Aug 2002 22:25:05 -0000 Date: Fri, 16 Aug 2002 15:25:05 -0700 (PDT) From: Nate Lawson To: "M. Warner Losh" Cc: brooks@one-eyed-alien.net, arch@FreeBSD.ORG Subject: Re: kernel strlcpy In-Reply-To: <20020816.141548.17599527.imp@bsdimp.com> 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 Fri, 16 Aug 2002, M. Warner Losh wrote: > : I am not advocating introducing strlcat because strncat is bairly used > : (only 9 times in the whole kernel.) > > I think it would be reasonable. > > In fact, if we ELIMINATE strncat and strncpy in the kernel, then that > would be enough to justify bringing them in. Since this isn't a > hosted environment, we can do that if we want. > > Warner One useful thing about strncpy is that it overwrites the remainder of its length with zeroes, not just null-terminating the string with a single zero. This is useful for fixed-length fields that aren't interpreted as null-terminated strings but can be a huge performance hit when all you wanted was single null termination (i.e. path). -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 16 15:29:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D60A37B400 for ; Fri, 16 Aug 2002 15:29:39 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8924043E65 for ; Fri, 16 Aug 2002 15:29:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7GMTZQe004273; Fri, 16 Aug 2002 16:29:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 16 Aug 2002 16:29:31 -0600 (MDT) Message-Id: <20020816.162931.25827842.imp@bsdimp.com> To: nate@root.org Cc: brooks@one-eyed-alien.net, arch@FreeBSD.ORG Subject: Re: kernel strlcpy From: "M. Warner Losh" In-Reply-To: References: <20020816.141548.17599527.imp@bsdimp.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 In message: Nate Lawson writes: : On Fri, 16 Aug 2002, M. Warner Losh wrote: : > : I am not advocating introducing strlcat because strncat is bairly used : > : (only 9 times in the whole kernel.) : > : > I think it would be reasonable. : > : > In fact, if we ELIMINATE strncat and strncpy in the kernel, then that : > would be enough to justify bringing them in. Since this isn't a : > hosted environment, we can do that if we want. : > : > Warner : : One useful thing about strncpy is that it overwrites the remainder of its : length with zeroes, not just null-terminating the string with a single : zero. This is useful for fixed-length fields that aren't interpreted as : null-terminated strings but can be a huge performance hit when all you : wanted was single null termination (i.e. path). Right, but strn* is almost always used wrong. There are very few fixed length fields like this compared to the number of bogus useages of strn*. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 17 11:19: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E990D37B400 for ; Sat, 17 Aug 2002 11:18:56 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id BDDF643E3B for ; Sat, 17 Aug 2002 11:18:55 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Aug 2002 19:18:54 +0100 (BST) To: arch@freebsd.org Subject: Solving the stack gap issue Date: Sat, 17 Aug 2002 19:18:54 +0100 From: Ian Dowse Message-ID: <200208171918.aa72556@salmon.maths.tcd.ie> 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 Many emulated Linux system calls use the stack gap to store paths and structures that need to be converted before calling the native system call. This has the well-known problem that shared address space threads can corrupt each others stack gap data if they perform system calls concurrently. Especially on SMP boxes this makes many Linux applications unusable on FreeBSD. A few approaches have been suggested: - Lock access to the stack gap, so that only one thread at a time can use it. - Use a different address region for each thread. - Avoid the need for the stack gap by providing kernel-callable versions of all syscalls. The first option would allow a single thread to hog the stack gap, so most applications would probably deadlock instantly. The second one sounds relatively straightforward, but so far nobody has found a simple way to allocate and control the per-thread memory. I have attempted to implement the third approach. It requires more extensive changes than the others, but it has the advantage of aiming to remove the stack gap hack instead of just adding another bad-aid to it. That said, it does add some overhead to normal system calls, so it may be that some ugliness is necessary to balance this tradeoff. The basic change is that many system calls have a version that is called with the FreeBSD ABI syscall arguments, e.g. The first option would allow a single thread to hog the stack gap, so most applications would probably deadlock instantly. The second one sounds relatively straightforward, but so far nobody has found a simple way to allocate and control the per-thread memory. I have attempted to implement the third approach. It requires more extensive changes than the others, but it has the advantage of aiming to remove the stack gap hack instead of just adding another bad-aid to it. That said, it does add some overhead to normal system calls, so it may be that some ugliness is necessary to balance this tradeoff. The basic change is that many system calls now have a version that is called with the FreeBSD ABI syscall arguments, e.g. int open(struct thread *td, struct open_args *uap) { return sys_open(td, SCARG(uap, path), UIO_USERSPACE, SCARG(uap, flags), SCARG(uap, mode)); } and a version that contains all of the code for implementing open(2) and is internal to the kernel, e.g.: int sys_open(struct thread *td, char *path, enum uio_seg pathseg, int flags, int mode); In this case it is expected that we may need support for both userspace and kernel-space paths, and since a path is a simple string, it makes sense for the caller to specify the address space from which the path should be read. For other functions, it seems more appropriate to have the wrapper do the copyin() itself. Anyway, there's a patch against -current at: http://www.maths.tcd.ie/~iedowse/FreeBSD/stackgap.diff This removes 80-90% of the stack gap uses in the i386 Linux emulation code. I haven't done more than a basic level of testing though. I'm also not particularly attached to any of the approaches taken here - it is really just a proof of concept for this approach. Any comments welcome! Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 17 12: 6:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B4737B400 for ; Sat, 17 Aug 2002 12:06:33 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 463C243E6E for ; Sat, 17 Aug 2002 12:06:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7HJ6Wdc068154; Sat, 17 Aug 2002 12:06:32 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7HJ6WiA068153; Sat, 17 Aug 2002 12:06:32 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Aug 2002 12:06:32 -0700 (PDT) From: Matthew Dillon Message-Id: <200208171906.g7HJ6WiA068153@apollo.backplane.com> To: Ian Dowse Cc: arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue References: <200208171918.aa72556@salmon.maths.tcd.ie> 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 :A few approaches have been suggested: :- Lock access to the stack gap, so that only one thread at a time : can use it. :- Use a different address region for each thread. :- Avoid the need for the stack gap by providing kernel-callable versions : of all syscalls. : :... :I have attempted to implement the third approach. It requires more :extensive changes than the others, but it has the advantage of :aiming to remove the stack gap hack instead of just adding another :bad-aid to it. That said, it does add some overhead to normal system :calls, so it may be that some ugliness is necessary to balance this :tradeoff. Good god! Ian, you've done the grunge work that nobody else wanted to do! This is great! It will also make the ABI work discussed a few months ago far easier to accomplish. I believe that your patch and approach is not only convenient, it is a necessary prerequisit for current and future ABI work in -current. I think you should commit it as soon as you think it's safe. Is there any specific kind of testing you would like done? Now that I have the TCP stuff comitted, the next thing on my agenda is the 64 bit ABI. Your work simplifies my task enormously. For example it allows me to make sys_*() functions take 64 bit arguments natively where appropriate and make the 32 bit syscalls convert. -Matt Matthew Dillon :Anyway, there's a patch against -current at: : : http://www.maths.tcd.ie/~iedowse/FreeBSD/stackgap.diff : :This removes 80-90% of the stack gap uses in the i386 Linux emulation :code. I haven't done more than a basic level of testing though. I'm :also not particularly attached to any of the approaches taken here :- it is really just a proof of concept for this approach. Any :comments welcome! : :Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 17 14:13:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C44A837B400 for ; Sat, 17 Aug 2002 14:13:22 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C78EB43E4A for ; Sat, 17 Aug 2002 14:13:18 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 VAA16584; Sat, 17 Aug 2002 21:13:09 GMT Date: Sun, 18 Aug 2002 07:19:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ian Dowse Cc: arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <200208171918.aa72556@salmon.maths.tcd.ie> Message-ID: <20020818055951.N12475-100000@gamplex.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 Sat, 17 Aug 2002, Ian Dowse wrote: > Many emulated Linux system calls use the stack gap to store paths > and structures that need to be converted before calling the native > system call. This has the well-known problem that shared address > space threads can corrupt each others stack gap data if they perform > system calls concurrently. Especially on SMP boxes this makes many > Linux applications unusable on FreeBSD. It also has the not so well known problems that stackgaps don't even work well for their main purpose of avoiding lots of code having to know that the args are in a special place. It just moves the problem from lots of general code having to know this to lots of compat code having to know this (so it actually increases the problem if there is enough compat code). Some compat code doesn't know this very well and causes panics by accessing the stack gap directly. Non-broken code would require lots more copyins and copyouts to avoid direct accesses: copyin input-args from user space translate input-args copyout input-args to stack gap call BSD syscall copyin input-args from stack gap reverse-translate input-args copyout input-args to user space > A few approaches have been suggested: > - Lock access to the stack gap, so that only one thread at a time > can use it. > - Use a different address region for each thread. > - Avoid the need for the stack gap by providing kernel-callable versions > of all syscalls. > ... > I have attempted to implement the third approach. It requires more Seems best. > extensive changes than the others, but it has the advantage of > aiming to remove the stack gap hack instead of just adding another > bad-aid to it. That said, it does add some overhead to normal system > calls, so it may be that some ugliness is necessary to balance this > tradeoff. I'd like normal calls to have a fast path. We're already 1 or 2 layers slower than Linux. (Linux on i386's does something like "pushal; call syscalltable(,%eax,4)" for the fast path, so it goes directly from the lowest layer to sys_foo(), but FreeBSD calls syscall() from the lowest label and syscall() does lots of relatively slow things.) > The basic change is that many system calls now have a version that > is called with the FreeBSD ABI syscall arguments, e.g. > > int > open(struct thread *td, struct open_args *uap) > { > return sys_open(td, SCARG(uap, path), UIO_USERSPACE, > SCARG(uap, flags), SCARG(uap, mode)); > } I would prefer this to be named something like xxx_open() and in a translation layer between Xsyscall() and open(), with the translation layer as null as possible. > and a version that contains all of the code for implementing open(2) > and is internal to the kernel, e.g.: > > int sys_open(struct thread *td, char *path, enum uio_seg pathseg, > int flags, int mode); I would prefer this to be named open() and take the same args as open(2). Passing around td args seems to just lead to pessimizations and bugs, since syscalls especially almost require td == curthread to work... > In this case it is expected that we may need support for both > userspace and kernel-space paths, and since a path is a simple > string, it makes sense for the caller to specify the address space > from which the path should be read. For other functions, it seems > more appropriate to have the wrapper do the copyin() itself. I think copyin() would be more simpler for pathnames too (but a pessimization unless it were done for all syscalls that take pathnames and not done by namei()). Reconsider this later. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message