From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 06:56:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA14716A4DA for ; Sun, 30 Jul 2006 06:56:46 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65A4443D46 for ; Sun, 30 Jul 2006 06:56:46 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k6U6uhPD003338; Sat, 29 Jul 2006 23:56:43 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k6U6udJt003335; Sat, 29 Jul 2006 23:56:39 -0700 (PDT) Date: Sat, 29 Jul 2006 23:56:39 -0700 (PDT) From: Matthew Dillon Message-Id: <200607300656.k6U6udJt003335@apollo.backplane.com> To: Dmitry Marakasov References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 06:56:47 -0000 : :* Matthew Dillon (dillon@apollo.backplane.com) wrote: : :> felt that 8 partitions is restrictive. My main home server has 10 :> and the main DragonFly box has 11. :> :> There is another solution for FreeBSD folks, however. You *DO* have :> four slices to play with. You can put a disklabel with 8 partitions :> in it on each one (for 32 total). It isn't as convenient, but it does :> work. :About `lack' of partitions - don't forget that labels can be nested. :Just do `bsdlabel -w /dev/ad0s1e` - you'll get /dev/ad0s1ea. : :-- :Best regards, : Dmitry mailto:amdmi3@mail.ru Oh, very cute! A terrible hack if you ask me, but cute all the same! -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 07:02:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA9716A4DD; Sun, 30 Jul 2006 07:02:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A8F343D45; Sun, 30 Jul 2006 07:02:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6U70M55096917; Sun, 30 Jul 2006 01:00:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 30 Jul 2006 01:00:41 -0600 (MDT) Message-Id: <20060730.010041.420517579.imp@bsdimp.com> To: andreas@freebsd.org From: "M. Warner Losh" In-Reply-To: <20060729094743.GA5840@titan.klemm.apsfilter.org> References: <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729094743.GA5840@titan.klemm.apsfilter.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 30 Jul 2006 01:00:22 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 07:02:37 -0000 In message: <20060729094743.GA5840@titan.klemm.apsfilter.org> Andreas Klemm writes: : Incompatible to UFS's like from Sun I think we are already, so we : don't have to honour them. Remember a current thread in german BSD : group where somebody complained about FreeBSD - mounting a Sun : filesystem r/w - destroyed the filesystem. Luckily he could recover : using fsck -b 32. I'm surprised that the fsck code passed the magic number test, since the sun ufs is in a different endian.. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 10:57:39 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EE3516A4E1 for ; Sun, 30 Jul 2006 10:57:39 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE30E43D46 for ; Sun, 30 Jul 2006 10:57:38 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6UAvWDI065157 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Jul 2006 12:57:32 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6UAvWJj065156 for hackers@freebsd.org; Sun, 30 Jul 2006 12:57:32 +0200 (CEST) Date: Sun, 30 Jul 2006 12:57:32 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060730105731.GA64955@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 10:57:39 -0000 hi, while working on SoC linuxolator project I am in a need of this: I need to do some operation on memory like mem1 = mem1 + mem2 etc. where the mem1/mem2 access can trigger fault. (memory not mapped or something) currently I solve this by using pcb_onfault. this must be done in asm (kib@ told me) so currently the code looks like this: futex_fault: movl PCPU(CURPCB), %edx movl $0, PCB_ONFAULT(%edx) movl $-EFAULT, %eax ret /* int futex_xchgl(int oparg, caddr_t uaddr, int *oldval); */ .globl futex_xchgl futex_xchgl: movl PCPU(CURPCB), %eax movl $futex_fault, PCB_ONFAULT(%eax) movl 4(%esp), %eax movl 8(%esp), %edx xchgl %eax, (%edx) movl 0xc(%esp), %edx movl %eax, (%edx) xorl %eax, %eax movl PCPU(CURPCB), %edx movl $0, PCB_ONFAULT(%edx) ret this is not very nice nor portable. I wonder if its possible to do something like this: LOCK_VM_SOMEHOW(); if (!memory_accessible(mem1) || !memory_accessible(mem2)) return EFAULT; mem1 = mem1 + mem2; UNLOCK_VM_SOMEHOW(); if its possible - what is the LOCK_VM_SOMEHOW lock? and what is the memory_accessible() function? thnx for pointing me to the right directions roman ---------------------- www.liberalnistrana.cz From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 11:34:15 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDD6B16A4DA for ; Sun, 30 Jul 2006 11:34:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail31.syd.optusnet.com.au (mail31.syd.optusnet.com.au [211.29.132.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3726743D45 for ; Sun, 30 Jul 2006 11:34:15 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail31.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k6UBYCiJ029741 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Jul 2006 21:34:13 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k6UBYCFm002586; Sun, 30 Jul 2006 21:34:12 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k6UBYCoq002585; Sun, 30 Jul 2006 21:34:12 +1000 (EST) (envelope-from peter) Date: Sun, 30 Jul 2006 21:34:12 +1000 From: Peter Jeremy To: Divacky Roman Message-ID: <20060730113411.GC1310@turion.vk2pj.dyndns.org> References: <20060730105731.GA64955@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline In-Reply-To: <20060730105731.GA64955@stud.fit.vutbr.cz> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 11:34:15 -0000 --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2006-Jul-30 12:57:32 +0200, Divacky Roman wrote: >while working on SoC linuxolator project I am in a need of this: > >I need to do some operation on memory like mem1 =3D mem1 + mem2 etc. >where the mem1/mem2 access can trigger fault. (memory not mapped or someth= ing) This is normally only an issue for accesses to userland memory, where it is solved by fetch(9) and store(9). If you need to deal with KVM addresses that may be unmapped, then all I can suggest is looking at the implementations of the above functions. --=20 Peter Jeremy --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEzJkz/opHv/APuIcRAlJLAJ9RbU4KpfkGp/AuU306sEzOtOfWmgCePBrV pJcrsVu6VDQ//QzoC+mDHAY= =kz+b -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 12:58:51 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B4A316A4DF for ; Sun, 30 Jul 2006 12:58:51 +0000 (UTC) (envelope-from amdmi3@mail.ru) Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id E404E43D45 for ; Sun, 30 Jul 2006 12:58:50 +0000 (GMT) (envelope-from amdmi3@mail.ru) Received: from [213.148.29.33] (port=35431 helo=nexii.panopticon) by mx3.mail.ru with esmtp id 1G7Asb-000JdQ-00; Sun, 30 Jul 2006 16:58:49 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.2]) by nexii.panopticon (Postfix) with ESMTP id 1FE5F11418; Sun, 30 Jul 2006 16:58:46 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 174F44212; Sun, 30 Jul 2006 16:58:47 +0400 (MSD) Date: Sun, 30 Jul 2006 16:58:46 +0400 From: Dmitry Marakasov To: Matthew Dillon Message-ID: <20060730125846.GA89899@hades.panopticon> Mail-Followup-To: Matthew Dillon , freebsd-hackers@freebsd.org References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> <200607300656.k6U6udJt003335@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200607300656.k6U6udJt003335@apollo.backplane.com> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 12:58:51 -0000 * Matthew Dillon (dillon@apollo.backplane.com) wrote: > Oh, very cute! A terrible hack if you ask me, but cute all the same! I don't consider it a hack. Pretty expected and consistent behaviour - any block device (be it a whole disk or just a partition) is scanned by geom for magic numbers, and if any found, corresponding subdevices do appear. This gives amazing flexibility - you can choose whether to use any partitioning scheme (you can drop slices at all), you are not limited to 4 slices * 7 partitions. Also, you may dd a whole disk image into partition of enough size, and still be able to mount subpartitions of that image (or boot qemu from it) without md(4) overhead (of course MBR slices can be nested as well - you'll get ad0s1s1 or ad1s1as1). Very cute indeed :) -- Best regards, Dmitry mailto:amdmi3@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 14:02:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D2816A4DF for ; Sun, 30 Jul 2006 14:02:13 +0000 (UTC) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD0543D45 for ; Sun, 30 Jul 2006 14:02:13 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 41A56348FA; Sun, 30 Jul 2006 10:02:12 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id E42764AC28; Sun, 30 Jul 2006 10:02:13 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17612.48101.830405.56113@canoe.dclg.ca> Date: Sun, 30 Jul 2006 10:02:13 -0400 To: Dmitry Marakasov In-Reply-To: <20060729141313.GA43548@hades.panopticon> References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 14:02:13 -0000 >>>>> "Dmitry" == Dmitry Marakasov writes: Dmitry> * Matthew Dillon (dillon@apollo.backplane.com) wrote: >> felt that 8 partitions is restrictive. My main home server has 10 >> and the main DragonFly box has 11. >> >> There is another solution for FreeBSD folks, however. You *DO* >> have four slices to play with. You can put a disklabel with 8 >> partitions in it on each one (for 32 total). It isn't as >> convenient, but it does work. Dmitry> About `lack' of partitions - don't forget that labels can be Dmitry> nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get Dmitry> /dev/ad0s1ea. Don't also forget that gpt(8) exists and seems to provide for large numbers of partitions. It even seems to be compiled into GENERIC by default. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 15:01:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCEE416A4E5 for ; Sun, 30 Jul 2006 15:01:12 +0000 (UTC) (envelope-from amdmi3@mail.ru) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3EB643D5E for ; Sun, 30 Jul 2006 15:00:58 +0000 (GMT) (envelope-from amdmi3@mail.ru) Received: from [213.148.29.33] (port=1605 helo=nexii.panopticon) by mx1.mail.ru with esmtp id 1G7Cmn-0001ry-00; Sun, 30 Jul 2006 19:00:57 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.2]) by nexii.panopticon (Postfix) with ESMTP id DDFAC11418; Sun, 30 Jul 2006 19:00:52 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 2276D43CF; Sun, 30 Jul 2006 19:00:54 +0400 (MSD) Date: Sun, 30 Jul 2006 19:00:54 +0400 From: Dmitry Marakasov To: David Gilbert Message-ID: <20060730150054.GA40518@hades.panopticon> Mail-Followup-To: David Gilbert , freebsd-hackers@freebsd.org References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> <17612.48101.830405.56113@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <17612.48101.830405.56113@canoe.dclg.ca> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 15:01:12 -0000 * David Gilbert (dgilbert@dclg.ca) wrote: > Dmitry> About `lack' of partitions - don't forget that labels can be > Dmitry> nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get > Dmitry> /dev/ad0s1ea. > Don't also forget that gpt(8) exists and seems to provide for large > numbers of partitions. It even seems to be compiled into GENERIC by > default. Afaik, one is unable to boot from gpt partitions. However, I myself didn't try it yet. Do gpt fully eliminate need in mbr/bsdlabel partitioning? There is also issue with UFS filesystems and bsdlabel - some filesystem data is stored in label itself: # bsdlabel /dev/ad0s1 # size offset fstype [fsize bsize bps/cpg] a: 262144 0 4.2BSD 2048 16384 16392 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For example, fsck(8) makes use of it - you can newfs /dev/ad0s1a && fsck /dev/ad0s1a but you can't newfs /dev/ad0 && fsck /dev/ad0 the latter will complain about unknown filesystem type and you'll have to use fsck_ufs instead. This shouldn't affect automatic fsck (because of fstab), but I can't guarantee that there are no any other drawbacks. -- Best regards, Dmitry mailto:amdmi3@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 15:53:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF3CF16A4DA for ; Sun, 30 Jul 2006 15:53:58 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64AF443D46 for ; Sun, 30 Jul 2006 15:53:57 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Sun, 30 Jul 2006 23:53:55 +0800 id 00102E04.44CCD613.0001443C References: <20060730105731.GA64955@stud.fit.vutbr.cz> In-Reply-To: <20060730105731.GA64955@stud.fit.vutbr.cz> From: "Intron" To: Divacky Roman Date: Sun, 30 Jul 2006 23:53:55 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 15:53:59 -0000 Divacky Roman wrote: > hi, > > while working on SoC linuxolator project I am in a need of this: > > I need to do some operation on memory like mem1 = mem1 + mem2 etc. > where the mem1/mem2 access can trigger fault. (memory not mapped or something) > > currently I solve this by using pcb_onfault. this must be done in asm (kib@ > told me) so currently the code looks like this: > > futex_fault: > movl PCPU(CURPCB), %edx > movl $0, PCB_ONFAULT(%edx) > movl $-EFAULT, %eax > ret > > /* int futex_xchgl(int oparg, caddr_t uaddr, int *oldval); */ > .globl futex_xchgl > futex_xchgl: > movl PCPU(CURPCB), %eax > movl $futex_fault, PCB_ONFAULT(%eax) > movl 4(%esp), %eax > movl 8(%esp), %edx > > xchgl %eax, (%edx) > movl 0xc(%esp), %edx > movl %eax, (%edx) > xorl %eax, %eax > > movl PCPU(CURPCB), %edx > movl $0, PCB_ONFAULT(%edx) > ret > > this is not very nice nor portable. I wonder if its possible to do something > like this: > > LOCK_VM_SOMEHOW(); > if (!memory_accessible(mem1) || !memory_accessible(mem2)) > return EFAULT; > > mem1 = mem1 + mem2; > > UNLOCK_VM_SOMEHOW(); > > if its possible - what is the LOCK_VM_SOMEHOW lock? and what is the > memory_accessible() function? > > thnx for pointing me to the right directions > > roman > > > ---------------------- > www.liberalnistrana.cz > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" As I know, there're two ways to detect page fault: 1. Look up in page mapping table (i.e. GDT and IDT on x86 or x86_64). See copyin() and copyout() in "/sys/i386/i386/support.s". 2. Capture exception interrupt triggered by CPU (i.e. INT 0x0E on x86 and x86_64) like vm_fault() in "/sys/vm/vm_fault.c". Actually, kernel memory page fault should not arise at all, which means bug made by programmer. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 16:34:35 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62B0216A4DE for ; Sun, 30 Jul 2006 16:34:35 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from outmx011.isp.belgacom.be (outmx011.isp.belgacom.be [195.238.5.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0EFE43D53 for ; Sun, 30 Jul 2006 16:34:34 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx011.isp.belgacom.be (localhost [127.0.0.1]) by outmx011.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6UGYQV9004532 for ; Sun, 30 Jul 2006 18:34:27 +0200 (envelope-from ) Received: from kalimero.kotnet.org (64.211-245-81.adsl-dyn.isp.belgacom.be [81.245.211.64]) by outmx011.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6UGYIrW004462; Sun, 30 Jul 2006 18:34:18 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.6/8.13.6) with ESMTP id k6UGYHKR010674; Sun, 30 Jul 2006 18:34:17 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: kmacy@fsmware.com Date: Sun, 30 Jul 2006 18:34:11 +0200 User-Agent: KMail/1.9.3 References: <200607292110.37733.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5604069.S5Bz4dlXLo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607301834.16657.tijl@ulyssis.org> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 page fault clobbers error code in trap frame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 16:34:35 -0000 --nextPart5604069.S5Bz4dlXLo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 29 July 2006 21:57, Kip Macy wrote: > Looking at siginfo it isn't clear that there is a "right way" to > provide SIGSEGV, eva, and the error code. > > _fault._trapno should contain the machine's error code and si_signo > should contain SIGSEGV, and si_addr contains the faulting pc. Maybe > one could abuse si_code to contain eva. Sorry for asking a question > that has already been answered but where is eva being put currently? si_addr doesn't contain the faulting pc, it contains the address that=20 caused the page fault (i.e. eva). pc at the time of the fault is stored=20 in the sigcontext as sc_eip. But siginfo is ok. The problem is in sigcontext (mostly a copy of=20 trapframe), where sc_err is incorrect. However, it appears that all the=20 relevant code has changed significantly in CURRENT to the point that=20 the offending line can simply be removed. It would be nice if somebody=20 could review/verify/test this, because I don't have CURRENT installed=20 at the moment. =2D-- sys/i386/i386/trap.c.orig Sun Jul 30 18:27:21 2006 +++ sys/i386/i386/trap.c Sun Jul 30 18:27:56 2006 @@ -777,9 +777,6 @@ return (-1); } =2D /* kludge to pass faulting virtual address to sendsig */ =2D frame->tf_err =3D eva; =2D return((rv =3D=3D KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); } --nextPart5604069.S5Bz4dlXLo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEzN+IdMR2xnarec8RAsHKAKDHdOFNszIR4mgbUfzx2kthR3N9eACgrKmR 4deLo0S9sYFtD4DegfegMFA= =x1wM -----END PGP SIGNATURE----- --nextPart5604069.S5Bz4dlXLo-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 17:01:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8432316A4DA for ; Sun, 30 Jul 2006 17:01:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4092843D46 for ; Sun, 30 Jul 2006 17:01:06 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k6UH13WH005888; Sun, 30 Jul 2006 10:01:04 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k6UH13AX005887; Sun, 30 Jul 2006 10:01:03 -0700 (PDT) Date: Sun, 30 Jul 2006 10:01:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200607301701.k6UH13AX005887@apollo.backplane.com> To: David Gilbert References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> <17612.48101.830405.56113@canoe.dclg.ca> Cc: freebsd-hackers@freebsd.org, Dmitry Marakasov Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 17:01:06 -0000 : :>>>>> "Dmitry" == Dmitry Marakasov writes: : :Dmitry> * Matthew Dillon (dillon@apollo.backplane.com) wrote: :>> felt that 8 partitions is restrictive. My main home server has 10 :>> and the main DragonFly box has 11. :>> :>> There is another solution for FreeBSD folks, however. You *DO* :>> have four slices to play with. You can put a disklabel with 8 :>> partitions in it on each one (for 32 total). It isn't as :>> convenient, but it does work. : :Dmitry> About `lack' of partitions - don't forget that labels can be :Dmitry> nested. Just do `bsdlabel -w /dev/ad0s1e` - you'll get :Dmitry> /dev/ad0s1ea. : :Don't also forget that gpt(8) exists and seems to provide for large :numbers of partitions. It even seems to be compiled into GENERIC by :default. : :Dave. Yah, well... I'd be a bit leery of using anything more complex then a basic disklabel. The more complex the setup, the more likely that a disk crash will become unrecoverable. I had an issue a little while back with a disk crash where the OS's insistence on reading numerous sectors at both the beginning and end of the disk before 'recognizing' it as a disk prevented me from being able to access the disk at all, even when all I wanted to do was to make a disk image of e.g. '/dev/ad6' and skip over the bad sectors. It pissed me off so much I rewrote the code in DragonFly to not actually try to interpret a slice or partition table unless something needing the slice or partition table was accessed (like '/dev/ad6s1'). A linked or recursive partition table makes things all that much more fragile. Recursion isn't as big a deal as linking. Linked partition tables are a disaster waiting to happen. No thanks! -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 19:30:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8728016A4DA for ; Sun, 30 Jul 2006 19:30:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1835143D46 for ; Sun, 30 Jul 2006 19:30:46 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so97145nzn for ; Sun, 30 Jul 2006 12:30:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AcmNBm7zjBxK/CyuF7mQZgJQNd7dnq83WRDJdF5RtxIKAsijGub9lKs9L4b1c8axW3MTLXaIIeMJS+CW+sfhk9JvMdxiwo9kwbJVPapsLYhS5vsIa0NxZEJqRcmnsHM//Bjy0JlfAX1PcCBIUpn8ZzPnBlmKYrFg74y+I41vQL4= Received: by 10.65.251.1 with SMTP id d1mr1467109qbs; Sun, 30 Jul 2006 12:30:45 -0700 (PDT) Received: by 10.35.16.20 with HTTP; Sun, 30 Jul 2006 12:30:45 -0700 (PDT) Message-ID: Date: Sun, 30 Jul 2006 12:30:45 -0700 From: "Kip Macy" To: "Tijl Coosemans" In-Reply-To: <200607301834.16657.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200607292110.37733.tijl@ulyssis.org> <200607301834.16657.tijl@ulyssis.org> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 page fault clobbers error code in trap frame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 19:30:46 -0000 > > si_addr doesn't contain the faulting pc, it contains the address that So either the comment is wrong, or that is a technically incorrect kludge. However, given that a number of the other fields are not filled out at all, the real objective should be to keep applications working. > > --- sys/i386/i386/trap.c.orig Sun Jul 30 18:27:21 2006 > +++ sys/i386/i386/trap.c Sun Jul 30 18:27:56 2006 > @@ -777,9 +777,6 @@ > return (-1); > } > > - /* kludge to pass faulting virtual address to sendsig */ > - frame->tf_err = eva; > - > return((rv == KERN_PROTECTION_FAILURE) ? SIGBUS : SIGSEGV); > } > > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 20:03:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDCD416A4DE for ; Sun, 30 Jul 2006 20:03:11 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from outmx013.isp.belgacom.be (outmx013.isp.belgacom.be [195.238.5.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C70B43D46 for ; Sun, 30 Jul 2006 20:03:11 +0000 (GMT) (envelope-from tijl@ulyssis.org) Received: from outmx013.isp.belgacom.be (localhost [127.0.0.1]) by outmx013.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6UK333h001097 for ; Sun, 30 Jul 2006 22:03:03 +0200 (envelope-from ) Received: from kalimero.kotnet.org (64.211-245-81.adsl-dyn.isp.belgacom.be [81.245.211.64]) by outmx013.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22) with ESMTP id k6UK30pN001071; Sun, 30 Jul 2006 22:03:00 +0200 (envelope-from ) Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.13.6/8.13.6) with ESMTP id k6UK2snk016088; Sun, 30 Jul 2006 22:03:00 +0200 (CEST) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: kmacy@fsmware.com Date: Sun, 30 Jul 2006 22:02:50 +0200 User-Agent: KMail/1.9.3 References: <200607292110.37733.tijl@ulyssis.org> <200607301834.16657.tijl@ulyssis.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2788921.PdlsaWxk3Z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607302202.54315.tijl@ulyssis.org> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 page fault clobbers error code in trap frame X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 20:03:11 -0000 --nextPart2788921.PdlsaWxk3Z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 30 July 2006 21:30, Kip Macy wrote: > > si_addr doesn't contain the faulting pc, it contains the address > > that > > So either the comment is wrong, or that is a technically incorrect > kludge. However, given that a number of the other fields are not > filled out at all, the real objective should be to keep applications > working. Well, the comment is correct except in case of a page fault. But this is=20 different from stable. In stable si_addr is a copy of tf_err, which,=20 because of the kludge, holds the fault address in case of a page=20 fault... I'm glad to see this code has been cleaned up. --nextPart2788921.PdlsaWxk3Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQBEzRBudMR2xnarec8RAmj6AJ9u2EP4NlScRtKMU7LiScozggiSkwCdG4EH bqfg49dxTUj5GCpTqcYpYJs= =WqkR -----END PGP SIGNATURE----- --nextPart2788921.PdlsaWxk3Z-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 20:04:01 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCD6216A4E1 for ; Sun, 30 Jul 2006 20:04:01 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35BE543D46 for ; Sun, 30 Jul 2006 20:04:00 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.7/8.13.7) with ESMTP id k6UK3s9m082669 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Jul 2006 22:03:54 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.7/8.13.3/Submit) id k6UK3sRi082667 for hackers@freebsd.org; Sun, 30 Jul 2006 22:03:54 +0200 (CEST) Date: Sun, 30 Jul 2006 22:03:54 +0200 From: Divacky Roman To: hackers@freebsd.org Message-ID: <20060730200354.GA82547@stud.fit.vutbr.cz> References: <20060730105731.GA64955@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060730105731.GA64955@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 20:04:01 -0000 On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote: > hi, > > while working on SoC linuxolator project I am in a need of this: > > I need to do some operation on memory like mem1 = mem1 + mem2 etc. > where the mem1/mem2 access can trigger fault. (memory not mapped or something) to make it clear.. I am trying to access user-space memory from kernel. This needs to be atomic (its an implementation of linux futexes) I need to check from kernel if some memory is accessible and then perform an operation on this memory. All atomically. hence I need two things - function which checks wheter the memory is accessible and something which makes it atomic (some mutex/something which prevents other process to enter VM to unmap/etc. the memory in question) hope its a bit more clear now roman From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 20:47:49 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C1FC16A4DA for ; Sun, 30 Jul 2006 20:47:49 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E01BF43D49 for ; Sun, 30 Jul 2006 20:47:48 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so330493pyb for ; Sun, 30 Jul 2006 13:47:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CWpJ5aXn9p2q2jy3ADe1AaskMaZ5McbRl0D116jpR9Af0eOYUK5ZTUyS9gcYgf+1KiR66oB7kTbEb+0uKssO6nzXeQBc8zP/X/CzGKiG1aOAMZq1xQfc/DrbY9E8GDtgYUSXBNJmqepOy62shdHVDuTNcoCWk6NaOKo3BS1DhLg= Received: by 10.35.41.14 with SMTP id t14mr2837298pyj; Sun, 30 Jul 2006 13:47:47 -0700 (PDT) Received: by 10.35.16.20 with HTTP; Sun, 30 Jul 2006 13:47:47 -0700 (PDT) Message-ID: Date: Sun, 30 Jul 2006 13:47:47 -0700 From: "Kip Macy" To: "Divacky Roman" In-Reply-To: <20060730200354.GA82547@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> Cc: hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 20:47:49 -0000 >From kern_umtx.c: static int _do_lock(struct thread *td, struct umtx *umtx, long id, int timo) { struct umtx_q *uq; intptr_t owner; intptr_t old; int error = 0; uq = td->td_umtxq; /* * Care must be exercised when dealing with umtx structure. It * can fault on any access. */ for (;;) { /* * Try the uncontested case. This should be done in userland. */ owner = casuptr((intptr_t *)&umtx->u_owner, UMTX_UNOWNED, id); /* The acquire succeeded. */ if (owner == UMTX_UNOWNED) return (0); /* The address was invalid. */ if (owner == -1) return (EFAULT); /* If no one owns it but it is contested try to acquire it. */ if (owner == UMTX_CONTESTED) { owner = casuptr((intptr_t *)&umtx->u_owner, UMTX_CONTESTED, id | UMTX_CONTESTED); if (owner == UMTX_CONTESTED) return (0); /* The address was invalid. */ if (owner == -1) return (EFAULT); On 7/30/06, Divacky Roman wrote: > On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote: > > hi, > > > > while working on SoC linuxolator project I am in a need of this: > > > > I need to do some operation on memory like mem1 = mem1 + mem2 etc. > > where the mem1/mem2 access can trigger fault. (memory not mapped or something) > > to make it clear.. I am trying to access user-space memory from kernel. > This needs to be atomic (its an implementation of linux futexes) > > I need to check from kernel if some memory is accessible and then perform an > operation on this memory. All atomically. > > hence I need two things - function which checks wheter the memory is accessible > and something which makes it atomic (some mutex/something which prevents other > process to enter VM to unmap/etc. the memory in question) > > hope its a bit more clear now > > roman > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 30 21:26:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26A9516A4E5 for ; Sun, 30 Jul 2006 21:26:03 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DFB243D67 for ; Sun, 30 Jul 2006 21:25:55 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 009FF20A7; Sun, 30 Jul 2006 23:25:51 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no X-Greylist: delayed 1519 seconds by postgrey-1.24 at tim.des.no; Sun, 30 Jul 2006 23:25:51 CEST Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id E5B2220A5; Sun, 30 Jul 2006 23:25:51 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 24A2933C28; Sun, 30 Jul 2006 23:00:32 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: David Gilbert References: <20060727063936.GA1246@titan.klemm.apsfilter.org> <20060727122159.GB4217@britannica.bec.de> <20060727202528.GA14954@titan.klemm.apsfilter.org> <200607282236.k6SMaRlj089446@apollo.backplane.com> <20060729141313.GA43548@hades.panopticon> <17612.48101.830405.56113@canoe.dclg.ca> <20060730150054.GA40518@hades.panopticon> Date: Sun, 30 Jul 2006 23:00:31 +0200 In-Reply-To: <20060730150054.GA40518@hades.panopticon> (Dmitry Marakasov's message of "Sun, 30 Jul 2006 19:00:54 +0400") Message-ID: <861ws2kdu8.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: disklabel differences FreeBSD, DragonFly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 21:26:03 -0000 Dmitry Marakasov writes: > Afaik, one is unable to boot from gpt partitions. except on EFI machines (Itanium and Intel Macs), but it is possible to combine GPT with an MBR such that you get a bootable partition (if nothing else, GEOM allows you to stick a GPT in a partition or slice) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 06:12:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C84C16A4DD for ; Mon, 31 Jul 2006 06:12:24 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65A0243D66 for ; Mon, 31 Jul 2006 06:12:22 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Mon, 31 Jul 2006 14:12:20 +0800 id 00102DF1.44CD9F44.00017212 References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> In-Reply-To: <20060730200354.GA82547@stud.fit.vutbr.cz> From: "Intron" To: freebsd-hackers@freebsd.org Date: Mon, 31 Jul 2006 14:12:20 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 06:12:24 -0000 Divacky Roman wrote: > On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote: >> hi, >> >> while working on SoC linuxolator project I am in a need of this: >> >> I need to do some operation on memory like mem1 = mem1 + mem2 etc. >> where the mem1/mem2 access can trigger fault. (memory not mapped or something) > > to make it clear.. I am trying to access user-space memory from kernel. > This needs to be atomic (its an implementation of linux futexes) > > I need to check from kernel if some memory is accessible and then perform an > operation on this memory. All atomically. > > hence I need two things - function which checks wheter the memory is accessible > and something which makes it atomic (some mutex/something which prevents other > process to enter VM to unmap/etc. the memory in question) > > hope its a bit more clear now > > roman > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" The manual page mutex(9) says, No mutexes should be held (except for Giant) across functions which access memory in userspace, such as copyin(9), copyout(9), uiomove(9), fuword(9), etc. No locks are needed when calling these functions. Actually, any contents in user space should be copied into kernel space before reading them. They should also be mirrored in kernel space if necessary. Mutex(9) is sometimes too heavy, and has many limitations, while sx(9) is somewhat enough. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 08:59:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8352216A4DA for ; Mon, 31 Jul 2006 08:59:12 +0000 (UTC) (envelope-from mykola.stryebkov@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07C9F43D46 for ; Mon, 31 Jul 2006 08:59:11 +0000 (GMT) (envelope-from mykola.stryebkov@gmail.com) Received: by wx-out-0102.google.com with SMTP id t12so159263wxc for ; Mon, 31 Jul 2006 01:59:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=L/eLnLM3KsSnqBesmEwwqE22G+tEplfmfc5i3dCy2mWQCWFZwiFGoGiDxiDDS3cZdpDhNQeNM/ELAdw8Nm3R5z10wVU0J2zR2xAU7gKkcGa/PoZZ9pEE0+KTzELgZQf/JZ39XWKEFGJwG/jAZsfq+S7hzk9j0bdOSzNFpWGMG+M= Received: by 10.70.133.8 with SMTP id g8mr2433276wxd; Mon, 31 Jul 2006 01:59:10 -0700 (PDT) Received: from localhost ( [67.19.231.54]) by mx.gmail.com with ESMTP id i13sm1473925wxd.2006.07.31.01.59.08; Mon, 31 Jul 2006 01:59:10 -0700 (PDT) Date: Mon, 31 Jul 2006 11:59:06 +0300 To: Intron Message-ID: <20060731085906.GA869@taran.infoua.com.ua> Mail-Followup-To: nick@humgat.org, Intron , freebsd-hackers@freebsd.org References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i From: mykola.stryebkov@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 08:59:12 -0000 On 31.07.2006 14:12:20, Intron wrote: > Mutex(9) is sometimes too heavy, and has many limitations, while sx(9) > is somewhat enough. First paragraph from sx(9) manual says: Shared/exclusive locks are used to protect data that are read far more often than they are written. Mutexes are inherently more efficient than shared/exclusive locks, so shared/exclusive locks should be used prudently. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 09:38:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D4D316A4DA for ; Mon, 31 Jul 2006 09:38:14 +0000 (UTC) (envelope-from admin@intron.ac) Received: from intron.ac (unknown [210.51.165.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D519243D70 for ; Mon, 31 Jul 2006 09:38:09 +0000 (GMT) (envelope-from admin@intron.ac) Received: from localhost (localhost [127.0.0.1]) (uid 1003) by intron.ac with local; Mon, 31 Jul 2006 17:38:07 +0800 id 00102E2D.44CDCF7F.00018427 References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> <20060731085906.GA869@taran.infoua.com.ua> In-Reply-To: <20060731085906.GA869@taran.infoua.com.ua> From: "Intron" To: mykola.stryebkov@gmail.com Date: Mon, 31 Jul 2006 17:38:07 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 09:38:14 -0000 mykola.stryebkov@gmail.com wrote: > On 31.07.2006 14:12:20, Intron wrote: > >> Mutex(9) is sometimes too heavy, and has many limitations, while sx(9) >> is somewhat enough. > > First paragraph from sx(9) manual says: > > Shared/exclusive locks are used to protect data that are read > far more often than they are written. Mutexes are inherently > more efficient than shared/exclusive locks, so shared/exclusive > locks should be used prudently. > > > -- > Nick Strebkov > Public key: http://humgat.org/~nick/pubkey.txt > fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" But sx(9) also says in section "CONTEXT", A thread may hold a shared or exclusive lock on an sx lock while sleep- ing. You may try copyout() when holding a mutex(9) on 7.0-CURRENT. Look out for kernel crash. ------------------------------------------------------------------------ From Beijing, China From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 13:21:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2672B16A4DE; Mon, 31 Jul 2006 13:21:08 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A053A43D46; Mon, 31 Jul 2006 13:21:07 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k6VDL63x080925; Mon, 31 Jul 2006 08:21:06 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CE03D2.2050803@centtech.com> Date: Mon, 31 Jul 2006 08:21:22 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Doug Barton References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> In-Reply-To: <44C8FB65.9020102@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 18:34:54 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 13:21:08 -0000 On 07/27/06 12:44, Doug Barton wrote: > Oliver Fromme wrote: >> Eric Anderson wrote: >> > I'm tired of trying to use rsync or gcp (which doesn't like symlinks >> > often) to copy trees of files/directories using hard links, so I added >> > the gcp-ish options -a and -l. >> > >> > -a is 'archive' mode, which is just a quick form of -PpR. >> >> -P is the default anyway, so -a would only replace -Rp. >> I don't think saving one letter justifies introducing a new >> option. You can use an alias or shell function. >> >> > -l is 'link' mode, where regular files get hard linked instead of copied. >> > >> > So, you can mimic an entire tree with something like: >> > >> > cp -al /from/ /to/ >> > >> > and it's fast too! >> >> You can do the same with existing tools in a portable >> (and thus preferable) way: >> >> cd /from; find -d . | cpio -dumpl /to > > While I don't want to stifle anyone's creativity, I agree with Oliver (and > other posters) on this one. The Unix way of doing things is small programs > that do their jobs well, tied together to accomplish bigger things. > > Doug > Honestly, I agree with the 'Unix way', however if we really took that to heart, there would be no 'cp' at all. We'd use dd instead, along with find, and chmod/chown. But we don't - why? Same reason for adding nearly any option. All the mentions of cpio, pax, tar, etc, are all great, and I know of them, but they are harder to remember, more typing, less 'compatible' in some cases (not all), possibly more prone to human error (typos), etc. The patch doesn't change any current behavior, nor should it be noticed by anyone not looking for it. However, it is useful, and it does make our cp work just like the GNU cp, which eases the migration path for linux->FreeBSD users. I suppose I'm just missing the reason *not* to commit such a simple and useful set of options. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 14:12:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63CBF16A4DE for ; Mon, 31 Jul 2006 14:12:03 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E4F543D99 for ; Mon, 31 Jul 2006 14:11:52 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 56087 invoked by uid 1001); 31 Jul 2006 14:11:51 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 31 Jul 2006 10:11:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.4005.407223.621637@bhuda.mired.org> Date: Mon, 31 Jul 2006 10:11:49 -0400 To: Eric Anderson In-Reply-To: <44CE03D2.2050803@centtech.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 14:12:03 -0000 In <44CE03D2.2050803@centtech.com>, Eric Anderson typed: > The patch doesn't change any current behavior, nor should it be noticed > by anyone not looking for it. However, it is useful, and it does make > our cp work just like the GNU cp, which eases the migration path for > linux->FreeBSD users. Is emulating Linux behavior that good an idea? I mean, if I want Linux, I can download and install a copy. The joke about "Linux is for people who hate Windows; FreeBSD is for people who love Unix" is funny to me *because* it seems to capture the difference between the two systems so accurately. I like Unix/BSD because I feel like the developers respect the user, and are willing to let the user do pretty much anything they need to do, even if there's no obvious reason for them to want that. I detest Windows because the developers treat the the user like an idiot, and write software that does things the way they think the user should want to do them - and make it impossible to do things that the developers don't think users would ever need/want to do. Linux seems to have more of the latter attitude than the former. [And no, I don't think this patch has that attitude; I just don't think that "that's how linux does it" is a valid argument: freebsd isn't linux.] On a lighter note, if we want to ease the migration path for users from other systems, then we should clearly add software to provide a BSOD at random intervals to make Windows users more comfortable. > I suppose I'm just missing the reason *not* to commit such a simple and > useful set of options. Feature bloat. Or, more verbosely, this doesn't add any new functionality to the system, while adding things that we would rather minimize. If the functionality is all that useful, then people should have already created shell code to make this functionality easily available via the tools that already have it. If nobody needs this functionality often enough to have done that, is it something that we want to enshrine in compiled code? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 14:54:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A8C16A4DE; Mon, 31 Jul 2006 14:54:06 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FAC643D49; Mon, 31 Jul 2006 14:54:05 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k6VEs3mo082304; Mon, 31 Jul 2006 09:54:04 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CE199C.2020500@centtech.com> Date: Mon, 31 Jul 2006 09:54:20 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Mike Meyer References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> In-Reply-To: <17614.4005.407223.621637@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 18:34:54 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 14:54:06 -0000 On 07/31/06 09:11, Mike Meyer wrote: > In <44CE03D2.2050803@centtech.com>, Eric Anderson typed: >> The patch doesn't change any current behavior, nor should it be noticed >> by anyone not looking for it. However, it is useful, and it does make >> our cp work just like the GNU cp, which eases the migration path for >> linux->FreeBSD users. > > Is emulating Linux behavior that good an idea? I mean, if I want > Linux, I can download and install a copy. The joke about "Linux is for > people who hate Windows; FreeBSD is for people who love Unix" is funny > to me *because* it seems to capture the difference between the two > systems so accurately. I like Unix/BSD because I feel like the > developers respect the user, and are willing to let the user do pretty > much anything they need to do, even if there's no obvious reason for > them to want that. I detest Windows because the developers treat the > the user like an idiot, and write software that does things the way > they think the user should want to do them - and make it impossible to > do things that the developers don't think users would ever need/want > to do. Linux seems to have more of the latter attitude than the > former. [And no, I don't think this patch has that attitude; I just > don't think that "that's how linux does it" is a valid argument: > freebsd isn't linux.] The -a option that was included in my patch was certainly added for compatibility sake and ease of use. I added it in while I was there to make our cp work with that same shortcut as Linux, not because I love linux (which I'm not that fond of), but because I would use it, and it would be helpful. The -l option was a missing feature, and is what gave me the desire to even look at the code. I obviously wouldn't have spent any time on it if I didn't need it bad enough, and I know of other users that work their way around it by using pipes and cpio, or pax, etc, along with hacking the code that uses those tools to change it from a cp command to their concocted version, but that isn't always an option. The reasoning was not simply to make it like linux, that's just a side effect. >> I suppose I'm just missing the reason *not* to commit such a simple and >> useful set of options. > > Feature bloat. Or, more verbosely, this doesn't add any new > functionality to the system, while adding things that we would rather > minimize. This is a really funny reason not to. Honestly, if you believe that, that you probably don't use cp at all, since dd can do it. In fact, I bet you don't use sysinstall either, right? I hate to be like this, but this is really kind of goofy sounding, as *tons* of tools in FreeBSD are there to make life easier, administration faster, etc. I mean, you use emacs right? Why not just echo the data to the mailer? > If the functionality is all that useful, then people should have > already created shell code to make this functionality easily available > via the tools that already have it. If nobody needs this functionality > often enough to have done that, is it something that we want to > enshrine in compiled code? To me, I read this as saying: "If it was useful, it would have already been done, and since it isn't, it must not be needed by anyone." Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 15:23:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C30D916A4ED for ; Mon, 31 Jul 2006 15:23:15 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 57A1D43D46 for ; Mon, 31 Jul 2006 15:23:14 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 57792 invoked by uid 1001); 31 Jul 2006 15:23:13 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 31 Jul 2006 11:23:13 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.8289.134373.387558@bhuda.mired.org> Date: Mon, 31 Jul 2006 11:23:13 -0400 To: Eric Anderson In-Reply-To: <44CE199C.2020500@centtech.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 15:23:16 -0000 In <44CE199C.2020500@centtech.com>, Eric Anderson typed: > On 07/31/06 09:11, Mike Meyer wrote: > > In <44CE03D2.2050803@centtech.com>, Eric Anderson typed: > >> The patch doesn't change any current behavior, nor should it be noticed > >> by anyone not looking for it. However, it is useful, and it does make > >> our cp work just like the GNU cp, which eases the migration path for > >> linux->FreeBSD users. > > Is emulating Linux behavior that good an idea? I mean, if I want > > Linux, I can download and install a copy. The joke about "Linux is for > > people who hate Windows; FreeBSD is for people who love Unix" is funny > > to me *because* it seems to capture the difference between the two > > systems so accurately. I like Unix/BSD because I feel like the > > developers respect the user, and are willing to let the user do pretty > > much anything they need to do, even if there's no obvious reason for > > them to want that. I detest Windows because the developers treat the > > the user like an idiot, and write software that does things the way > > they think the user should want to do them - and make it impossible to > > do things that the developers don't think users would ever need/want > > to do. Linux seems to have more of the latter attitude than the > > former. [And no, I don't think this patch has that attitude; I just > > don't think that "that's how linux does it" is a valid argument: > > freebsd isn't linux.] > The reasoning was not simply to make it like linux, that's just a side > effect. That doesn't make the "to makes it more like Linux" argument a good reason to change FreeBSD. > >> I suppose I'm just missing the reason *not* to commit such a simple and n> >> useful set of options. > > Feature bloat. Or, more verbosely, this doesn't add any new > > functionality to the system, while adding things that we would rather > > minimize. > This is a really funny reason not to. Honestly, if you believe that, > that you probably don't use cp at all, since dd can do it. Yes, I believe that. Adding features does *not* necessarily improve a system. If you want it added, give us *good* reasons to add it. Lack of a good reason not to add a feature is *not* a good reason to add the feature. Personally, I'm neutral on this change, other than not wanting FreeBSD to bloat any more than it already is. Given good reasons, I'd say commit it. The reasons you just provided are specious. > > If the functionality is all that useful, then people should have > > already created shell code to make this functionality easily available > > via the tools that already have it. If nobody needs this functionality > > often enough to have done that, is it something that we want to > > enshrine in compiled code? > To me, I read this as saying: "If it was useful, it would have already > been done, and since it isn't, it must not be needed by anyone." How does "people would have created shell code to make this easy to do" equate to "someone would have already added an option for it"? You claim that the code provides "useful functionality". If it's useful, then people should be using the alternatives frequently. Command lines that people use frequently tend to get enshrined in shell scripts, or aliases, or shell functions, or whatever. Moving such things into commands is a standard path for Unix code, and has been since at least v6. So, if you want to take that step, can you show that it's really used frequently enough to warrant getting a dedicated option? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 15:46:21 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F00A16A4DF for ; Mon, 31 Jul 2006 15:46:21 +0000 (UTC) (envelope-from mykola.stryebkov@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5742A43D5C for ; Mon, 31 Jul 2006 15:46:20 +0000 (GMT) (envelope-from mykola.stryebkov@gmail.com) Received: by wx-out-0102.google.com with SMTP id t12so214137wxc for ; Mon, 31 Jul 2006 08:46:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:user-agent:from; b=LjRblKLCImLvBP2qrCAC9ptxLOfRkY5ZwgLarMQDOngIu9aKKnvyOai80ChxJ610aPJ0ED2lLjEPc/THrZinIfC//oopeBcik1ieOUNRnyrIgRlqM2IlCLk3bT2au25iOQNE++sgePACcn0/BihetQV2xXv+puj2zzfHf0jNwJU= Received: by 10.70.68.11 with SMTP id q11mr2806299wxa; Mon, 31 Jul 2006 08:46:18 -0700 (PDT) Received: from localhost ( [67.19.231.54]) by mx.gmail.com with ESMTP id i37sm979088wxd.2006.07.31.08.46.16; Mon, 31 Jul 2006 08:46:17 -0700 (PDT) Date: Mon, 31 Jul 2006 18:46:12 +0300 To: hackers@freebsd.org Message-ID: <20060731154612.GA2921@taran.infoua.com.ua> Mail-Followup-To: nick@humgat.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline User-Agent: Mutt/1.4.2.1i From: mykola.stryebkov@gmail.com Cc: Subject: _getlogin() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 15:46:21 -0000 Hi, Where can i find source of subj? /usr/src/lib/libc/gen/getlogin.c has the declaration of this function, but i'm unable to find its definition. Thanks. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 15:47:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 539B516A4DE for ; Mon, 31 Jul 2006 15:47:25 +0000 (UTC) (envelope-from juan.fco.rodriguez@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5035543D76 for ; Mon, 31 Jul 2006 15:47:11 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: by wx-out-0102.google.com with SMTP id t12so214263wxc for ; Mon, 31 Jul 2006 08:47:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=opEHemMuK6Scv5PYcWrjK3PSqjprwXAKMjuufbAah9mjw+oqdSO2SV7rE+7XnSTtZHnLJsHsciWq2EFqkFhxTLLlyRprFPfrehanFht33khzCOgy3Kelg3//04IrnmXf1Aj1lkcjKKlN9ID+aRnktor79t44Wtd50m89rtEwsB4= Received: by 10.70.102.5 with SMTP id z5mr2881706wxb; Mon, 31 Jul 2006 08:47:09 -0700 (PDT) Received: by 10.70.37.19 with HTTP; Mon, 31 Jul 2006 08:47:09 -0700 (PDT) Message-ID: <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> Date: Mon, 31 Jul 2006 17:47:09 +0200 From: "Juan Rodriguez" To: freebsd-hackers@freebsd.org In-Reply-To: <17614.8289.134373.387558@bhuda.mired.org> MIME-Version: 1.0 References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 15:47:25 -0000 On 7/31/06, Mike Meyer wrote: > > In <44CE199C.2020500@centtech.com>, Eric Anderson > typed: > > On 07/31/06 09:11, Mike Meyer wrote: > > > In <44CE03D2.2050803@centtech.com>, Eric Anderson < > anderson@centtech.com> typed: > > >> The patch doesn't change any current behavior, nor should it be > noticed > > >> by anyone not looking for it. However, it is useful, and it does > make > > >> our cp work just like the GNU cp, which eases the migration path for > > >> linux->FreeBSD users. > > > Is emulating Linux behavior that good an idea? I mean, if I want > > > Linux, I can download and install a copy. The joke about "Linux is for > > > people who hate Windows; FreeBSD is for people who love Unix" is funny > > > to me *because* it seems to capture the difference between the two > > > systems so accurately. I like Unix/BSD because I feel like the > > > developers respect the user, and are willing to let the user do pretty > > > much anything they need to do, even if there's no obvious reason for > > > them to want that. I detest Windows because the developers treat the > > > the user like an idiot, and write software that does things the way > > > they think the user should want to do them - and make it impossible to > > > do things that the developers don't think users would ever need/want > > > to do. Linux seems to have more of the latter attitude than the > > > former. [And no, I don't think this patch has that attitude; I just > > > don't think that "that's how linux does it" is a valid argument: > > > freebsd isn't linux.] > > The reasoning was not simply to make it like linux, that's just a side > > effect. > > That doesn't make the "to makes it more like Linux" argument a good > reason to change FreeBSD. > > > >> I suppose I'm just missing the reason *not* to commit such a simple > and > n> >> useful set of options. > > > Feature bloat. Or, more verbosely, this doesn't add any new > > > functionality to the system, while adding things that we would rather > > > minimize. > > This is a really funny reason not to. Honestly, if you believe that, > > that you probably don't use cp at all, since dd can do it. > > Yes, I believe that. Adding features does *not* necessarily improve a > system. If you want it added, give us *good* reasons to add it. Lack > of a good reason not to add a feature is *not* a good reason to add > the feature. > > Personally, I'm neutral on this change, other than not wanting FreeBSD > to bloat any more than it already is. Given good reasons, I'd say > commit it. The reasons you just provided are specious. > > > > If the functionality is all that useful, then people should have > > > already created shell code to make this functionality easily available > > > via the tools that already have it. If nobody needs this functionality > > > often enough to have done that, is it something that we want to > > > enshrine in compiled code? > > To me, I read this as saying: "If it was useful, it would have already > > been done, and since it isn't, it must not be needed by anyone." > > How does "people would have created shell code to make this easy to > do" equate to "someone would have already added an option for it"? You > claim that the code provides "useful functionality". If it's useful, > then people should be using the alternatives frequently. Command lines > that people use frequently tend to get enshrined in shell scripts, or > aliases, or shell functions, or whatever. Moving such things into > commands is a standard path for Unix code, and has been since at least > v6. So, if you want to take that step, can you show that it's really > used frequently enough to warrant getting a dedicated option? > > -- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Hello, My GNU version of "cp" has more than 18 options, the FreeBSD version only has 9. As I usually work with Linux machines, I'm used to "cp -a" and I have always hated to have to look up in the FreeBSD's "cp" manual page for the right options to get the same funtionality. I tend to think that "-a" is option bloating because it's not really needed, but I see "-l" as a new feature for "cp" that might be useful. I'm not a unix/linux expert but when I have to copy something, "cp" shows up inmediately in my mind (I almost never use "cpio" and I didn't know "pax", for example). To sum it up, I think "cp -a" and "cp -l" are both useful, the first one because of compatibility with the large base of Linux systems out there, and the second one because I think it's a useful feature for the FreeBSD "cp". This is only my personal experience, though I understand that if you want to protect "cp" for having more than 10 options, these options shouldn't see the sunlight :P -- JFRH From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 16:08:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E96816A4E1 for ; Mon, 31 Jul 2006 16:08:08 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id E759843D46 for ; Mon, 31 Jul 2006 16:08:07 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 59114 invoked by uid 1001); 31 Jul 2006 16:08:07 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 31 Jul 2006 12:08:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.10982.499561.139268@bhuda.mired.org> Date: Mon, 31 Jul 2006 12:08:06 -0400 To: "Juan Rodriguez" In-Reply-To: <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 16:08:08 -0000 In <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com>, Juan Rodriguez typed: > On 7/31/06, Mike Meyer wrote: > My GNU version of "cp" has more than 18 options, the FreeBSD > version only has 9. And this results in: student% uname -a Linux student.mired.org 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 GNU/Linux student% ls -l /bin/cp -rwxr-xr-x 1 root root 51008 2005-09-05 05:14 /bin/cp snake% uname -a FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 snake% ls -l /bin/cp -r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 16:26:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E429416A56D for ; Mon, 31 Jul 2006 16:26:41 +0000 (UTC) (envelope-from juan.fco.rodriguez@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD4743D46 for ; Mon, 31 Jul 2006 16:26:40 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so891818uge for ; Mon, 31 Jul 2006 09:26:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PzpP9YwjHWHNLh8rdAxsfP95mGD3jLSKR4sWlUsSLGFUAucSe4PS9/aDQIpQOCs5Uu9LOlzg/Ci6T91SuHxswbllxfbTHNtoNbF/EEmUr2tKdMk/n2MHRzy8KPbif3Ve/8VcDa0h9aTWyjmoMNS1ZkRd0OQmNjZStVB109rI8lM= Received: by 10.78.165.13 with SMTP id n13mr245356hue; Mon, 31 Jul 2006 09:26:39 -0700 (PDT) Received: by 10.70.37.19 with HTTP; Mon, 31 Jul 2006 09:26:39 -0700 (PDT) Message-ID: <96b30c400607310926g76213454l73a51f2d50251cf9@mail.gmail.com> Date: Mon, 31 Jul 2006 18:26:39 +0200 From: "Juan Rodriguez" To: freebsd-hackers@freebsd.org In-Reply-To: <17614.10982.499561.139268@bhuda.mired.org> MIME-Version: 1.0 References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 16:26:42 -0000 On 7/31/06, Mike Meyer wrote: > > In <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com>, Juan > Rodriguez typed: > > On 7/31/06, Mike Meyer > wrote: > > My GNU version of "cp" has more than 18 options, the FreeBSD > > version only has 9. > > And this results in: > > student% uname -a > Linux student.mired.org 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686 > GNU/Linux > student% ls -l /bin/cp > -rwxr-xr-x 1 root root 51008 2005-09-05 05:14 /bin/cp > > > snake% uname -a > FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 > 04:42:56 UTC 2006 root@opus.cse.buffalo.edu > :/usr/obj/usr/src/sys/SMP i386 > snake% ls -l /bin/cp > -r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp > > > -- > Mike Meyer > http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > I've just realized that the manual page of FreeBSD's "cp" warns about hard links: -R ...blablabla... Note that cp copies hard linked files as separate files. If you need to preserve hard links, consider using tar(1), cpio(1), or pax(1) instead. -- JFRH From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 16:54:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FCEB16A4DA for ; Mon, 31 Jul 2006 16:54:32 +0000 (UTC) (envelope-from raistlin@tacorp.net) Received: from mail.tacorp.net (mail.tacorp.net [64.254.140.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E68543D46 for ; Mon, 31 Jul 2006 16:54:31 +0000 (GMT) (envelope-from raistlin@tacorp.net) Received: from localhost (localhost [127.0.0.1]) by mail.tacorp.net (Postfix) with ESMTP id 9902C1B5027; Mon, 31 Jul 2006 12:54:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at tacorp.net Received: from mail.tacorp.net ([127.0.0.1]) by localhost (mail.tacorp.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAK6fGHsjUqt; Mon, 31 Jul 2006 12:54:29 -0400 (EDT) Received: by mail.tacorp.net (Postfix, from userid 1002) id 52D841B5053; Mon, 31 Jul 2006 12:54:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.tacorp.net (Postfix) with ESMTP id 514E71B504E; Mon, 31 Jul 2006 12:54:29 -0400 (EDT) Date: Mon, 31 Jul 2006 12:54:29 -0400 (EDT) From: Jason Slagle To: Mike Meyer In-Reply-To: <17614.10982.499561.139268@bhuda.mired.org> Message-ID: <20060731124934.A4444@mail.tacorp.net> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Juan Rodriguez Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 16:54:32 -0000 On Mon, 31 Jul 2006, Mike Meyer wrote: > snake% uname -a > FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 > snake% ls -l /bin/cp > -r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp > > flea# ls -l cp -rwxr-xr-x 1 root wheel 15300 Jul 31 12:52 cp flea# ./cp -a cp.o cp.o.2 flea# ./cp usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-apv] source_file target_file cp [-R [-H | -L | -P]] [-f | -i | -n] [-apv] source_file ... target_directory flea# ls -l /bin/cp -r-xr-xr-x 1 root wheel 15300 Apr 24 13:55 /bin/cp flea# Looks to me with optimizations, the addition of the option seems to add nothing for the -a case at least. Jason -- Jason Slagle /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail . From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 17:12:51 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3C9116A4DD for ; Mon, 31 Jul 2006 17:12:50 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D17543D45 for ; Mon, 31 Jul 2006 17:12:49 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so917776uge for ; Mon, 31 Jul 2006 10:12:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fCCt05dPrbXrq+0uQv/KItOO9C2BncjMMPwyQ1wBwjwgty6HPxdIwJa4lA08Lps5+xAanohrcdJqYjdWOb8j0iT2DODMYHbtncJliAcb6UITnK6IIAs95GHDM65rLd6AUqUfmCg6SjWeXByMspXi1PxYitkg8R96nB4BPNJcWEE= Received: by 10.78.167.12 with SMTP id p12mr603340hue; Mon, 31 Jul 2006 10:12:48 -0700 (PDT) Received: by 10.78.50.6 with HTTP; Mon, 31 Jul 2006 10:12:48 -0700 (PDT) Message-ID: <84dead720607311012q42e5dapf83e73653e245ae0@mail.gmail.com> Date: Mon, 31 Jul 2006 22:42:48 +0530 From: "Joseph Koshy" To: nick@humgat.org, hackers@freebsd.org In-Reply-To: <20060731154612.GA2921@taran.infoua.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060731154612.GA2921@taran.infoua.com.ua> Cc: Subject: Re: _getlogin() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:12:51 -0000 > Where can i find source of subj? > /usr/src/lib/libc/gen/getlogin.c has > the declaration of this function, but i'm unable > to find its definition. Its generated as part of the C library build. See: src/lib/libc/i386/sys/Makefile.inc src/lib/libc/sys/Makefile.inc sys/lib/libc/i386/SYS.h -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 17:29:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AD6816A4DF for ; Mon, 31 Jul 2006 17:29:00 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id AA07843D53 for ; Mon, 31 Jul 2006 17:28:59 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 84245 invoked by uid 2001); 31 Jul 2006 17:28:58 -0000 Date: Mon, 31 Jul 2006 12:28:58 -0500 From: "Rick C. Petty" To: Juan Rodriguez Message-ID: <20060731172858.GA84042@megan.kiwi-computer.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:29:00 -0000 On Mon, Jul 31, 2006 at 05:47:09PM +0200, Juan Rodriguez wrote: > > My GNU version of "cp" has more than 18 options, the FreeBSD > version only has 9. > > As I usually work with Linux machines, I'm used to "cp -a" and I have always > hated to have to look up in the FreeBSD's "cp" manual page for the right > options to get the same funtionality. I tend to think > that "-a" is option bloating because it's not really needed, but I see > "-l" as a new feature for "cp" that might be useful. I agree, -a is bloat. However I don't understand why you say: > To sum it up, I think "cp -a" and "cp -l" are both useful, I agree that the "-l" option *may* be useful. > the first one > because of compatibility with the large base of Linux systems out there, and > the second one because I think it's a useful feature for the FreeBSD "cp". In both cases, why don't you just use: /usr/compat/linux/bin/cp If you're not going to add all 18 options to our cp, then -a shouldn't be added at all. It doesn't provide any useful functionality, and the argument to make it more compatible with Linux is silly unless you add the other 9 options. If you want the linux cp, use the linux cp. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 17:42:00 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E845B16A4DE for ; Mon, 31 Jul 2006 17:41:59 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D47DB43D92 for ; Mon, 31 Jul 2006 17:41:47 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k6VHfk3J009828; Mon, 31 Jul 2006 12:41:46 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CE40EA.5080009@centtech.com> Date: Mon, 31 Jul 2006 12:42:02 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> In-Reply-To: <20060731172858.GA84042@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 18:34:54 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Juan Rodriguez Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:42:00 -0000 On 07/31/06 12:28, Rick C. Petty wrote: > On Mon, Jul 31, 2006 at 05:47:09PM +0200, Juan Rodriguez wrote: >> My GNU version of "cp" has more than 18 options, the FreeBSD >> version only has 9. >> >> As I usually work with Linux machines, I'm used to "cp -a" and I have always >> hated to have to look up in the FreeBSD's "cp" manual page for the right >> options to get the same funtionality. I tend to think >> that "-a" is option bloating because it's not really needed, but I see >> "-l" as a new feature for "cp" that might be useful. > > I agree, -a is bloat. However I don't understand why you say: > >> To sum it up, I think "cp -a" and "cp -l" are both useful, > > I agree that the "-l" option *may* be useful. > >> the first one >> because of compatibility with the large base of Linux systems out there, and >> the second one because I think it's a useful feature for the FreeBSD "cp". > > In both cases, why don't you just use: > > /usr/compat/linux/bin/cp Two reasons - it's not in the base system, so a port has to be installed - and linux_base is FC3 now, so if you want to talk about bloat... Another reason is gcp fails to recursively copy a directory that has symlinks in it. Example: $ cd /tmp/ $ mkdir test $ touch test/t $ ln -s t test/b $ ls -al test/ drwxr-xr-x 2 anderson wheel 512 Jul 7 09:39 . drwxrwxrwt 69 root wheel 8704 Jul 7 09:39 .. lrwxr-xr-x 1 anderson wheel 1 Jul 7 09:39 b -> t -rw-r--r-- 1 anderson wheel 0 Jul 7 09:39 t $ gcp -al test/ test2/ $ ls -al test2/ drwxr-xr-x 2 anderson wheel 512 Jul 7 09:39 . drwxrwxrwt 70 root wheel 8704 Jul 7 09:40 .. -rw-r--r-- 3 anderson wheel 0 Jul 7 09:39 b -rw-r--r-- 3 anderson wheel 0 Jul 7 09:39 t ( you can see it made a resolved the symlink and made a hardlink to the symlink destination, not exactly what I would want, but didn't fail) However, now do: $ ln -s /tmp/ test/link-to-dir $ ls -al test/ drwxr-xr-x 2 anderson wheel 512 Jul 7 09:43 . drwxrwxrwt 70 root wheel 8704 Jul 7 09:40 .. lrwxr-xr-x 1 anderson wheel 1 Jul 7 09:39 b -> t lrwxr-xr-x 1 anderson wheel 5 Jul 7 09:43 link-to-dir -> /tmp/ -rw-r--r-- 3 anderson wheel 0 Jul 7 09:39 t $ gcp -al test/ test2/ gcp: cannot create link `test2/test/link-to-dir': Operation not permitted gcp gets an error when copying symlinks that point to directories. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 17:54:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4C7716A4DE for ; Mon, 31 Jul 2006 17:54:33 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id ED05743D46 for ; Mon, 31 Jul 2006 17:54:32 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 61691 invoked by uid 1001); 31 Jul 2006 17:54:32 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 31 Jul 2006 13:54:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.17367.666515.448013@bhuda.mired.org> Date: Mon, 31 Jul 2006 13:54:31 -0400 To: rick-freebsd@kiwi-computer.com In-Reply-To: <20060731172858.GA84042@megan.kiwi-computer.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Juan Rodriguez Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 17:54:33 -0000 > the first one because of compatibility with the large base of Linux systems > out there, I'll say it again: Being compatible with some other system is *not* a reason to add something to FreeBSD. Sure, if we decide a feature is useful, then there's a lot to be said for making it compatible with other systems that already offer that functionality. But adding a feature just to add compatibility is nothing but bloat. And it *doesn't matter* how large a base of users that other systems has. I don't run FreeBSD because it's popular; I run it because I believe it's the best solution to my problems. I believe that's true because we - and CSRG before us, and Bell Labs before them - worry more about quality than about popularity (well, at least if you ignore OSI). If I wanted a popular OS, I'd run Windows. If I wanted a popular Unix, I'd run OSX. Turning FreeBSD into Linux is no more desirable than turning it into Windows. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 18:15:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DCCC16A4E1 for ; Mon, 31 Jul 2006 18:15:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB77A43D55 for ; Mon, 31 Jul 2006 18:15:12 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id t12so236722wxc for ; Mon, 31 Jul 2006 11:15:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=tBxzkcZiic1uDautFoPEjEUCDIjeac7YArbEzFNH+t2UgQBu6UwMZe0lRIMN+k5uh9RU4+GcHa0r8KcaKEUv+k4pBmCNFoqLWCca5PlydEY/CRhs4FgKmpATsWstgCXjzzzuIxS7kHVc5zK5HFEsS8jofguCWt00aDcx0p4KbF4= Received: by 10.70.80.3 with SMTP id d3mr3108367wxb; Mon, 31 Jul 2006 11:15:12 -0700 (PDT) Received: by 10.70.11.18 with HTTP; Mon, 31 Jul 2006 11:15:11 -0700 (PDT) Message-ID: <3bbf2fe10607311115ua9b7b9axd9d3e6dcff2c1daf@mail.gmail.com> Date: Mon, 31 Jul 2006 20:15:11 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Divacky Roman" In-Reply-To: <20060730200354.GA82547@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> X-Google-Sender-Auth: 9e82a4bd3d8b3797 Cc: freebsd-hackers@freebsd.org Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:15:13 -0000 2006/7/30, Divacky Roman : > On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote: > > hi, > > > > while working on SoC linuxolator project I am in a need of this: > > > > I need to do some operation on memory like mem1 = mem1 + mem2 etc. > > where the mem1/mem2 access can trigger fault. (memory not mapped or something) > > to make it clear.. I am trying to access user-space memory from kernel. > This needs to be atomic (its an implementation of linux futexes) > > I need to check from kernel if some memory is accessible and then perform an > operation on this memory. All atomically. > > hence I need two things - function which checks wheter the memory is accessible > and something which makes it atomic (some mutex/something which prevents other > process to enter VM to unmap/etc. the memory in question) > > hope its a bit more clear now You would use something like: #include #include #include #include #include #include #include #include ... int lock_and_fetch(const void* mem1, const void *mem2) { mtx_lock(&vm_page_queue_mtx); if (fubyte(mem1) == -1 || fubyte(mem2) == -1) { mtx_unlock(&vm_page_queue_mtx); return(EINVAL); } /* Operations... */ mtx_unlock(&vm_page_queue_mtx); return(0); } It prevents to virtual pages to be passed through queues. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 18:24:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B311916A4E2; Mon, 31 Jul 2006 18:24:11 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89E6C43D67; Mon, 31 Jul 2006 18:24:00 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k6VIO0vD030151; Mon, 31 Jul 2006 13:24:00 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CE4AD0.60409@centtech.com> Date: Mon, 31 Jul 2006 13:24:16 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Mike Meyer References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> In-Reply-To: <17614.8289.134373.387558@bhuda.mired.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 18:34:54 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:24:11 -0000 On 07/31/06 10:23, Mike Meyer wrote: > In <44CE199C.2020500@centtech.com>, Eric Anderson typed: >> On 07/31/06 09:11, Mike Meyer wrote: >>> In <44CE03D2.2050803@centtech.com>, Eric Anderson typed: >>>> The patch doesn't change any current behavior, nor should it be noticed >>>> by anyone not looking for it. However, it is useful, and it does make >>>> our cp work just like the GNU cp, which eases the migration path for >>>> linux->FreeBSD users. >>> Is emulating Linux behavior that good an idea? I mean, if I want >>> Linux, I can download and install a copy. The joke about "Linux is for >>> people who hate Windows; FreeBSD is for people who love Unix" is funny >>> to me *because* it seems to capture the difference between the two >>> systems so accurately. I like Unix/BSD because I feel like the >>> developers respect the user, and are willing to let the user do pretty >>> much anything they need to do, even if there's no obvious reason for >>> them to want that. I detest Windows because the developers treat the >>> the user like an idiot, and write software that does things the way >>> they think the user should want to do them - and make it impossible to >>> do things that the developers don't think users would ever need/want >>> to do. Linux seems to have more of the latter attitude than the >>> former. [And no, I don't think this patch has that attitude; I just >>> don't think that "that's how linux does it" is a valid argument: >>> freebsd isn't linux.] >> The reasoning was not simply to make it like linux, that's just a side >> effect. > > That doesn't make the "to makes it more like Linux" argument a good > reason to change FreeBSD. > >>>> I suppose I'm just missing the reason *not* to commit such a simple and > n> >> useful set of options. >>> Feature bloat. Or, more verbosely, this doesn't add any new >>> functionality to the system, while adding things that we would rather >>> minimize. >> This is a really funny reason not to. Honestly, if you believe that, >> that you probably don't use cp at all, since dd can do it. > > Yes, I believe that. Adding features does *not* necessarily improve a > system. If you want it added, give us *good* reasons to add it. Lack > of a good reason not to add a feature is *not* a good reason to add > the feature. > > Personally, I'm neutral on this change, other than not wanting FreeBSD > to bloat any more than it already is. Given good reasons, I'd say > commit it. The reasons you just provided are specious. You don't sound neutral at all actually, but ok. I suppose I thought the reasons were obvious - to get a hardlinked copy of a directory tree, one must concoct any one of a number of command lines, all using at least one of which is much bigger in size than the patched cp I proposed. Here are some of the commands mentioned so far that are used by people to do the exact same thing: -r-xr-xr-x 1 root wheel 50056 Jul 25 23:08 /usr/bin/bsdtar -r-xr-xr-x 1 root wheel 52600 Jul 25 23:07 /usr/bin/cpio -r-xr-xr-x 1 root wheel 36480 Jul 25 23:08 /usr/bin/find -r-xr-xr-x 1 root wheel 90376 Jul 25 23:06 /bin/pax And here's my patched version of cp: -r-xr-xr-x 1 root wheel 15460 Jul 26 14:52 /bin/cp So yes, you bloat by 160 bytes, but you can then possibly remove your need for one or more utilities that eat up at least twice the space. The -a option isn't as much of a useful option, but it keeps life nice and simple for those of us with only FreeBSD systems. If the -a option is an issue, then ignore it. >>> If the functionality is all that useful, then people should have >>> already created shell code to make this functionality easily available >>> via the tools that already have it. If nobody needs this functionality >>> often enough to have done that, is it something that we want to >>> enshrine in compiled code? >> To me, I read this as saying: "If it was useful, it would have already >> been done, and since it isn't, it must not be needed by anyone." > > How does "people would have created shell code to make this easy to > do" equate to "someone would have already added an option for it"? You > claim that the code provides "useful functionality". If it's useful, > then people should be using the alternatives frequently. Command lines > that people use frequently tend to get enshrined in shell scripts, or > aliases, or shell functions, or whatever. Moving such things into > commands is a standard path for Unix code, and has been since at least > v6. So, if you want to take that step, can you show that it's really > used frequently enough to warrant getting a dedicated option? People do make scripts to get around it, and they've posted their own 'heres what I do' on this list in this thread. People even use tools like rsync for it too. There's a lot of people working around it in various ways, that's what gave me the reason to post it to the list. Anyway, it's apparent that those who are against the extra features post louder than those who could use them, so feel free to ignore the patch altogether if you wish. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 18:44:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 499EB16A4DD for ; Mon, 31 Jul 2006 18:44:57 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A49F43D53 for ; Mon, 31 Jul 2006 18:44:55 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 84700 invoked by uid 2001); 31 Jul 2006 18:44:55 -0000 Date: Mon, 31 Jul 2006 13:44:55 -0500 From: "Rick C. Petty" To: Eric Anderson Message-ID: <20060731184454.GA84483@megan.kiwi-computer.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CE40EA.5080009@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:44:57 -0000 On Mon, Jul 31, 2006 at 12:42:02PM -0500, Eric Anderson wrote: > On 07/31/06 12:28, Rick C. Petty wrote: > > > >In both cases, why don't you just use: > > > >/usr/compat/linux/bin/cp > > Two reasons - it's not in the base system, so a port has to be installed > - and linux_base is FC3 now, so if you want to talk about bloat... And the "-l" option is needed in single-user mode? I like not having extra bloat around when I don't even have /usr mounted and am trying to fix a disk or misconfiguration. I'm just arguing the usefulness of having it in the base system vs. using linux_base. The argument that our cp should be equivalent to gcp seems silly to me. "-l" may be a useful option, but at what point is the line drawn between bloating our base cp and having a gcp port (or using linux_base)?? "-a" certainly is useless. An alias is far more useful-- even for things in /bin ! I certainly cp and mv mapped to "cp -i" and "mv -i".. one could also argue that the our base versions of these use this option by default. Personally, I prefer to do a post-install patch to add these aliases to /etc/csh.cshrc (actually on my systems: /etc/csh.aliases) and /etc/profile, etc. > Another reason is gcp fails to recursively copy a directory that has > symlinks in it. That sounds like a bug or at least an oversight. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 18:53:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 710A916A4DE for ; Mon, 31 Jul 2006 18:53:11 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D82543D4C for ; Mon, 31 Jul 2006 18:52:58 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k6VIqvW1021091; Mon, 31 Jul 2006 13:52:57 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CE5199.3050903@centtech.com> Date: Mon, 31 Jul 2006 13:53:13 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> In-Reply-To: <20060731184454.GA84483@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 18:34:54 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:53:11 -0000 On 07/31/06 13:44, Rick C. Petty wrote: > On Mon, Jul 31, 2006 at 12:42:02PM -0500, Eric Anderson wrote: >> On 07/31/06 12:28, Rick C. Petty wrote: >>> In both cases, why don't you just use: >>> >>> /usr/compat/linux/bin/cp >> Two reasons - it's not in the base system, so a port has to be installed >> - and linux_base is FC3 now, so if you want to talk about bloat... > > And the "-l" option is needed in single-user mode? I like not having extra > bloat around when I don't even have /usr mounted and am trying to fix a > disk or misconfiguration. I'm just arguing the usefulness of having it in > the base system vs. using linux_base. The argument that our cp should be > equivalent to gcp seems silly to me. I never once said our cp should be equivalent. I just provided a patch that added 2 simple arguments, not the other 10 (or whatever the number is). > "-l" may be a useful option, but at what point is the line drawn between > bloating our base cp and having a gcp port (or using linux_base)?? I don't know, and I'm not (obviously) the one to make those decisions. > "-a" certainly is useless. An alias is far more useful-- even for things > in /bin ! I certainly cp and mv mapped to "cp -i" and "mv -i".. one could > also argue that the our base versions of these use this option by default. > Personally, I prefer to do a post-install patch to add these aliases to > /etc/csh.cshrc (actually on my systems: /etc/csh.aliases) and /etc/profile, > etc. > >> Another reason is gcp fails to recursively copy a directory that has >> symlinks in it. > > That sounds like a bug or at least an oversight. I'm just a FreeBSD user, so what do I know? I'll just do as others have kindly suggested, and keep my patches to my local servers/systems. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 18:53:31 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89D8E16A534 for ; Mon, 31 Jul 2006 18:53:31 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 15F9543D7D for ; Mon, 31 Jul 2006 18:53:19 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 63437 invoked by uid 1001); 31 Jul 2006 18:53:16 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 31 Jul 2006 14:53:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17614.20892.315747.115331@bhuda.mired.org> Date: Mon, 31 Jul 2006 14:53:16 -0400 To: Eric Anderson In-Reply-To: <44CE4AD0.60409@centtech.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <44CE4AD0.60409@centtech.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 18:53:31 -0000 In <44CE4AD0.60409@centtech.com>, Eric Anderson typed: > On 07/31/06 10:23, Mike Meyer wrote: > > In <44CE199C.2020500@centtech.com>, Eric Anderson typed: > >> On 07/31/06 09:11, Mike Meyer wrote: > >>>> I suppose I'm just missing the reason *not* to commit such a simple and > > n> >> useful set of options. > >>> Feature bloat. Or, more verbosely, this doesn't add any new > >>> functionality to the system, while adding things that we would rather > >>> minimize. > >> This is a really funny reason not to. Honestly, if you believe that, > >> that you probably don't use cp at all, since dd can do it. > > > > Yes, I believe that. Adding features does *not* necessarily improve a > > system. If you want it added, give us *good* reasons to add it. Lack > > of a good reason not to add a feature is *not* a good reason to add > > the feature. > > > > Personally, I'm neutral on this change, other than not wanting FreeBSD > > to bloat any more than it already is. Given good reasons, I'd say > > commit it. The reasons you just provided are specious. > You don't sound neutral at all actually, but ok. I'm as neutral as I'd be about *any* other addition. I don't have a specific reason to dislike it. But I don't have a specific reason to like it, either. The last time I wanted a hardlinked copy of a directory tree was long enough ago that most (if not all) of the alternative solutions mentioned here didn't exist yet. > I suppose I thought > the reasons were obvious - to get a hardlinked copy of a directory tree, > one must concoct any one of a number of command lines, all using at > least one of which is much bigger in size than the patched cp I > proposed. Here are some of the commands mentioned so far that are used > by people to do the exact same thing: > > -r-xr-xr-x 1 root wheel 50056 Jul 25 23:08 /usr/bin/bsdtar > -r-xr-xr-x 1 root wheel 52600 Jul 25 23:07 /usr/bin/cpio > -r-xr-xr-x 1 root wheel 36480 Jul 25 23:08 /usr/bin/find > -r-xr-xr-x 1 root wheel 90376 Jul 25 23:06 /bin/pax > And here's my patched version of cp: > -r-xr-xr-x 1 root wheel 15460 Jul 26 14:52 /bin/cp > > So yes, you bloat by 160 bytes, but you can then possibly remove your > need for one or more utilities that eat up at least twice the space. So are you proposing that we remove one of those utilities? If not, then you are bloating the system. Yeah, it's only by a little bit. But a lot of little bits add up. > The -a option isn't as much of a useful option, but it keeps life nice > and simple for those of us with only FreeBSD systems. If the -a option > is an issue, then ignore it. How does the -a option make life simpler for those of us with only FreeBSD systems? By saving two characters typing if we want to use a tool designed for copying files to archive them instead? > >>> If the functionality is all that useful, then people should have > >>> already created shell code to make this functionality easily available > >>> via the tools that already have it. If nobody needs this functionality > >>> often enough to have done that, is it something that we want to > >>> enshrine in compiled code? > >> To me, I read this as saying: "If it was useful, it would have already > >> been done, and since it isn't, it must not be needed by anyone." > > > > How does "people would have created shell code to make this easy to > > do" equate to "someone would have already added an option for it"? You > > claim that the code provides "useful functionality". If it's useful, > > then people should be using the alternatives frequently. Command lines > > that people use frequently tend to get enshrined in shell scripts, or > > aliases, or shell functions, or whatever. Moving such things into > > commands is a standard path for Unix code, and has been since at least > > v6. So, if you want to take that step, can you show that it's really > > used frequently enough to warrant getting a dedicated option? > People do make scripts to get around it, and they've posted their own > 'heres what I do' on this list in this thread. People even use tools > like rsync for it too. There's a lot of people working around it in > various ways, that's what gave me the reason to post it to the list. I haven't seen any scripts. I recall lots of people pointing out alternatives. None of these are what I would call "work arounds". They're using the available tools to do the job they were designed to do. Your patch means they can use a tool designed to copy files to create links. Which points up an obvious question: other than compatibility with Linux, is there any reason this functionaly shouldn't be added to the ln command instead? > Anyway, it's apparent that those who are against the extra features post > louder than those who could use them, so feel free to ignore the patch > altogether if you wish. That's how technical decisions get made on the internet. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 19:18:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D62516A4E9; Mon, 31 Jul 2006 19:18:48 +0000 (UTC) (envelope-from prvs=julian=360b2d18d@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9E2043D64; Mon, 31 Jul 2006 19:17:46 +0000 (GMT) (envelope-from prvs=julian=360b2d18d@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 31 Jul 2006 12:17:16 -0700 Message-ID: <44CE573B.209@elischer.org> Date: Mon, 31 Jul 2006 12:17:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Meyer References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <44CE4AD0.60409@centtech.com> <17614.20892.315747.115331@bhuda.mired.org> In-Reply-To: <17614.20892.315747.115331@bhuda.mired.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 19:18:48 -0000 Mike Meyer wrote: >I'm as neutral as I'd be about *any* other addition. I don't have a >specific reason to dislike it. But I don't have a specific reason to >like it, either. The last time I wanted a hardlinked copy of a >directory tree was long enough ago that most (if not all) of the >alternative solutions mentioned here didn't exist yet. > > > >>I suppose I thought >>the reasons were obvious - to get a hardlinked copy of a directory tree, >>one must concoct any one of a number of command lines, all using at >>least one of which is much bigger in size than the patched cp I >>proposed. Here are some of the commands mentioned so far that are used >>by people to do the exact same thing: >> >>-r-xr-xr-x 1 root wheel 50056 Jul 25 23:08 /usr/bin/bsdtar >>-r-xr-xr-x 1 root wheel 52600 Jul 25 23:07 /usr/bin/cpio >>-r-xr-xr-x 1 root wheel 36480 Jul 25 23:08 /usr/bin/find >>-r-xr-xr-x 1 root wheel 90376 Jul 25 23:06 /bin/pax >> >> > > > >>And here's my patched version of cp: >>-r-xr-xr-x 1 root wheel 15460 Jul 26 14:52 /bin/cp >> >>So yes, you bloat by 160 bytes, but you can then possibly remove your >>need for one or more utilities that eat up at least twice the space. >> >> > >So are you proposing that we remove one of those utilities? If not, >then you are bloating the system. Yeah, it's only by a little bit. But >a lot of little bits add up. > > Ok I"m going to pipe up here. The feature is cheap, it is useful and it allows people to adopt FreeBSD with less surprises. I will commit this soon unless someone else does it first. Now go do something useful :-) From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 19:53:49 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D1EA16A4FB; Mon, 31 Jul 2006 19:53:49 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DF1A43D9C; Mon, 31 Jul 2006 19:53:18 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k6VJrEU8001606; Mon, 31 Jul 2006 15:53:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44CE573B.209@elischer.org> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <44CE4AD0.60409@centtech.com> <17614.20892.315747.115331@bhuda.mired.org> <44CE573B.209@elischer.org> Date: Mon, 31 Jul 2006 15:53:14 -0400 To: Julian Elischer , Mike Meyer From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@FreeBSD.org, Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 19:53:49 -0000 At 12:17 PM -0700 7/31/06, Julian Elischer wrote: > >Ok I"m going to pipe up here. > >The feature is cheap, it is useful and it allows people >to adopt FreeBSD with less surprises. I will commit >this soon unless someone else does it first. This is not the first time we have had a long thread about the '-a' option, at least, and if we do not add it now then we will just debate this again in 8-10 months. The time wasted in the debate is much worse than the 160 bytes wasted on the disk. 160 bytes, on a disk that we allocate room in fragments of what, 4096 byte chunks? I forget now. I think Julian has the right idea. ... assuming there's no bugs in the code. I didn't actually look at the code. :-) -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 20:32:19 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1546016A4DD for ; Mon, 31 Jul 2006 20:32:19 +0000 (UTC) (envelope-from amdmi3@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BC0043D46 for ; Mon, 31 Jul 2006 20:32:18 +0000 (GMT) (envelope-from amdmi3@mail.ru) Received: from [213.148.29.33] (port=4994 helo=nexii.panopticon) by mx27.mail.ru with esmtp id 1G7eQz-000Hx1-00 for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 00:32:17 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.2]) by nexii.panopticon (Postfix) with ESMTP id 6166411413 for ; Tue, 1 Aug 2006 00:32:10 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id D1DB14212; Tue, 1 Aug 2006 00:32:13 +0400 (MSD) Date: Tue, 1 Aug 2006 00:32:13 +0400 From: Dmitry Marakasov To: freebsd-hackers@freebsd.org Message-ID: <20060731203213.GA75233@hades.panopticon> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.12-2006-07-14 Subject: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 20:32:19 -0000 Hi! Recent `disklabel differences FreeBSD, DragonFly' thread gave me a thought - why do we have absolute offsets in disklabel? AFAIK, on NetBSD and OpenBSD, label is not necessarily located `near' filesystems stored in it's partitions - and even disklabel utility shows absolute offsets (with 'c' covering entire device). FreeBSD, however, seem to step far away from that standart - 8 partitions instead of 16, label located in the beginning of a partition, bsdlabel shows relative offsets. Now I wonder if there are any reasons for offsets to be actually absolute? There are many weighty arguments for relative offsets: - No confusion (once I did try to dd slice from one place on disk to another to copy it, and was very surprised when changes made on one partition appeared on another as well) - Ability to copy and move slices with simple dd(1). - Ability to save whole disk images on slices and access subpartitions without problems (for example when moving system to larger hdd or when storing hdd images for emulation on partitions instead of filesystem, avoiding overhead). This was as an argument for geom's recursive labelling feature, but now I realize that it was not quite correct, as because of absolute offsets it can't actually be used now. So I want to hear opinions on the subject - is it worth implementing and how easy or hard will it be to implement it and migrate. I've looked through geom_label and bsdlabel code and found these quite easy to change. I'm not sure about compatibility though - is it possible to introduce some flag into label indicating that it uses relative offsets? If the idea is welcomed, I am eager to work on it, as I would like this change much. -- Best regards, Dmitry mailto:amdmi3@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 20:38:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F118E16A4DD for ; Mon, 31 Jul 2006 20:38:18 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FC6643D45 for ; Mon, 31 Jul 2006 20:38:17 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7eWj-0003YO-Hg for freebsd-hackers@freebsd.org; Mon, 31 Jul 2006 22:38:13 +0200 Received: from cmung1440.cmu.carnet.hr ([193.198.133.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 22:38:13 +0200 Received: from ivoras by cmung1440.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 22:38:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 31 Jul 2006 22:37:56 +0200 Lines: 20 Message-ID: References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1440.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <17614.10982.499561.139268@bhuda.mired.org> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 20:38:19 -0000 Mike Meyer wrote: > snake% uname -a > FreeBSD snake.mired.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP i386 > snake% ls -l /bin/cp > -r-xr-xr-x 1 root wheel 15300 May 6 23:56 /bin/cp To badly paraphase [1] a quote: "Here, have a $1, buy yourself a GB of storage..." :) Bloat is bad, but saving me time it takes to type redeems some of it. One of the reasons this binary is so small is because it's dynamically linked, so some space was saved when systems started moving away from static binaries. If nitpicking is in order, this file's size is still under default block size (16 KB) and there's plenty of stuff to fit in there to fill it. [1] butcher, more likely From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 20:45:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B539616A4DD for ; Mon, 31 Jul 2006 20:45:07 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3131343D46 for ; Mon, 31 Jul 2006 20:45:06 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1G7edK-0004rl-DL for freebsd-hackers@freebsd.org; Mon, 31 Jul 2006 22:45:02 +0200 Received: from cmung1440.cmu.carnet.hr ([193.198.133.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 22:45:02 +0200 Received: from ivoras by cmung1440.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 22:45:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 31 Jul 2006 22:42:49 +0200 Lines: 13 Message-ID: References: <44C82A40.3020009@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1440.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <44C82A40.3020009@centtech.com> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 20:45:07 -0000 Eric Anderson wrote: > -a is 'archive' mode, which is just a quick form of -PpR. > -l is 'link' mode, where regular files get hard linked instead of copied. I agree with this, and while you're in there, can you add -s to copy sparse files (via the usual "if the buffer is all nulls, seek beyond eof instead of writing" trick)? I recently had to copy big sparse files and dd with conv=sparse didn't work! I managed with rsync but I feel this functionality is the domain of 'cp' (yes, like it is in Linux - please don't start bikesheading on this detail). From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 20:50:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3493A16A4DD for ; Mon, 31 Jul 2006 20:50:45 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0C9343D46 for ; Mon, 31 Jul 2006 20:50:44 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.4) id k6VKoikt021060 for freebsd-hackers@freebsd.org; Mon, 31 Jul 2006 15:50:44 -0500 (CDT) (envelope-from dan) Date: Mon, 31 Jul 2006 15:50:44 -0500 From: Dan Nelson To: freebsd-hackers@freebsd.org Message-ID: <20060731205043.GD63872@dan.emsphone.com> References: <20060731203213.GA75233@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731203213.GA75233@hades.panopticon> X-OS: FreeBSD 5.5-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 20:50:45 -0000 In the last episode (Aug 01), Dmitry Marakasov said: > Recent `disklabel differences FreeBSD, DragonFly' thread gave me a > thought - why do we have absolute offsets in disklabel? AFAIK, on > NetBSD and OpenBSD, label is not necessarily located `near' > filesystems stored in it's partitions - and even disklabel utility > shows absolute offsets (with 'c' covering entire device). FreeBSD, > however, seem to step far away from that standart - 8 partitions > instead of 16, label located in the beginning of a partition, > bsdlabel shows relative offsets. Now I wonder if there are any > reasons for offsets to be actually absolute? There are many weighty > arguments for relative offsets: I asked this question a few years ago after having problems dd'ing a FreeBSD installation from one disk to another, and the answer was "it's always been that way" :) It shouldn't be too hard to have the code autodetect whether the offsets are relative or absolute by looking at what the 'c' partition's offset is. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 21:04:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E542516A4DA for ; Mon, 31 Jul 2006 21:04:54 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6235543D46 for ; Mon, 31 Jul 2006 21:04:54 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7evI-0000DN-Np for freebsd-hackers@freebsd.org; Mon, 31 Jul 2006 23:03:36 +0200 Received: from cmung1440.cmu.carnet.hr ([193.198.133.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 23:03:36 +0200 Received: from ivoras by cmung1440.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Jul 2006 23:03:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 31 Jul 2006 23:01:24 +0200 Lines: 15 Message-ID: References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1440.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <20060731184454.GA84483@megan.kiwi-computer.com> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 21:04:55 -0000 Rick C. Petty wrote: > "-l" may be a useful option, but at what point is the line drawn between > bloating our base cp and having a gcp port (or using linux_base)?? It's like saying "if you need this option, go to Linux" - it just seems wrong. With all respect to "series of small utilities" way of doing things, I think the "whatever is shorter to type" takes precedence :) And it's not like the added code will have to be changed/maintained in the forseeable future - if the basic implementation is ok, the underlying structures and ideas will not change while UFS semantics are in use. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 21:17:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28DC716A4E1; Mon, 31 Jul 2006 21:17:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA3E843D5C; Mon, 31 Jul 2006 21:17:39 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6VLHVZH073824; Mon, 31 Jul 2006 17:17:32 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 31 Jul 2006 16:38:14 -0400 User-Agent: KMail/1.9.1 References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44CE4AD0.60409@centtech.com> <17614.20892.315747.115331@bhuda.mired.org> In-Reply-To: <17614.20892.315747.115331@bhuda.mired.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607311638.15298.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 31 Jul 2006 17:17:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 19:34:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Mike Meyer , Doug Barton Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 21:17:42 -0000 On Monday 31 July 2006 14:53, Mike Meyer wrote: > Which points up an obvious question: other than compatibility with > Linux, is there any reason this functionaly shouldn't be added to the > ln command instead? Umm, because ln doesn't copy hierarchies? Using that argument we'd remove support for hard-links from tar and cpio. I think cp -a is harmless (just as I use rsync -a all the time rather than rsync -rlptgoD) and cp -l is probably useful. Really, it is more intuitive to be able to copy a hierarchy using the 'copy' command (cp) directly rather than a convoluted pair of find | cpio. In this case I think you might be overly paranoid. :) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 21:17:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46C4416A4E2; Mon, 31 Jul 2006 21:17:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E918343D46; Mon, 31 Jul 2006 21:17:39 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6VLHVZI073824; Mon, 31 Jul 2006 17:17:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 31 Jul 2006 16:39:24 -0400 User-Agent: KMail/1.9.1 References: <20060730105731.GA64955@stud.fit.vutbr.cz> <20060730200354.GA82547@stud.fit.vutbr.cz> <3bbf2fe10607311115ua9b7b9axd9d3e6dcff2c1daf@mail.gmail.com> In-Reply-To: <3bbf2fe10607311115ua9b7b9axd9d3e6dcff2c1daf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607311639.24810.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 31 Jul 2006 17:17:34 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1627/Sun Jul 30 19:34:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Attilio Rao , Divacky Roman Subject: Re: VM question related to faults X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 21:17:42 -0000 On Monday 31 July 2006 14:15, Attilio Rao wrote: > 2006/7/30, Divacky Roman : > > On Sun, Jul 30, 2006 at 12:57:32PM +0200, Divacky Roman wrote: > > > hi, > > > > > > while working on SoC linuxolator project I am in a need of this: > > > > > > I need to do some operation on memory like mem1 = mem1 + mem2 etc. > > > where the mem1/mem2 access can trigger fault. (memory not mapped or something) > > > > to make it clear.. I am trying to access user-space memory from kernel. > > This needs to be atomic (its an implementation of linux futexes) > > > > I need to check from kernel if some memory is accessible and then perform an > > operation on this memory. All atomically. > > > > hence I need two things - function which checks wheter the memory is accessible > > and something which makes it atomic (some mutex/something which prevents other > > process to enter VM to unmap/etc. the memory in question) > > > > hope its a bit more clear now > > You would use something like: > > #include > #include > #include > #include > #include > #include > #include > > #include > > ... > int > lock_and_fetch(const void* mem1, const void *mem2) > { > > mtx_lock(&vm_page_queue_mtx); > if (fubyte(mem1) == -1 || fubyte(mem2) == -1) { > mtx_unlock(&vm_page_queue_mtx); > return(EINVAL); > } > /* Operations... */ > mtx_unlock(&vm_page_queue_mtx); > > return(0); > } > > It prevents to virtual pages to be passed through queues. Erm, but if fubyte() had to page the file in from disk you would have to sleep while holding the vm_page_queue_mtx, and that's not allowed. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 21:31:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BDBB16A4DA for ; Mon, 31 Jul 2006 21:31:11 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id DDD9F43D45 for ; Mon, 31 Jul 2006 21:31:10 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 85887 invoked by uid 2001); 31 Jul 2006 21:31:09 -0000 Date: Mon, 31 Jul 2006 16:31:09 -0500 From: "Rick C. Petty" To: freebsd-hackers@freebsd.org Message-ID: <20060731213109.GA85795@megan.kiwi-computer.com> References: <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 21:31:11 -0000 On Mon, Jul 31, 2006 at 11:01:24PM +0200, Ivan Voras wrote: > Rick C. Petty wrote: > > >"-l" may be a useful option, but at what point is the line drawn between > >bloating our base cp and having a gcp port (or using linux_base)?? > > It's like saying "if you need this option, go to Linux" - it just seems > wrong. Not quite. I'm just saying that the "-l" option would be seldomly-used and chances are that the people who would use it are likely to also have linux_base installed. > With all respect to "series of small utilities" way of doing things, I > think the "whatever is shorter to type" takes precedence :) Ah, so then let's install a binary called "a" which is hard-linked to cp and does the equivalent of "cp -a". While we're at it, let's add a "t" command as a shortcut to "tar -f". [/sarcasm] This is what aliases are for. "cp -a" seems to me to be a silly way to say "cp -pR". Come on, it's only one letter shorter (although you could argue the time it takes to hit the shift key counts as a letter). I would think that more BSD admins are so used to typing "cp -pR" than "cp -a". In any case, it seems pointless to waste a letter when an alias is a more appropriate solution. cp(1) uses getopt(3), so there are only so many letters available. It seems more useful to add other bits of functionality and use up letters. If you really want "-a" then it should copy sparse files correctly, preserve hard links within the copied hierarchy (much like rsync's -H option), and handle extended attributes (e.g. ACLs). If not, then save "-a" for something like ACLs. Does cp(1) properly handle ACLs now anyway? > And it's not like the added code will have to be changed/maintained in > the forseeable future - if the basic implementation is ok, the > underlying structures and ideas will not change while UFS semantics are > in use. Actually I have no gripe against "-l"; I was just making a point. I think this hard-link idea is pretty useful. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 22:07:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EF8216A4DF for ; Mon, 31 Jul 2006 22:07:17 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9AB43D53 for ; Mon, 31 Jul 2006 22:07:15 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7fun-0004Lo-QS for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 00:07:09 +0200 Received: from cmung2251.cmu.carnet.hr ([193.198.136.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 00:07:09 +0200 Received: from ivoras by cmung2251.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 00:07:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 01 Aug 2006 00:07:01 +0200 Lines: 19 Message-ID: References: <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> <20060731213109.GA85795@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung2251.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <20060731213109.GA85795@megan.kiwi-computer.com> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 22:07:17 -0000 Rick C. Petty wrote: > think that more BSD admins are so used to typing "cp -pR" than "cp -a". In Ah, but therein lies one of the points - Percentage of "BSD admins" vs "other-unix-like-systems admins" is slowly but steadily diminishing. In my (I'll admit - not so expansive) experience BSD admins tend to be older people who stick with what they know will work - vast majority of younger admins I know either personally or on the 'net generally know only Linux. Using common options help bring people over, and also saves trouble with porting shell script code :) > then save "-a" for something like ACLs. Does cp(1) properly handle ACLs > now anyway? It's a good point. I don't know if it works but ACLs should probably be handled by -p. From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 23:21:39 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E97316A4DF for ; Mon, 31 Jul 2006 23:21:39 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE66C43D49 for ; Mon, 31 Jul 2006 23:21:36 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (n9yk6azndu1bzvxe@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k6VNLUn7001991; Mon, 31 Jul 2006 16:21:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k6VNLSZG001990; Mon, 31 Jul 2006 16:21:28 -0700 (PDT) (envelope-from jmg) Date: Mon, 31 Jul 2006 16:21:28 -0700 From: John-Mark Gurney To: Ivan Voras Message-ID: <20060731232128.GL96589@funkthat.com> Mail-Followup-To: Ivan Voras , freebsd-hackers@freebsd.org References: <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> <20060731213109.GA85795@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 23:21:39 -0000 Ivan Voras wrote this message on Tue, Aug 01, 2006 at 00:07 +0200: > older people who stick with what they know will work - vast majority of > younger admins I know either personally or on the 'net generally know > only Linux. > > Using common options help bring people over, and also saves trouble with > porting shell script code :) Helping people not be portable w/ other Unixes like Solaris is something we should not do... Can anyone name another major Unix besides Linux that has the -a option? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 31 23:27:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B3D016A4DE for ; Mon, 31 Jul 2006 23:27:59 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864DD43D53 for ; Mon, 31 Jul 2006 23:27:57 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7hAn-0003Rs-Ow for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 01:27:46 +0200 Received: from cmung1324.cmu.carnet.hr ([193.198.133.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 01:27:45 +0200 Received: from ivoras by cmung1324.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 01:27:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 01 Aug 2006 01:27:36 +0200 Lines: 9 Message-ID: References: <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <20060731172858.GA84042@megan.kiwi-computer.com> <44CE40EA.5080009@centtech.com> <20060731184454.GA84483@megan.kiwi-computer.com> <20060731213109.GA85795@megan.kiwi-computer.com> <20060731232128.GL96589@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1324.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <20060731232128.GL96589@funkthat.com> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 23:27:59 -0000 John-Mark Gurney wrote: > Helping people not be portable w/ other Unixes like Solaris is something > we should not do... Can anyone name another major Unix besides Linux that > has the -a option? I won't continue this line of discussion more, but it's possible Linux has more traction in these things nowadays. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 03:33:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00D4D16A4DE for ; Tue, 1 Aug 2006 03:33:06 +0000 (UTC) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A9F243D46 for ; Tue, 1 Aug 2006 03:33:05 +0000 (GMT) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.11/8.12.11) with ESMTP id k713X4I2093418 for ; Mon, 31 Jul 2006 23:33:04 -0400 (EDT) (envelope-from wayne@manor.msen.com) Message-Id: <200608010333.k713X4I2093418@manor.msen.com> To: freebsd-hackers@freebsd.org From: "Michael R. Wayne" Date: Mon, 31 Jul 2006 23:33:04 -0400 Sender: wayne@manor.msen.com Subject: fdisk very confused on 3ware system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 03:33:06 -0000 I am unable to create a new partition on a machine running 6.1-RELEASE-p3 and am beginning to suspect something is wrong in fdisk. If I run sysinstall and go to the partition editor, I get the following, which seems correct: Disk name: twed0 FDISK Partition Editor DISK Geometry: 9729 cyls/255 heads/63 sectors = 156296385 sectors (76316MB) Offset Size(ST) End Name PType Desc Subtype Flags 0 63 62 - 12 unused 0 63 31455207 31455269 twed0s1 8 freebsd 165 31455270 58717575 90172844 twed0s2 8 freebsd 165 90172845 66126595 156299439 - 12 unused 0 But, I am unable to create a new partition. Every time I do that, I get: ERROR: Unable to write data to disk twed0! This machine is not running secure: kern.securelevel: -1 So, I decided to go in with fdisk and see what was up. It looks like something is very confused on partition two, which is likely why I can not create a partition 3: > fdisk /dev/twed0 ******* Working on device /dev/twed0 ******* parameters extracted from in-core disklabel are: cylinders=9729 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=9729 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 31455207 (15358 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 31455270, size 58717575 (28670 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 <---------------- !! The data for partition 3 is: The data for partition 4 is: At this point, I'm suspecting that fdisk is computing something incorrectly and am not sure how to proceeed as I'd prefer not to corrupt my disk label. Before I consider filing a PR, is this a known problem? /\/\ \/\/ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 05:11:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70B5816BF55 for ; Tue, 1 Aug 2006 05:11:05 +0000 (UTC) (envelope-from qdolan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D13743D5A for ; Tue, 1 Aug 2006 05:11:04 +0000 (GMT) (envelope-from qdolan@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1193576uge for ; Mon, 31 Jul 2006 22:11:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:to:message-id:content-type:from:subject:date:x-mailer; b=k3MPPczc8RSFsmuQpctlqK05dvqlhr+wb3PJteNVpUir0NmgrnymQmOw0wuHsYww/N/nPDQn5sG/4ym1p6b6OZBZTcJ1A8y7KCoXEVhlvVhGGe3LRsK9ctflxSLZcEIVZONneJpXdJ56AR5pU8QU7jCJzCSEAs7TGUcABa/VnYk= Received: by 10.65.95.12 with SMTP id x12mr5178941qbl; Mon, 31 Jul 2006 22:11:02 -0700 (PDT) Received: from ?172.22.1.30? ( [203.13.70.60]) by mx.gmail.com with ESMTP id 16sm3893596nzo.2006.07.31.22.11.01; Mon, 31 Jul 2006 22:11:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: freebsd-hackers@freebsd.org Message-Id: From: Q Date: Tue, 1 Aug 2006 15:10:57 +1000 X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Req: Help tracking possible kernel memory leak. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 05:11:41 -0000 (Resent: Apologies if this is a duplicate) Hi, I was wondering if someone could help point me in the direction of how to go about trying to resolve what I assume to be a memory leak in FreeBSD 6.x. I have two database servers, one running 6.0 the other 6.1, both are running PostgreSQL. They both have 4gig of memory, running a generic kernel with the following sysctl's tweaked: kern.ipc.semmni=128 kern.ipc.semmns=512 kern.ipc.semume=100 kern.ipc.semmnu=256 kern.maxdsiz=1073741824 kern.dfldsiz=1073741824 kern.maxssiz=134217728 kern.ipc.shmmax=536870912 kern.ipc.shmall=262144 kern.ipc.shm_use_phys=1 net.inet.udp.maxdgram=63535 They are both used for processing an extremely large amount of data collected from various sources every 5 minutes and therefore perform virtually identical workloads. All processing is performed locally, there is only 1 external connection being made to the database, once a day to retrieve a small selection of data. Both machines are showing a constantly growing 'Active' memory usage in 'top' until they reach a point where the database performance drop dramatically and disk IO goes through the roof. If the machine is left to run in this state it appears to eventually just hang (at least this is what happened to one of the machines). Most recently one of the servers (running 6.1) had an "Active Memory" total of 1.6Gig, database performance was significantly worse than normal, and disk io was dramatically higher. Queries that previously took a few seconds were taking several minutes. Using vmstat, ps and top, along with restarting the database I was unable to find anything that would indicate a user space leak consuming this 1.6Gig of memory. The only way I found to free this memory and ultimately restore the database performance was to reboot the machine. Which resulted in the "Active memory" resetting back to virtually nothing and proceeded to slowly climb again (after 4 days one server is up to about 380Mb, and the other server is at about 680Mb after 7 days) and growing at an almost linear rate. If someone would be so kind as to provide some advice on how to track down this issue it would be much appreciated. Having to reboot these machines every 15 days is simply not a viable option. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _____ / Quinton Dolan - qdolan@gmail.com __ __/ / / __/ / / / __ / _/ / / Gold Coast, QLD, Australia __/ __/ __/ ____/ / - / Ph: +61 419 729 806 _______ / _\ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 07:26:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA51116A4DF for ; Tue, 1 Aug 2006 07:26:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B692243D45 for ; Tue, 1 Aug 2006 07:26:26 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail03.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k717QBCM028739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Aug 2006 17:26:13 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k717QBYG000904; Tue, 1 Aug 2006 17:26:11 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k717QB3U000903; Tue, 1 Aug 2006 17:26:11 +1000 (EST) (envelope-from peter) Date: Tue, 1 Aug 2006 17:26:11 +1000 From: Peter Jeremy To: Ivan Voras Message-ID: <20060801072611.GA717@turion.vk2pj.dyndns.org> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 07:26:29 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: >I agree with this, and while you're in there, can you add -s to copy=20 >sparse files (via the usual "if the buffer is all nulls, seek beyond eof= =20 >instead of writing" trick)? Note that it isn's possible to accurately distinguish between a block of NULs and a hole in the file through the filesystem. The only way to accurately copy a sparse file is with dump/restore. On Mon, 2006-Jul-31 22:37:56 +0200, Ivan Voras wrote: >To badly paraphase [1] a quote: "Here, have a $1, buy yourself a GB of=20 >storage..." :) This is true in the desktop and server market but is not true in the embedded market and only marginally true for laptops. --=20 Peter Jeremy --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEzwIT/opHv/APuIcRAmEmAJ90WuXGd8QbxLyldLSGqP3gJEx1GACaArTO YcvQyPnpUXOGRnao40mvi6M= =fWaH -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 08:56:19 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D74B516A4DD for ; Tue, 1 Aug 2006 08:56:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93C6643D49 for ; Tue, 1 Aug 2006 08:56:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B44AC46D0C; Tue, 1 Aug 2006 04:56:19 -0400 (EDT) Date: Tue, 1 Aug 2006 09:56:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joseph Koshy In-Reply-To: <84dead720607311012q42e5dapf83e73653e245ae0@mail.gmail.com> Message-ID: <20060801095559.E32926@fledge.watson.org> References: <20060731154612.GA2921@taran.infoua.com.ua> <84dead720607311012q42e5dapf83e73653e245ae0@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: nick@humgat.org, hackers@freebsd.org Subject: Re: _getlogin() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 08:56:19 -0000 On Mon, 31 Jul 2006, Joseph Koshy wrote: >> Where can i find source of subj? >> /usr/src/lib/libc/gen/getlogin.c has >> the declaration of this function, but i'm unable >> to find its definition. > > Its generated as part of the C library build. See: > src/lib/libc/i386/sys/Makefile.inc > src/lib/libc/sys/Makefile.inc > sys/lib/libc/i386/SYS.h And: src/sys/kern/kern_prot.c :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 10:08:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 525BA16A4DE for ; Tue, 1 Aug 2006 10:08:02 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C609B43D46 for ; Tue, 1 Aug 2006 10:08:00 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G7rAH-0007iJ-IR for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 12:07:53 +0200 Received: from cmung1407.cmu.carnet.hr ([193.198.133.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 12:07:53 +0200 Received: from ivoras by cmung1407.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 12:07:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 01 Aug 2006 12:07:45 +0200 Lines: 15 Message-ID: References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1407.cmu.carnet.hr User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <20060801072611.GA717@turion.vk2pj.dyndns.org> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 10:08:02 -0000 Peter Jeremy wrote: > Note that it isn's possible to accurately distinguish between a block > of NULs and a hole in the file through the filesystem. The only way > to accurately copy a sparse file is with dump/restore. Hence the need for an explicit switch. > This is true in the desktop and server market but is not true in the > embedded market and only marginally true for laptops. I don't know about embedded markets (do they need cp, or it's simply kernel+dedicated application?) but I've recently bought a 60GB laptop drive for ~~ $120 (converted back from my currency, may be cheaper in other parts of the world) - that's $2/GB. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 12:16:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3DC116A521 for ; Tue, 1 Aug 2006 12:16:57 +0000 (UTC) (envelope-from amdmi3@mail.ru) Received: from mx27.mail.ru (mx27.mail.ru [194.67.23.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F8843D79 for ; Tue, 1 Aug 2006 12:15:04 +0000 (GMT) (envelope-from amdmi3@mail.ru) Received: from [213.148.29.33] (port=62808 helo=nexii.panopticon) by mx27.mail.ru with esmtp id 1G7t9L-00059u-00; Tue, 01 Aug 2006 16:15:03 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.2]) by nexii.panopticon (Postfix) with ESMTP id AA73A1705C; Tue, 1 Aug 2006 16:15:03 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 43C7F417F; Tue, 1 Aug 2006 16:14:59 +0400 (MSD) Date: Tue, 1 Aug 2006 16:14:59 +0400 From: Dmitry Marakasov To: Dan Nelson Message-ID: <20060801121459.GA81372@hades.panopticon> Mail-Followup-To: Dan Nelson , freebsd-hackers@freebsd.org References: <20060731203213.GA75233@hades.panopticon> <20060731205043.GD63872@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060731205043.GD63872@dan.emsphone.com> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-hackers@freebsd.org Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:16:58 -0000 * Dan Nelson (dnelson@allantgroup.com) wrote: > > Recent `disklabel differences FreeBSD, DragonFly' thread gave me a > > thought - why do we have absolute offsets in disklabel? AFAIK, on > > NetBSD and OpenBSD, label is not necessarily located `near' > > filesystems stored in it's partitions - and even disklabel utility > > shows absolute offsets (with 'c' covering entire device). FreeBSD, > > however, seem to step far away from that standart - 8 partitions > > instead of 16, label located in the beginning of a partition, > > bsdlabel shows relative offsets. Now I wonder if there are any > > reasons for offsets to be actually absolute? There are many weighty > > arguments for relative offsets: > I asked this question a few years ago after having problems dd'ing a > FreeBSD installation from one disk to another, and the answer was "it's > always been that way" :) It shouldn't be too hard to have the code > autodetect whether the offsets are relative or absolute by looking at > what the 'c' partition's offset is. The only problem seem to be that older FreeBSD versions won't be able to use modified labels. -- Best regards, Dmitry mailto:amdmi3@mail.ru From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 12:44:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1457116A4DA for ; Tue, 1 Aug 2006 12:44:04 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C9743D77 for ; Tue, 1 Aug 2006 12:43:59 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k71Chw6V005832 for ; Tue, 1 Aug 2006 07:43:59 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CF4C9F.3040101@centtech.com> Date: Tue, 01 Aug 2006 07:44:15 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: FreeBSD Hackers References: <44C82A40.3020009@centtech.com> In-Reply-To: <44C82A40.3020009@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1629/Tue Aug 1 06:19:34 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: [PATCH] adding two new options to 'cp' (UPDATE) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 12:44:04 -0000 On 07/26/06 21:51, Eric Anderson wrote: > I'm tired of trying to use rsync or gcp (which doesn't like symlinks > often) to copy trees of files/directories using hard links, so I added > the gcp-ish options -a and -l. > > -a is 'archive' mode, which is just a quick form of -PpR. > -l is 'link' mode, where regular files get hard linked instead of copied. > > So, you can mimic an entire tree with something like: > > cp -al /from/ /to/ > > and it's fast too! > > Patch is against 6-STABLE, but works well on 7-CURRENT as well. > > Patch is here (with man page edits): > http://www.googlebit.com/freebsd/patches/cp-patch > > cd /tmp/ > fetch http://www.googlebit.com/freebsd/patches/cp-patch > cd /usr/src/ > patch < /tmp/cp-patch > cd bin/cp > make && make install I've made an updated patch available. It fixes the missing information in the usage output, a file descriptor leak, and also now warns when an attempt to copy a socket occurs instead of erroring. This isn't really particular to any of the new arguments, but is more consistent with other tools, and consistent with cp's other options that just warn. The new patch can be found here: http://www.googlebit.com/freebsd/patches/cp-patch-2 Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 13:36:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F94F16A4E1 for ; Tue, 1 Aug 2006 13:36:53 +0000 (UTC) (envelope-from davidt@yadt.co.uk) Received: from outcold.yadt.co.uk (outcold.yadt.co.uk [81.187.204.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1427D43D7D for ; Tue, 1 Aug 2006 13:36:40 +0000 (GMT) (envelope-from davidt@yadt.co.uk) Received: from localhost (localhost [127.0.0.1]) by outcold.yadt.co.uk (Postfix) with ESMTP id 4674D1DD4CC for ; Tue, 1 Aug 2006 14:36:39 +0100 (BST) X-Virus-Scanned: amavisd-new 2.4.0 (20060403) at yadt.co.uk Received: from outcold.yadt.co.uk ([127.0.0.1]) by localhost (outcold.yadt.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCJDvib+0KdN for ; Tue, 1 Aug 2006 14:36:38 +0100 (BST) Received: by outcold.yadt.co.uk (Postfix, from userid 1001) id 9CE231DD4E3; Tue, 1 Aug 2006 14:36:38 +0100 (BST) Date: Tue, 1 Aug 2006 14:36:38 +0100 From: David Taylor To: freebsd-hackers@freebsd.org Message-ID: <20060801133638.GA83496@outcold.yadt.co.uk> Mail-Followup-To: freebsd-hackers@freebsd.org References: <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 13:36:53 -0000 On Tue, 01 Aug 2006, Ivan Voras wrote: > Peter Jeremy wrote: >=20 > >Note that it isn's possible to accurately distinguish between a block > >of NULs and a hole in the file through the filesystem. The only way > >to accurately copy a sparse file is with dump/restore. >=20 > Hence the need for an explicit switch. A switch doesn't help. A sparse file can contain both holes and blocks of NULs. You could, I suppose, do something like -s 100, which would seek past any block of >100 NULs. --=20 David Taylor From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 15:59:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 348E216A4DA for ; Tue, 1 Aug 2006 15:59:11 +0000 (UTC) (envelope-from freebsd4@fadesa.es) Received: from fuego.fadesa.es (fuego.fadesa.es [195.55.55.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5833843D77 for ; Tue, 1 Aug 2006 15:59:09 +0000 (GMT) (envelope-from freebsd4@fadesa.es) Received: (from root@localhost) by fuego.fadesa.es (8.9.3p2/8.8.8) id RAA24139 for ; Tue, 1 Aug 2006 17:54:23 +0200 Received: from tierra.fadesa.es(195.55.55.7) by fuego.fadesa.es Tue, 1 Aug 06 17:54:12 +0200 Received: from [195.55.55.6] (filemon.fadesa.es [195.55.55.6] (may be forged)) by tierra.fadesa.es (8.9.3p2/8.8.8) with ESMTP id RAA08700 for ; Tue, 1 Aug 2006 17:58:33 +0200 Message-ID: <44CF7A28.6020704@fadesa.es> Date: Tue, 01 Aug 2006 17:58:32 +0200 From: =?UTF-8?B?Ikpvc8OpIE0uIEZhbmRpw7FvIg==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: gl, es, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Logged: Logged by tierra.fadesa.es as RAA08700 at Tue Aug 1 17:58:33 2006 Subject: ural(4) and panic on sleeping thread (6.1-R) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 15:59:11 -0000 Hello, I get a panic each time I try to create an access point with the ural driver. only by running this commands the machine panic: kldload bridge sysctl net.link.ether.bridge.enable=3D1 net.link.ether.bridge_cfg=3D"rl0,ural0" I'm not very familiarized with 'kgdb' so if some developper gets interested in this panic I can execute all commands they are interested in. thank you. # kgdb -c /var/crash/vmcore.3 /usr/obj/usr/src/sys/GENERIC/kernel.debug [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditi= ons. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <6>rl0: promiscuous mode enabled Sleeping thread (tid 100079, pid 783) owns a non-sleepable lock panic: sleeping thread Uptime: 1m22s Dumping 254 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 254MB (65008 pages) 238 222 206 190 174 158 142 126 110 94 78= 62 46 30 14 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc064dee1 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :402 first_buf_printf =3D 1 #2 0xc064e178 in panic (fmt=3D0xc08a8dda "sleeping thread") at /usr/src/= sys/kern/kern_shutdown.c:558 td =3D (struct thread *) 0xc2535300 bootopt =3D 260 newpanic =3D 0 ap =3D 0xc2535300 "\fS=EF=BF=BD buf =3D "sleeping thread", '\0' #3 0xc066da08 in propagate_priority (td=3D0xc283e900) at /usr/src/sys/ke= rn/subr_turnstile.c:196 tc =3D (struct turnstile_chain *) 0xc2535300 ts =3D (struct turnstile *) 0xc252d440 pri =3D 4 #4 0xc066e1ea in turnstile_wait (lock=3D0xc2d15620, owner=3D0xc283e900) = at /usr/src/sys/kern/subr_turnstile.c:634 tc =3D (struct turnstile_chain *) 0xc09801f0 ts =3D (struct turnstile *) 0xc252d440 td =3D (struct thread *) 0xc2535300 td1 =3D (struct thread *) 0xc2535300 #5 0xc06456c8 in _mtx_lock_sleep (m=3D0xc2d15620, tid=3D3260240640, opts= =3D0, file=3D0xc2d1490a "/usr/src/sys/modules/bridge/../../net/bridge.c",= line=3D778) at /usr/src/sys/kern/kern_mutex.c:565 v =3D 0 #6 0xc064552c in _mtx_lock_flags (m=3D0x0, opts=3D0, file=3D0xc2d1490a "= /usr/src/sys/modules/bridge/../../net/bridge.c", line=3D778) at /usr/src/sys/kern/kern_mutex.c:286 No locals. #7 0xc2d140dc in ?? () No symbol table info available. #8 0xc2d15620 in ?? () No symbol table info available. #9 0x00000000 in ?? () No symbol table info available. #10 0xc2d1490a in ?? () No symbol table info available. #11 0x0000030a in ?? () No symbol table info available. #12 0xc06b5e63 in bpf_mtap (bp=3D0xc2802a42, m=3D0xc2802a00) at /usr/src/= sys/net/bpf.c:1321 d =3D (struct bpf_d *) 0xc2670400 pktlen =3D 3261531136 slen =3D 0 #13 0xc06bc1f2 in ether_input (ifp=3D0xc2670400, m=3D0xc2802a00) at /usr/= src/sys/net/if_ethersubr.c:614 eh =3D (struct ether_header *) 0x0 etype =3D 2048 #14 0xc076043b in rl_rxeof (sc=3D0xc265a800) at /usr/src/sys/pci/if_rl.c:= 1201 m =3D (struct mbuf *) 0xc2802a00 ifp =3D (struct ifnet *) 0xc2670400 rxbufpos =3D (uint8_t *) 0x0 total_len =3D 4 wrap =3D 65532 rxstat =3D 0 cur_rx =3D 100 limit =3D 0 max_bytes =3D 100 rx_bytes =3D 100 #15 0xc07606cb in rl_intr (arg=3D0xc265a800) at /usr/src/sys/pci/if_rl.c:= 1356 sc =3D (struct rl_softc *) 0xc265a800 ifp =3D (struct ifnet *) 0xc2670400 status =3D 1 #16 0xc06395b5 in ithread_execute_handlers (p=3D0xc253b20c, ie=3D0xc25328= 80) at /usr/src/sys/kern/kern_intr.c:684 ih =3D (struct intr_handler *) 0xc25f6400 ihn =3D (struct intr_handler *) 0xc267ab80 #17 0xc06396cc in ithread_loop (arg=3D0xc2610ca0) at /usr/src/sys/kern/ke= rn_intr.c:767 intr_event =3D (struct intr_thread *) 0xc2610ca0 ie =3D (struct intr_event *) 0xc2532880 td =3D (struct thread *) 0xc2535300 p =3D (struct proc *) 0xc253b20c ---Type to continue, or q to quit--- #18 0xc0638524 in fork_exit (callout=3D0xc0639678 , arg=3D0= xc2610ca0, frame=3D0xcc113d38) at /usr/src/sys/kern/kern_fork.c:805 p =3D (struct proc *) 0xc253b20c td =3D (struct thread *) 0x0 #19 0xc0830cfc in fork_trampoline () at /usr/src/sys/i386/i386/exception.= s:208 No locals. (kgdb) Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved= =2E FreeBSD 6.1-RELEASE #0: Fri Jul 28 11:46:46 CEST 2006 root@info34.local:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Celeron(R) CPU 2.00GHz (1992.63-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf29 Stepping =3D 9 Features=3D0xbfebf9ff Features2=3D0x4400> real memory =3D 267321344 (254 MB) avail memory =3D 247910400 (236 MB) kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x62,0x66 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: BIOS IRQ 11 for 0.10.INTA is invalid pci0: on pcib0 agp0: mem 0xf0000000-0xf7ffffff at device = 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xe1000000-0xe1ffffff,0xe8000000-0xefffffff ir= q 10 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] pcm0: port 0x1800-0x18ff mem 0xe0000000-0xe0000fff irq = 11 at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) rl0: port 0x2000-0x20ff mem 0xe0002000-0xe000= 20ff irq 10 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:00:e2:90:d9:d0 fwohci0: port 0x2400-0x247f mem 0xe0002800-0xe0002= fff irq 11 at device 11.0 on pci0 fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:11:06:00:00:0a:56:5d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:06:0a:56:5d fwe0: Ethernet address: 02:11:06:0a:56:5d fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) ohci0: mem 0xe0003000-0xe0003= fff irq 10 at device 15.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170= -0x177,0x376,0x2480-0x248f at device 16.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA acce= ss bug, expect reduced performance ata0: on atapci0 ata1: on atapci0 pci0: at device 17.0 (no driver attached) cbb0: mem 0xe0004000-0xe0004fff = irq 11 at device 19.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ohci1: mem 0xe0005000-0xe0005= fff irq 11 at device 20.0 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 = on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on a= cpi0 sio0: type 16550A sio1: port 0x2f8-0x2ff irq 3 drq 3 on ac= pi0 sio1: type 16550A pmtimer0 on isa0 orm0: at iomem 0xd8000-0xdbfff,0xdc000-0xdffff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0= ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/20.00, addr 2, iclass 3/1= ums0: 3 buttons and Z dir. ural0: ANI 802.11g W, rev 2.00/0.01, addr 3 ural0: MAC/BBP RT2570 (rev 0x03), RF RT2526 ural0: Ethernet address: 00:80:5a:33:91:55 ural0: if_start running deferred for Giant Timecounter "TSC" frequency 1992630836 Hz quality 800 Timecounters tick every 1.000 msec rl1: port 0x1000-0x10ff mem 0x88000000-0x8800= 01ff irq 11 at device 0.0 on cardbus0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:10:60:59:1d:47 ad0: DMA limited to UDMA33, controller found non-ATA66 cable ad0: 28615MB at ata0-master UDMA33 acd0: CDROM at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s3a From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:07:04 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEAD816A4E5 for ; Tue, 1 Aug 2006 17:07:04 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9833143D53 for ; Tue, 1 Aug 2006 17:07:03 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k71H6uF9010407; Tue, 1 Aug 2006 13:06:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> Date: Tue, 1 Aug 2006 13:06:55 -0400 To: Ivan Voras , freebsd-hackers@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:07:05 -0000 At 12:07 PM +0200 8/1/06, Ivan Voras wrote: >Peter Jeremy wrote: > >>Note that it isn's possible to accurately distinguish >>between a block of NULs and a hole in the file through >>the filesystem. The only way to accurately copy a >>sparse file is with dump/restore. > >Hence the need for an explicit switch. The point is not that you need an explicit switch, the point is that you have to add a lot of code to 'cp' for 'cp' to do the job correctly. You are changing the nature of how the command works. I very much doubt you can implement that *correctly* in a mere 160 bytes of additional object code! Note: -r-xr-xr-x 1 root wheel 15348 [date] /bin/cp -r-xr-xr-x 2 root wheel 44288 [date] /sbin/dump -r-xr-xr-x 2 root wheel 58736 [date] /sbin/restore I realize a lot of these decisions are somewhat subjective. "One person's feature is another person's bloat". But in the case of this specific example, I (personally) would not want 'cp' to implement every detail which is already handled by dump/restore. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:11:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7483C16A4E0 for ; Tue, 1 Aug 2006 17:11:52 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D55E43D49 for ; Tue, 1 Aug 2006 17:11:51 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 3958 invoked by uid 2001); 1 Aug 2006 17:11:50 -0000 Date: Tue, 1 Aug 2006 12:11:50 -0500 From: "Rick C. Petty" To: Peter Jeremy Message-ID: <20060801171150.GB3413@megan.kiwi-computer.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801072611.GA717@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:11:52 -0000 On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote: > On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: > >I agree with this, and while you're in there, can you add -s to copy > >sparse files (via the usual "if the buffer is all nulls, seek beyond eof > >instead of writing" trick)? > > Note that it isn's possible to accurately distinguish between a block > of NULs and a hole in the file through the filesystem. The only way > to accurately copy a sparse file is with dump/restore. Sure it is-- in a number of ways. The most useful way is to do something of the sort: int sd, dd; // assume these are set to source & dest descriptors unsigned char* zeros; unsigned char* buffer; struct stat st; size_t bytes, offset; fstat(sd, &st); zeros = malloc(st.st_blksize); bzero(zeros, st.st_blksize); for (offset = 0; offset < st.st_size; offset += bytes) { bytes = st.st_blksize; if (offset + bytes > st.st_size) bytes = st.st_size - offset; read(sd, buffer, bytes); if (0 == memcmp(buffer, zeros, bytes)) lseek(dd, bytes, SEEK_CUR); else write(sd, buffer, bytes); } Obviously, I didn't add the error checking/handling, but AFAIK this is essentially what the -S option to gnu's tar does. In this example, you may not mimic the allocated blocks of a sparse file, but you would optimize the copy to use as few filesystem blocks as possible. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:19:14 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31CAE16A4F1 for ; Tue, 1 Aug 2006 17:19:14 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 45E1743D98 for ; Tue, 1 Aug 2006 17:19:13 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 4000 invoked by uid 2001); 1 Aug 2006 17:19:12 -0000 Date: Tue, 1 Aug 2006 12:19:12 -0500 From: "Rick C. Petty" To: Garance A Drosehn Message-ID: <20060801171912.GC3413@megan.kiwi-computer.com> References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:19:14 -0000 On Tue, Aug 01, 2006 at 01:06:55PM -0400, Garance A Drosehn wrote: > > The point is not that you need an explicit switch, the > point is that you have to add a lot of code to 'cp' for > 'cp' to do the job correctly. Not really. See my example in a previous post. All you need to do is perform an lseek(2) instead of a write(2) if the block you read is all zero. > You are changing the nature of how the command works. No, you're adding features, not changing the behavior for the default case. > I very much doubt you > can implement that *correctly* in a mere 160 bytes of > additional object code! I'd be willing to bet that my aforementioned example would fit in that space-- because you already do an fstat & the read/write code-- the only thing to add is the zero-checking and seek ahead code. > -r-xr-xr-x 1 root wheel 15348 [date] /bin/cp > -r-xr-xr-x 2 root wheel 44288 [date] /sbin/dump > -r-xr-xr-x 2 root wheel 58736 [date] /sbin/restore dump/restore is significantly different in operation than cp. Both do a lot more than just copy files. Also dump/restore is specific to UFS and my example code would handle sparse files for any filesystem. > I realize a lot of these decisions are somewhat subjective. > "One person's feature is another person's bloat". But in > the case of this specific example, I (personally) would > not want 'cp' to implement every detail which is already > handled by dump/restore. I don't think this is what people are asking for. BTW, does dump/restore handle extended attributes? Last I checked, it didn't. But then again I don't think cp or tar do either. Feel free to enlighten me. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:27:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2820016A4DF for ; Tue, 1 Aug 2006 17:27:45 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F01E043D6B for ; Tue, 1 Aug 2006 17:27:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k71HRbpa036354; Tue, 1 Aug 2006 12:27:37 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CF8F1A.5090506@centtech.com> Date: Tue, 01 Aug 2006 12:27:54 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> In-Reply-To: <20060801171150.GB3413@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1630/Tue Aug 1 10:38:56 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:27:45 -0000 On 08/01/06 12:11, Rick C. Petty wrote: > On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote: >> On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: >>> I agree with this, and while you're in there, can you add -s to copy >>> sparse files (via the usual "if the buffer is all nulls, seek beyond eof >>> instead of writing" trick)? >> Note that it isn's possible to accurately distinguish between a block >> of NULs and a hole in the file through the filesystem. The only way >> to accurately copy a sparse file is with dump/restore. > > Sure it is-- in a number of ways. The most useful way is to do something > of the sort: > > int sd, dd; // assume these are set to source & dest descriptors > unsigned char* zeros; > unsigned char* buffer; > struct stat st; > size_t bytes, offset; > > fstat(sd, &st); > zeros = malloc(st.st_blksize); > bzero(zeros, st.st_blksize); > > for (offset = 0; offset < st.st_size; offset += bytes) > { > bytes = st.st_blksize; > if (offset + bytes > st.st_size) > bytes = st.st_size - offset; > read(sd, buffer, bytes); > if (0 == memcmp(buffer, zeros, bytes)) > lseek(dd, bytes, SEEK_CUR); > else > write(sd, buffer, bytes); > } > > Obviously, I didn't add the error checking/handling, but AFAIK this is > essentially what the -S option to gnu's tar does. In this example, you > may not mimic the allocated blocks of a sparse file, but you would > optimize the copy to use as few filesystem blocks as possible. Wouldn't this be incorrect for files that are really full of zeros? It would turn them in to sparse files when they shouldn't be, correct? Is that what happens with other tools? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:40:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8078F16A583 for ; Tue, 1 Aug 2006 17:40:50 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 9361843D49 for ; Tue, 1 Aug 2006 17:40:49 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 4178 invoked by uid 2001); 1 Aug 2006 17:40:48 -0000 Date: Tue, 1 Aug 2006 12:40:48 -0500 From: "Rick C. Petty" To: Eric Anderson Message-ID: <20060801174048.GE3413@megan.kiwi-computer.com> References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CF8F1A.5090506@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:40:50 -0000 On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote: > > Wouldn't this be incorrect for files that are really full of zeros? It > would turn them in to sparse files when they shouldn't be, correct? Is > that what happens with other tools? Why is this bad? I'm not suggesting that the default implementation should change but that this "-s" option be added to properly optimize for sparse files. A sparse file is one which contains blocks of pure zeros. My example wouldn't vary in how the destination file is read but in how many blocks are allocated in the underlying file system. One of my biggest gripes with cp(1) was how a recursive tree copy was always larger than the source, if the source contained any sparse files. This is similar to your desire to add "-l" for doing hard links. Both have their usefulness. And your "-a" option could be a replacement for "-pRs" if so desired (or "-S", it's all the same to me). While we're at it, I think we should add the -S option to bsdtar. I'm willing to do the work and make patches (to cp & tar), if someone is willing to review and commit them. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:51:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9262216A4E7 for ; Tue, 1 Aug 2006 17:51:20 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8151543D68 for ; Tue, 1 Aug 2006 17:51:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k71HpG1N040244; Tue, 1 Aug 2006 12:51:16 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CF94A4.3000306@centtech.com> Date: Tue, 01 Aug 2006 12:51:32 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> In-Reply-To: <20060801174048.GE3413@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1630/Tue Aug 1 10:38:56 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:51:20 -0000 On 08/01/06 12:40, Rick C. Petty wrote: > On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote: >> Wouldn't this be incorrect for files that are really full of zeros? It >> would turn them in to sparse files when they shouldn't be, correct? Is >> that what happens with other tools? > > Why is this bad? I'm not suggesting that the default implementation > should change but that this "-s" option be added to properly optimize > for sparse files. A sparse file is one which contains blocks of pure > zeros. My example wouldn't vary in how the destination file is read > but in how many blocks are allocated in the underlying file system. It could possibly be bad if you have a real file (say a 10GB file, partially filled with zeros - a disk image created with dd for instance), and you use cp with something like -spR to recursively copy all files. Your destination disk image would then be a sparse file, so additional changes and modifications to the file (block allocations) would fragment the image and make it slower. That would be unexpected and probably go unnoticed for some time. I do see the usefulness in this, but I think one needs to be careful to either clearly note in the man page that it will make sparse files from *any* file containing a string of zeros larger than the block size, or it needs to 'do the right thing' and determine if it's sparse or not. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:20:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B767416A50A for ; Tue, 1 Aug 2006 18:20:46 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 24F3F43D5A for ; Tue, 1 Aug 2006 18:20:40 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 4341 invoked by uid 2001); 1 Aug 2006 18:00:40 -0000 Date: Tue, 1 Aug 2006 13:00:40 -0500 From: "Rick C. Petty" To: Eric Anderson Message-ID: <20060801180040.GA4272@megan.kiwi-computer.com> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CF94A4.3000306@centtech.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:20:46 -0000 On Tue, Aug 01, 2006 at 12:51:32PM -0500, Eric Anderson wrote: > On 08/01/06 12:40, Rick C. Petty wrote: > > It could possibly be bad if you have a real file (say a 10GB file, > partially filled with zeros - a disk image created with dd for > instance), and you use cp with something like -spR to recursively copy > all files. Your destination disk image would then be a sparse file, so > additional changes and modifications to the file (block allocations) > would fragment the image and make it slower. That would be unexpected > and probably go unnoticed for some time. I do see the usefulness in > this, but I think one needs to be careful to either clearly note in the > man page that it will make sparse files from *any* file containing a > string of zeros larger than the block size, I completely agree. This is why it would not be the default behavior. Also, gnutar provides this option and it just describes it as "handle sparse files efficiently"-- so a rewording of that to say that by "efficient" we mean that the program will allocate as few blocks as possible in the underlying filesystem. I think a clear description in the man page would suffice. > or it needs to 'do the right > thing' and determine if it's sparse or not. Unfortunately that would require knowledge which the POSIX calls have no knowledge of. I don't believe we should roll filesystem-specific knowledge into cp. However, there is utility in performing a "space-saving" copy, just as a hardlink is quite space-saving. =) "-s" or "-S" could refer to sparse, space, squeeze, shrink, or whatever. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:26:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8B2016A4DA for ; Tue, 1 Aug 2006 18:26:42 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 2022143D98 for ; Tue, 1 Aug 2006 18:26:30 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 96093 invoked by uid 1001); 1 Aug 2006 18:26:29 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Tue, 01 Aug 2006 14:26:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17615.40148.872008.53973@bhuda.mired.org> Date: Tue, 1 Aug 2006 14:26:28 -0400 To: rick-freebsd@kiwi-computer.com In-Reply-To: <20060801171150.GB3413@megan.kiwi-computer.com> References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:26:42 -0000 In <20060801171150.GB3413@megan.kiwi-computer.com>, Rick C. Petty typed: > On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote: > > On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: > > >I agree with this, and while you're in there, can you add -s to copy > > >sparse files (via the usual "if the buffer is all nulls, seek beyond eof > > >instead of writing" trick)? > > > > Note that it isn's possible to accurately distinguish between a block > > of NULs and a hole in the file through the filesystem. The only way > > to accurately copy a sparse file is with dump/restore. > > Sure it is-- in a number of ways. The most useful way is to do something > of the sort: [code elided] > Obviously, I didn't add the error checking/handling, but AFAIK this is > essentially what the -S option to gnu's tar does. Yes, but gnu tar doesn't do this accurately, so you're not doing what Peter said you couldn't do. You are doing what Ivan asked, though. I always think of cp as a tool for making *copies of files*, not for creating an archive of a directory tree. We've got lots of tools that do the latter. Do we really need another one? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:34:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E5DF16A4DF for ; Tue, 1 Aug 2006 18:34:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB7743D69 for ; Tue, 1 Aug 2006 18:34:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k71IYMKB081390; Tue, 1 Aug 2006 14:34:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 1 Aug 2006 14:29:42 -0400 User-Agent: KMail/1.9.1 References: <44CF7A28.6020704@fadesa.es> In-Reply-To: <44CF7A28.6020704@fadesa.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200608011429.42407.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 01 Aug 2006 14:34:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1630/Tue Aug 1 11:38:56 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: =?utf-8?q?Jos=C3=A9_M=2E?= =?utf-8?q?_Fandi=C3=B1o?= Subject: Re: ural(4) and panic on sleeping thread (6.1-R) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:34:54 -0000 On Tuesday 01 August 2006 11:58, Jos=C3=A9 M. Fandi=C3=B1o wrote: > Hello, >=20 > I get a panic each time I try to create an access point > with the ural driver. >=20 > only by running this commands the machine panic: > kldload bridge > sysctl net.link.ether.bridge.enable=3D1 > net.link.ether.bridge_cfg=3D"rl0,ural0" >=20 > I'm not very familiarized with 'kgdb' so if some developper > gets interested in this panic I can execute all commands > they are interested in. >=20 > thank you. >=20 > # kgdb -c /var/crash/vmcore.3 /usr/obj/usr/src/sys/GENERIC/kernel.debug > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o:=20 Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain=20 conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd". >=20 > Unread portion of the kernel message buffer: > <6>rl0: promiscuous mode enabled > Sleeping thread (tid 100079, pid 783) owns a non-sleepable lock > panic: sleeping thread In kgdb, do 'proc 783', and then 'where' to get a stack trace of the thread= =20 that did the wrong thing. (The thread that panics is just an innocent=20 victim that bumped into the miscreant.) =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:43:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C59C16A4DF for ; Tue, 1 Aug 2006 18:43:56 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 6466D43D53 for ; Tue, 1 Aug 2006 18:43:09 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 4662 invoked by uid 2001); 1 Aug 2006 18:42:52 -0000 Date: Tue, 1 Aug 2006 13:42:52 -0500 From: "Rick C. Petty" To: Mike Meyer Message-ID: <20060801184252.GB4272@megan.kiwi-computer.com> References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <17615.40148.872008.53973@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17615.40148.872008.53973@bhuda.mired.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:43:56 -0000 On Tue, Aug 01, 2006 at 02:26:28PM -0400, Mike Meyer wrote: > In <20060801171150.GB3413@megan.kiwi-computer.com>, Rick C. Petty typed: > > > Obviously, I didn't add the error checking/handling, but AFAIK this is > > essentially what the -S option to gnu's tar does. > > Yes, but gnu tar doesn't do this accurately, That may be. I haven't looked at their code, I just assumed how they did it. > so you're not doing what > Peter said you couldn't do. You are doing what Ivan asked, though. That depends upon what you mean by "accurately" and what you mean by "sparse". :-P Yes, if you're looking for a block-wise "dump" of a file system's file, you use dump. If you're looking to make a "copy" of a file, optimizing for sparseness, you use rsync. A pretty heavyweight solution when you're trying to copy one file. > I always think of cp as a tool for making *copies of files*, not for > creating an archive of a directory tree. We've got lots of tools that > do the latter. Do we really need another one? I wasn't thinking of the "sparse handling" utility for whole trees, but it would be useful for that also. I'm just looking for a lightweight tool for copying files containing sparse chunks.. Since we switched to bsdtar, the base system has been lacking this feature. To me, this seems more useful (as a base feature) than hard-linking trees. But both have utility. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:54:39 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F4316A4E0 for ; Tue, 1 Aug 2006 18:54:39 +0000 (UTC) (envelope-from prvs=julian=361365f97@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 260A643D6A for ; Tue, 1 Aug 2006 18:54:38 +0000 (GMT) (envelope-from prvs=julian=361365f97@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 01 Aug 2006 11:54:38 -0700 Message-ID: <44CFA36D.4040709@elischer.org> Date: Tue, 01 Aug 2006 11:54:37 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> In-Reply-To: <44CF94A4.3000306@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rick-freebsd@kiwi-computer.com Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:54:39 -0000 Eric Anderson wrote: > On 08/01/06 12:40, Rick C. Petty wrote: > >> On Tue, Aug 01, 2006 at 12:27:54PM -0500, Eric Anderson wrote: >> >>> Wouldn't this be incorrect for files that are really full of zeros? >>> It would turn them in to sparse files when they shouldn't be, >>> correct? Is that what happens with other tools? >> >> >> Why is this bad? I'm not suggesting that the default implementation >> should change but that this "-s" option be added to properly optimize >> for sparse files. A sparse file is one which contains blocks of pure >> zeros. My example wouldn't vary in how the destination file is read >> but in how many blocks are allocated in the underlying file system. > > > It could possibly be bad if you have a real file (say a 10GB file, > partially filled with zeros - a disk image created with dd for > instance), and you use cp with something like -spR to recursively copy > all files. Your destination disk image would then be a sparse file, > so additional changes and modifications to the file (block > allocations) would fragment the image and make it slower. That would > be unexpected and probably go unnoticed for some time. I do see the > usefulness in this, but I think one needs to be careful to either > clearly note in the man page that it will make sparse files from *any* > file containing a string of zeros larger than the block size, or it > needs to 'do the right thing' and determine if it's sparse or not. > the option to copy sparsly is an option and not forced down the user's throat. I agree it would be a useful OPTION. at the moment there is no way to "sparsify" :-) a file easily. As long as the documentation warns that copying it without the sparse option might unexpectedly fill up your disk (or whatever your favourite trap is) then, it is UNIX's job to give you all teh tools you need and your job to decide when and where you shoot yorself in the foot. to "approximatly" quote Terry Lambert: " It is not unix's job to stop you from shooting your foot. If you so choose to do so, then it is UNIX's job to deliver Mr. Bullet to Mr Foot in the most efficient way it knows." > Eric > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 18:55:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A3E316A4DE for ; Tue, 1 Aug 2006 18:55:29 +0000 (UTC) (envelope-from prvs=julian=361365f97@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA0BD43D60 for ; Tue, 1 Aug 2006 18:55:24 +0000 (GMT) (envelope-from prvs=julian=361365f97@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 01 Aug 2006 11:55:24 -0700 Message-ID: <44CFA39C.70905@elischer.org> Date: Tue, 01 Aug 2006 11:55:24 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> In-Reply-To: <44CF8F1A.5090506@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rick-freebsd@kiwi-computer.com Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 18:55:29 -0000 Eric Anderson wrote: > On 08/01/06 12:11, Rick C. Petty wrote: > >> On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote: >> >>> On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: >>> >>>> I agree with this, and while you're in there, can you add -s to >>>> copy sparse files (via the usual "if the buffer is all nulls, seek >>>> beyond eof instead of writing" trick)? >>> >>> Note that it isn's possible to accurately distinguish between a block >>> of NULs and a hole in the file through the filesystem. The only way >>> to accurately copy a sparse file is with dump/restore. >> >> >> Sure it is-- in a number of ways. The most useful way is to do >> something >> of the sort: >> >> int sd, dd; // assume these are set to source & dest descriptors >> unsigned char* zeros; >> unsigned char* buffer; >> struct stat st; >> size_t bytes, offset; >> >> fstat(sd, &st); >> zeros = malloc(st.st_blksize); >> bzero(zeros, st.st_blksize); >> >> for (offset = 0; offset < st.st_size; offset += bytes) >> { >> bytes = st.st_blksize; >> if (offset + bytes > st.st_size) >> bytes = st.st_size - offset; >> read(sd, buffer, bytes); >> if (0 == memcmp(buffer, zeros, bytes)) >> lseek(dd, bytes, SEEK_CUR); >> else >> write(sd, buffer, bytes); >> } >> >> Obviously, I didn't add the error checking/handling, but AFAIK this is >> essentially what the -S option to gnu's tar does. In this example, you >> may not mimic the allocated blocks of a sparse file, but you would >> optimize the copy to use as few filesystem blocks as possible. > > > Wouldn't this be incorrect for files that are really full of zeros? > It would turn them in to sparse files when they shouldn't be, > correct? Is that what happens with other tools? If you use the sparse option then that is what you are asking it to do. > > Eric > > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 19:05:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1D6C16A591 for ; Tue, 1 Aug 2006 19:05:16 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B228A43D78 for ; Tue, 1 Aug 2006 19:05:05 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail03.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k71J4sVr029387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Aug 2006 05:04:55 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k71J4rbQ003217; Wed, 2 Aug 2006 05:04:53 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k71J4r05003216; Wed, 2 Aug 2006 05:04:53 +1000 (EST) (envelope-from peter) Date: Wed, 2 Aug 2006 05:04:53 +1000 From: Peter Jeremy To: Eric Anderson Message-ID: <20060801190453.GD717@turion.vk2pj.dyndns.org> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SO98HVl1bnMOfKZd" Content-Disposition: inline In-Reply-To: <44CF94A4.3000306@centtech.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, rick-freebsd@kiwi-computer.com Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 19:05:17 -0000 --SO98HVl1bnMOfKZd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote: >string of zeros larger than the block size, or it needs to 'do the right= =20 >thing' and determine if it's sparse or not. You can do this by comparing stat.st_size with stat.st_blocks - a sparse file will have fewer blocks than its size requires. What you can't do is accurately determine where the holes are. Note that st_blksize is not nessarily the allocation blocksize and therefore is unrelated to the size of holes in the filesystem. Also, on FreeBSD, the designation of "optimal" is a misnomer and I/O operations should be much larger than this for optimal efficiency. --=20 Peter Jeremy --SO98HVl1bnMOfKZd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEz6XU/opHv/APuIcRAvE4AJoDnQ182fq7H5d8xPFjdM9eWHO4HQCfY1Rc bRpeb1FabKXVxYvM9sfwV5I= =RNRl -----END PGP SIGNATURE----- --SO98HVl1bnMOfKZd-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 20:16:50 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90D6A16A4E6 for ; Tue, 1 Aug 2006 20:16:50 +0000 (UTC) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from correo.novusordo.net (cdjj.org [216.194.85.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1F9D43D5A for ; Tue, 1 Aug 2006 20:16:48 +0000 (GMT) (envelope-from cdjones-freebsd-hackers@novusordo.net) Received: from [192.168.4.141] (nipisi.cs.ualberta.ca [129.128.4.7]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by correo.novusordo.net (Postfix) with ESMTP id B0DE811532 for ; Tue, 1 Aug 2006 14:16:47 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: freebsd-hackers@freebsd.org Message-Id: Content-Type: multipart/mixed; boundary=Apple-Mail-3-62547150 From: Chris Jones Date: Tue, 1 Aug 2006 14:16:46 -0600 X-Mailer: Apple Mail (2.752.2) Subject: [PATCH] Jail Memory Limits X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 20:16:50 -0000 --Apple-Mail-3-62547150 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, folks --- I have a beta patch to add memory limits (on the basis of RSS) to jails, and would love to get some people to test it out. The patch files (below) are against RELENG_6 from earlier this morning, but should work against anything recent. They should be applied under /usr/src. This creates a kernel process for each jail to intermittently 1) check whether the jail's overcommitted on RSS and 2) if so, to partially page out the processes in the same way that's used for when the system's short on memory. This permits short periods of over- use, with a tendency back to the limit. (Aside: this is the same way Solaris handles it.) To test, use the new '-m MEM_LIMIT_IN_MB' flag to jail to set the memory limit for the jail; I've also included a trivial program which consumes and holds memory which can be run inside the jail. Take a look on the console for the debugging information, which is rather verbose at the moment. I'm expecting patches for jail scheduling to be coming down the pipe soon. Cheers, Chris --Apple-Mail-3-62547150 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=kern.patch Content-Disposition: attachment; filename=kern.patch Only in /usr/src/sys/kern: CVS diff -u /usr/src/sys/kern/kern_jail.c sys/kern/kern_jail.c --- /usr/src/sys/kern/kern_jail.c Sat Nov 12 20:12:32 2005 +++ sys/kern/kern_jail.c Tue Aug 1 12:18:07 2006 @@ -15,12 +15,19 @@ #include #include #include +#include #include #include #include #include #include #include +#include +#include +#include +#include +#include +#include #include #include #include @@ -92,6 +99,134 @@ SYSINIT(prison, SI_SUB_INTRINSIC, SI_ORDER_ANY, init_prison, NULL); +static void +jsched_td(void *arg) +{ + struct prison *pr; + pr = arg; + +/* printf("Starting jsched_td\n"); */ + + for (;;) { + if (pr->pr_scheduler_flags & J_SCHED_TD_DIE) + break; + + /* Scheduling stuff goes here. */ +/* printf("jsched_td running\n"); */ + tsleep(pr, 0, "-", hz); + } + +/* printf("Exiting jsched_td\n"); */ + + pr->pr_scheduler_flags = J_SCHED_TD_DEAD; + kthread_exit(0); +} + +static void +jpager_td(void *arg) +{ + struct proc *p; + struct prison *pr; + struct thread *td; + long limit, cursize, newsize, usage; + int breakout; + + pr = arg; + + printf("Starting jpager/%d with memory limit %ld bytes\n", + pr->pr_id, (long) prison_memory_limit(pr)); + + for (;;) { + if (pr->pr_pager_flags & J_PAGER_TD_DIE) + break; + + /* TODO: consider whether it might be better to start + * pushing back when we approach the limit, rather than + * when we hit it. + */ + limit = (long) prison_memory_limit(pr); + usage = (long) prison_memory(pr); + + /* The logic from vm_daemon() really needs to go here. + * Problem: we want to push things below their rlimits. + * + * TODO: refactor vm_daemon to optionally act on specific jails? + */ + + printf("jpager/%d: memory %ld / %ld bytes\n", + pr->pr_id, usage, limit); + + if ((usage - limit) > 0) { + printf("jpager/%d: overcommitted by %ld bytes (%lf percent)\n", + pr->pr_id, usage - limit, + (double) 100 * ((double) (usage - limit) / (double) limit)); + sx_slock(&allproc_lock); + LIST_FOREACH(p, &allproc, p_list) { + + if (pr != p->p_ucred->cr_prison) + continue; + + PROC_LOCK(p); + if (p->p_flag & (P_SYSTEM | P_WEXIT)) { + PROC_UNLOCK(p); + continue; + } + + mtx_lock_spin(&sched_lock); + breakout = 0; + FOREACH_THREAD_IN_PROC(p, td) { + if (!TD_ON_RUNQ(td) && + !TD_IS_RUNNING(td) && + !TD_IS_SLEEPING(td)) { + breakout = 1; + break; + } + } + mtx_unlock_spin(&sched_lock); + if (breakout) { + PROC_UNLOCK(p); + continue; + } + + /* NOTE: we differ here from vm_daemon b/c we don't + * care about the rlimit; things that are exceeding that will + * get caught in due course. We need, however, to decrease + * the pressure on our permitted memory allocation. Fortunately, + * we only care about eventually hitting the limit, so if we + * don't get there right away, it's okay. + */ + + /* TODO: this arbitrarily reduces each process's space by + * 5% (until it's completely swapped out) while + * we're under memory pressure. A better way would be + * to either hit large processes first, or to hit the + * least-active processes first, or go proportionally, + * or .... + */ + newsize = cursize = (long) vmspace_resident_count(p->p_vmspace); + newsize -= newsize / 20; + if (cursize < 0) + newsize = 0; + PROC_UNLOCK(p); + printf("jpager/%d: squeezing process %d from %ld to %ld\n", + pr->pr_id, p->p_pid, cursize, newsize); + vm_pageout_map_deactivate_pages(&p->p_vmspace->vm_map, newsize); + } /* end LIST_FOREACH procs */ + sx_sunlock(&allproc_lock); + } + + /* TODO --- make interval into a sysctl. */ + /* 6 seconds because VM recomputes totals every 5. */ + printf("jpager_td sleeping\n"); + tsleep(pr, 0, "-", 6 * hz); + } + + printf("Exiting jpager_td\n"); + + pr->pr_pager_flags = J_PAGER_TD_DEAD; + kthread_exit(0); +} + /* * MPSAFE * @@ -106,6 +241,8 @@ struct prison *pr, *tpr; struct jail j; struct jail_attach_args jaa; + struct proc *j_sched_proc = NULL; + struct proc *j_pager_proc = NULL; int vfslocked, error, tryprid; error = copyin(uap->jail, &j, sizeof(j)); @@ -135,7 +272,9 @@ goto e_dropvnref; pr->pr_ip = j.ip_number; pr->pr_linux = NULL; + pr->pr_priority = j.priority; pr->pr_securelevel = securelevel; + pr->pr_mem_limit = j.mem_limit; /* Determine next pr_id and add prison to allprison list. */ mtx_lock(&allprison_mtx); @@ -159,6 +298,19 @@ prisoncount++; mtx_unlock(&allprison_mtx); + /* TODO #ifdef SCHED_HIER */ + pr->pr_scheduler_flags = J_SCHED_TD_ACTIVE; + if (kthread_create(jsched_td, pr, (void *) j_sched_proc, 0, 0, "jsched %d", pr->pr_id)) + goto e_dropprref; + KASSERT(j_sched_proc != NULL, ("NULL j_sched_proc")); + pr->pr_scheduler = j_sched_proc; + pr->pr_pager_flags = J_PAGER_TD_ACTIVE; + if (kthread_create(jpager_td, pr, (void *) j_pager_proc, 0, 0, "jpager %d", pr->pr_id)) + goto e_dropprref; + KASSERT(j_pager_proc != NULL, ("NULL j_pager_proc")); + pr->pr_pager = j_pager_proc; + /* TODO #endif */ + error = jail_attach(td, &jaa); if (error) goto e_dropprref; @@ -282,6 +434,11 @@ prisoncount--; mtx_unlock(&allprison_mtx); + /* Tell scheduler to die. No need to wait for it. */ + pr->pr_scheduler_flags |= J_SCHED_TD_DIE; + pr->pr_pager_flags |= J_PAGER_TD_DIE; + wakeup(pr); + TASK_INIT(&pr->pr_task, 0, prison_complete, pr); taskqueue_enqueue(taskqueue_thread, &pr->pr_task); return; @@ -391,6 +548,42 @@ else ok = 0; return (ok); +} + +/* Given credential, return memory usage in bytes. */ +vm_pindex_t +prison_memory(struct prison *pr) +{ + struct proc *p; + u_int mem_used = 0; + + /* TODO: cut this to search only procs in given jail. */ + FOREACH_PROC_IN_SYSTEM(p) { + if (!jailed(p->p_ucred) || + (pr != p->p_ucred->cr_prison)) { + continue; + } + + /* Get memory usage (see vm/vm_map.h). */ + /* TODO maybe use vm_swrss? */ + mem_used += (p->p_vmspace)->vm_tsize; /* text size (pages) */ + mem_used += (p->p_vmspace)->vm_dsize; /* data size (pages) */ + mem_used += (p->p_vmspace)->vm_ssize; /* stack size (pages) */ + } + + /* Convert to bytes, cache (maybe unncessary?). */ + mem_used *= PAGE_SIZE; + /* mtx_lock(&pr->pr_mtx); + pr->pr_mem_usage = mem_used; + mtx_unlock(&pr->pr_mtx); */ + return mem_used; +} + +/* Given credential, return permitted memory usage in bytes. */ +vm_pindex_t +prison_memory_limit(struct prison *pr) +{ + return pr->pr_mem_limit; } /* --Apple-Mail-3-62547150 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=sys.patch Content-Disposition: attachment; filename=sys.patch Only in /usr/src/sys/sys: CVS diff -u /usr/src/sys/sys/jail.h sys/sys/jail.h --- /usr/src/sys/sys/jail.h Thu Jun 9 12:49:19 2005 +++ sys/sys/jail.h Fri Jul 28 12:03:26 2006 @@ -18,6 +18,10 @@ char *path; char *hostname; u_int32_t ip_number; + unsigned int priority; + unsigned int mem_limit; +/* struct thread *scheduler; + CJ TODO --- add reference to preferred scheduler, e.g. by name? */ }; struct xprison { @@ -26,9 +30,26 @@ char pr_path[MAXPATHLEN]; char pr_host[MAXHOSTNAMELEN]; u_int32_t pr_ip; + unsigned int priority; + unsigned int mem_limit; + /* struct thread *scheduler; */ }; #define XPRISON_VERSION 1 +#define JAIL_DEFAULT_PRIORITY 10 +#define JAIL_MINIMUM_PRIORITY 1 +#define JAIL_MAXIMUM_PRIORITY 100 + +#define JAIL_DEFAULT_MEM_LIMIT 256 * 1024 * 1024 + +#define J_SCHED_TD_ACTIVE 0x01 +#define J_SCHED_TD_DIE 0x02 +#define J_SCHED_TD_DEAD 0x04 + +#define J_PAGER_TD_ACTIVE 0x01 +#define J_PAGER_TD_DIE 0x02 +#define J_PAGER_TD_DEAD 0x04 + #ifndef _KERNEL int jail(struct jail *); @@ -61,6 +82,11 @@ * (d) set only during destruction of jail, no mutex needed */ #if defined(_KERNEL) || defined(_WANT_PRISON) + +#include +/*struct proc; */ + + struct prison { LIST_ENTRY(prison) pr_list; /* (a) all prisons */ int pr_id; /* (c) prison id */ @@ -73,6 +99,13 @@ int pr_securelevel; /* (p) securelevel */ struct task pr_task; /* (d) destroy task */ struct mtx pr_mtx; + unsigned int pr_priority; /* (p) jail priority */ + struct proc *pr_scheduler; /* (c) scheduler pid */ + int pr_scheduler_flags; /* (p) communication to scheduler */ + struct proc *pr_pager; /* (c) pager pid */ + int pr_pager_flags; /* (p) communication to pager */ + size_t pr_mem_limit; /* (p) memory allocation limit */ + size_t pr_mem_usage; /* (p) memory in use */ }; #endif /* _KERNEL || _WANT_PRISON */ @@ -110,6 +143,8 @@ void prison_hold(struct prison *pr); int prison_if(struct ucred *cred, struct sockaddr *sa); int prison_ip(struct ucred *cred, int flag, u_int32_t *ip); +vm_pindex_t prison_memory(struct prison *pr); +vm_pindex_t prison_memory_limit(struct prison *pr); void prison_remote_ip(struct ucred *cred, int flags, u_int32_t *ip); #endif /* _KERNEL */ --Apple-Mail-3-62547150 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name=usr.sbin.patch Content-Disposition: attachment; filename=usr.sbin.patch Only in /usr/src/usr.sbin/jail: CVS diff -u /usr/src/usr.sbin/jail/jail.c usr.sbin/jail/jail.c --- /usr/src/usr.sbin/jail/jail.c Tue Aug 1 13:50:48 2006 +++ usr.sbin/jail/jail.c Tue Aug 1 12:18:07 2006 @@ -56,6 +56,7 @@ struct in_addr in; gid_t groups[NGROUPS]; int ch, i, iflag, Jflag, lflag, ngroups, securelevel, uflag, Uflag; + unsigned int mem_limit, priority; char path[PATH_MAX], *ep, *username, *JidFile; static char *cleanenv; const char *shell, *p = NULL; @@ -63,11 +64,13 @@ FILE *fp; iflag = Jflag = lflag = uflag = Uflag = 0; + mem_limit = JAIL_DEFAULT_MEM_LIMIT; + priority = JAIL_DEFAULT_PRIORITY; securelevel = -1; username = JidFile = cleanenv = NULL; fp = NULL; - while ((ch = getopt(argc, argv, "ils:u:U:J:")) != -1) { + while ((ch = getopt(argc, argv, "ilp:m:s:u:U:J:")) != -1) { switch (ch) { case 'i': iflag = 1; @@ -76,6 +79,17 @@ JidFile = optarg; Jflag = 1; break; + case 'm': + /* TODO --- should this be specified in MB? */ + mem_limit = atoi(optarg); + mem_limit *= 1024 * 1024; + break; + case 'p': + priority = atoi(optarg); + if (priority < JAIL_MINIMUM_PRIORITY || + priority > JAIL_MAXIMUM_PRIORITY) + errx(1, "invalid priority: `%s'", optarg); + break; case 's': ltmp = strtol(optarg, &ep, 0); if (*ep || ep == optarg || ltmp > INT_MAX || !ltmp) @@ -118,6 +132,8 @@ if (inet_aton(argv[2], &in) == 0) errx(1, "Could not make sense of ip-number: %s", argv[2]); j.ip_number = ntohl(in.s_addr); + j.mem_limit = mem_limit; + j.priority = priority; if (Jflag) { fp = fopen(JidFile, "w"); if (fp == NULL) @@ -182,8 +198,10 @@ usage(void) { - (void)fprintf(stderr, "%s%s%s\n", - "usage: jail [-i] [-J jid_file] [-s securelevel] [-l -u ", + (void)fprintf(stderr, "%s%s%s%s%s\n", + "usage: jail [-i] [-J jid_file] [-m mem_limit] ", + "[-p priority] [-s securelevel]", + " [-l -u ", "username | -U username]", " path hostname ip-number command ..."); exit(1); --Apple-Mail-3-62547150 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0444; name=useMemory.c Content-Disposition: attachment; filename=useMemory.c #include #include #include #include #include #include static void usage(void); extern char **environ; int main(int argc, char **argv) { unsigned int memsize; unsigned int p = 0; /* offset from beginning of boundary */ char *memstart; int ch; char testdata = 0xff; while ((ch = getopt(argc, argv, "m:")) != -1) { switch (ch) { case 'm': memsize = atoi(optarg); memsize *= 1024 * 1024; break; default: usage(); } } argc -= optind; argv += optind; /* Allocate memory. */ memstart = malloc(memsize * sizeof(char)); if (NULL == memstart) { printf("useMemory: couldn't allocate memory!"); exit(2); } printf("useMemory: allocated %ld bytes of memory\n", memsize); while (p < memsize) { memstart[p] = 0xde; memstart[p+1] = 0xad; memstart[p+2] = 0xbe; memstart[p+3] = 0xef; if (0 == (p % 1048576)) printf("useMemory: writing to %ld / %ld bytes at %p (%dddd)\n", p, memsize, &memstart[p], memstart[p], memstart[p+1], memstart[p+2], memstart[p+3]); p += 1024; /* this really should be set to the page size */ } for (;;) sleep(10); exit(0); } static void usage(void) { (void) fprintf(stderr, "%s\n", "usage: useMemory [-m memsize]"); exit(1); } --Apple-Mail-3-62547150-- From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 20:18:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 353D216A4DD for ; Tue, 1 Aug 2006 20:18:08 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 7757743D5C for ; Tue, 1 Aug 2006 20:18:07 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 5386 invoked by uid 2001); 1 Aug 2006 20:18:06 -0000 Date: Tue, 1 Aug 2006 15:18:06 -0500 From: "Rick C. Petty" To: Peter Jeremy Message-ID: <20060801201806.GC4272@megan.kiwi-computer.com> References: <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> <20060801190453.GD717@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801190453.GD717@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 20:18:08 -0000 On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote: > >string of zeros larger than the block size, or it needs to 'do the right > >thing' and determine if it's sparse or not. > > You can do this by comparing stat.st_size with stat.st_blocks - a > sparse file will have fewer blocks than its size requires. What you > can't do is accurately determine where the holes are. > > Note that st_blksize is not nessarily the allocation blocksize and > therefore is unrelated to the size of holes in the filesystem. Also, > on FreeBSD, the designation of "optimal" is a misnomer and I/O > operations should be much larger than this for optimal efficiency. True, but I've not seen the case where the following is not true: The filesystem's block size (i.e. 8x fragment size) in UFS an integer multiple of st_blksize. My previously-posted example would work just fine. I guess a better solution would be to check every 512-byte chunk and seek if zero. It's up to the underlying filesystem to implement this as a sparse file, if that filesystem supports such a thing. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 21:30:53 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D90E16A4DD for ; Tue, 1 Aug 2006 21:30:53 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from antivirus.uni-rostock.de (mailrelay1.uni-rostock.de [139.30.8.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C239A43D45 for ; Tue, 1 Aug 2006 21:30:51 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from antivirus.exch.rz.uni-rostock.de ([127.0.0.1]) by antivirus.uni-rostock.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 23:30:50 +0200 Received: from antivirus.uni-rostock.de (unverified) by antivirus.exch.rz.uni-rostock.de (Content Technologies SMTPRS 4.3.20) with ESMTP id for ; Tue, 1 Aug 2006 23:30:50 +0200 Received: from mail pickup service by antivirus.uni-rostock.de with Microsoft SMTPSVC; Tue, 1 Aug 2006 23:30:49 +0200 X-SCL: 5 70.15% Received: from mail.uni-rostock.de ([139.30.8.11]) by antivirus.uni-rostock.de with Microsoft SMTPSVC (6.0.3790.1830); Tue, 1 Aug 2006 23:30:49 +0200 Received: from conversion-daemon.mail2.uni-rostock.de by mail2.uni-rostock.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) id <0J3C00B018TZN6@mail.uni-rostock.de> (original mail from joerg@britannica.bec.de) for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 23:30:49 +0200 (MEST) Received: from britannica.bec.de (storm.stura.uni-rostock.de [139.30.252.72]) by mail2.uni-rostock.de (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) with ESMTP id <0J3C002UV93DY8@mail.uni-rostock.de> for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 23:30:49 +0200 (MEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 2504A63D7; Tue, 01 Aug 2006 23:30:26 +0200 (CEST) Date: Tue, 01 Aug 2006 23:30:26 +0200 From: Joerg Sonnenberger In-reply-to: <20060801190453.GD717@turion.vk2pj.dyndns.org> To: freebsd-hackers@freebsd.org Mail-followup-to: freebsd-hackers@freebsd.org Message-id: <20060801213026.GA26016@britannica.bec.de> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.5.12-2006-07-14 References: <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> <20060801190453.GD717@turion.vk2pj.dyndns.org> X-OriginalArrivalTime: 01 Aug 2006 21:30:49.0407 (UTC) FILETIME=[C1EDE4F0:01C6B5B1] Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 21:30:53 -0000 On Wed, Aug 02, 2006 at 05:04:53AM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 12:51:32 -0500, Eric Anderson wrote: > >string of zeros larger than the block size, or it needs to 'do the right > >thing' and determine if it's sparse or not. > > You can do this by comparing stat.st_size with stat.st_blocks - a > sparse file will have fewer blocks than its size requires. What you > can't do is accurately determine where the holes are. There's an extension for the seek interface in Solaris to do that. Joerg Schily discussed this with some of us BSD developers in Chemnitz/Germany earlier this year. There was someone working on porting it to FreeBSD IIRC. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 21:38:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0785F16A4F2 for ; Tue, 1 Aug 2006 21:38:16 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99EB243D79 for ; Tue, 1 Aug 2006 21:38:03 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G81vy-0007Z8-Th for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 23:37:50 +0200 Received: from cmung1752.cmu.carnet.hr ([193.198.134.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:37:50 +0200 Received: from ivoras by cmung1752.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:37:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 01 Aug 2006 23:37:47 +0200 Lines: 10 Message-ID: References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44CF94A4.3000306@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1752.cmu.carnet.hr User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) In-Reply-To: <44CF94A4.3000306@centtech.com> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 21:38:16 -0000 Eric Anderson wrote: > It could possibly be bad if you have a real file (say a 10GB file, > partially filled with zeros - a disk image created with dd for > instance), and you use cp with something like -spR to recursively copy > all files. Your destination disk image would then be a sparse file, so Incidentally, this is exactly why I've needed it - I like to create disk images for virtual machines as sparse files, when I know they won't be much filled, but need the "virtual" space :) From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 21:49:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7030D16A4FA for ; Tue, 1 Aug 2006 21:49:06 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C784143E5C for ; Tue, 1 Aug 2006 21:47:10 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G823p-000120-AJ for freebsd-hackers@freebsd.org; Tue, 01 Aug 2006 23:45:57 +0200 Received: from cmung1752.cmu.carnet.hr ([193.198.134.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:45:57 +0200 Received: from ivoras by cmung1752.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Aug 2006 23:45:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 01 Aug 2006 23:44:51 +0200 Lines: 45 Message-ID: References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <17615.40148.872008.53973@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1752.cmu.carnet.hr User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) In-Reply-To: <17615.40148.872008.53973@bhuda.mired.org> Sender: news Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 21:49:06 -0000 Mike Meyer wrote: > I always think of cp as a tool for making *copies of files*, not for > creating an archive of a directory tree. We've got lots of tools that > do the latter. Do we really need another one? But, but, but - I only asked for cp to be able to copy my sparse files as sparse files, not do magic with them :) The side-effect that it will sparsify other files is both unavoidable and actually useful. OTOH, for copying/sparisfying single files, dd should be fixed. vsdev:/tmp> l total 2 drwx------ 2 ivoras wheel 512 Jul 9 00:08 mc-ivoras/ vsdev:/tmp> dd if=/dev/zero of=file bs=1024 seek=100 count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.016648 secs (61509 bytes/sec) vsdev:/tmp> l total 8 -rw-r--r-- 1 ivoras wheel 103424 Aug 1 21:40 file drwx------ 2 ivoras wheel 512 Jul 9 00:08 mc-ivoras/ vsdev:/tmp> du -shc file 6.0K file 6.0K total vsdev:/tmp> l total 8 -rw-r--r-- 1 ivoras wheel 103424 Aug 1 21:40 file drwx------ 2 ivoras wheel 512 Jul 9 00:08 mc-ivoras/ vsdev:/tmp> dd if=file of=file2 bs=1024 conv=sparse 101+0 records in 101+0 records out 103424 bytes transferred in 0.130216 secs (794250 bytes/sec) vsdev:/tmp> l total 110 -rw-r--r-- 1 ivoras wheel 103424 Aug 1 21:40 file -rw-r--r-- 1 ivoras wheel 103424 Aug 1 21:41 file2 drwx------ 2 ivoras wheel 512 Jul 9 00:08 mc-ivoras/ vsdev:/tmp> du -shc file* 6.0K file 102K file2 108K total From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 22:51:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29C1316A4DD for ; Tue, 1 Aug 2006 22:51:57 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7FDB43D46 for ; Tue, 1 Aug 2006 22:51:56 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 70FD52948D; Tue, 1 Aug 2006 15:51:56 -0700 (PDT) To: Ivan Voras In-reply-to: Your message of "Tue, 01 Aug 2006 23:37:47 +0200." Date: Tue, 01 Aug 2006 15:51:56 -0700 From: Bakul Shah Message-Id: <20060801225156.70FD52948D@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 22:51:57 -0000 > Eric Anderson wrote: > > > It could possibly be bad if you have a real file (say a 10GB file, > > partially filled with zeros - a disk image created with dd for > > instance), and you use cp with something like -spR to recursively copy > > all files. Your destination disk image would then be a sparse file, so > > Incidentally, this is exactly why I've needed it - I like to create disk > images for virtual machines as sparse files, when I know they won't be > much filled, but need the "virtual" space :) [Basic idea from the plan 9 guys] Rather than modify every tool for this may be the OS should avoid writing a block of zeroes? The idea is to check if the first and last word are 0. If so, check the whole block (you can avoid the necessary bounds check by temporarily unzeroing the last word). If all zeroes and there is no existing allocation for the range being written, just advance the current offset (essentially lseek). Else proceed as normal write. This test is very cheap in practice and if you can avoid one write in ten thousand this way you will likely see overall savings. Of course, you still need rsync but it help all local copying, the common case. This being an optimization you don't need to implement a complete solution. For instance writing 1 zero byte in one call and then 4095 zero bytes in another may defeat the optimization. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 00:09:13 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 540AE16A4DD for ; Wed, 2 Aug 2006 00:09:13 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF7AD43D49 for ; Wed, 2 Aug 2006 00:09:12 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k72098IQ011178; Tue, 1 Aug 2006 20:09:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060801171912.GC3413@megan.kiwi-computer.com> References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171912.GC3413@megan.kiwi-computer.com> Date: Tue, 1 Aug 2006 20:09:08 -0400 To: rick-freebsd@kiwi-computer.com From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 00:09:13 -0000 At 12:19 PM -0500 8/1/06, Rick C. Petty wrote: >On Tue, Aug 01, 2006, Garance A Drosehn wrote: > > >> The point is not that you need an explicit switch, the >> point is that you have to add a lot of code to 'cp' for >> 'cp' to do the job correctly. > >Not really. See my example in a previous post. All you >need to do is perform an lseek(2) instead of a write(2) >if the block you read is all zero. I guess it depends on what the option will be described as doing. If you want an option which will "sparse-ify" any file, then yes that's easy to do. I had understood this option as a request to "copy all the existing holes", which is not the same thing. I.e., I thought we wanted `cp' to create the new file such that it would take up exactly the same number of disk blocks, and have the same number of holes (in exactly the same places) as the original file. I agree that "sparse-ify" should be easy to implement, and could be useful. I'm not fond of the idea, but I can see how people might want it. I do would not like it, because the user will have to know whether it is appropriate to use on a file-by-file basis. You can't just 'cp -rp' an entire directory, and feel confident that the "Right Thing(TM)" will happen for each file that is being copied. So, if I am copying directories, I'll still have to resort to some other tool to get the job done "Right(TM)". In my case, I want zeros on the disk in the destination wherever there were zeros on the disk in the source. In some situations, I don't want the number-of-blocks of a file to increase every time I change a X'00' to a X'01'. It would be nice for `cp' to do that too, but I expect *that* would add too much bloat to `cp'. Not only that, but it just sets us up for the next request for `cp' to do "perfectly-accurate copies" of files. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 00:17:58 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5762516A4DE for ; Wed, 2 Aug 2006 00:17:58 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 69C9343D49 for ; Wed, 2 Aug 2006 00:17:57 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 7187 invoked by uid 2001); 2 Aug 2006 00:17:56 -0000 Date: Tue, 1 Aug 2006 19:17:56 -0500 From: "Rick C. Petty" To: Garance A Drosehn Message-ID: <20060802001756.GB6671@megan.kiwi-computer.com> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171912.GC3413@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 00:17:58 -0000 On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote: > > I had understood this option as a request to "copy all the > existing holes", which is not the same thing. I.e., I > thought we wanted `cp' to create the new file such that it > would take up exactly the same number of disk blocks, and > have the same number of holes (in exactly the same places) > as the original file. Which it currently doesn't, without any sparse option. A copied file will always be larger than the original (in terms of disk blocks) if the original had any sparseness. > I agree that "sparse-ify" should be easy to implement, and > could be useful. I'm not fond of the idea, but I can see > how people might want it. I do would not like it, because > the user will have to know whether it is appropriate to use > on a file-by-file basis. You can't just 'cp -rp' an entire > directory, and feel confident that the "Right Thing(TM)" > will happen for each file that is being copied. So, if I > am copying directories, I'll still have to resort to some > other tool to get the job done "Right(TM)". I don't see why not. If you're mixing sparse and non-sparse files in a tree and wish to duplicate this precisely, you need dump/restore.. oh, and those only work for UFS filesystems. Whatever the Right Thing is, you should have a good idea whether you wish to sparsify or anti-sparsify the files beneath (current cp does the anti-sparsify). If you're doing a directory copy and cannot choose which is the Right Thing for everything within that directory, then cp(1) certainly is not your choice. > In my case, I want zeros on the disk in the destination > wherever there were zeros on the disk in the source. This may be true with cp(1) as it is now, but certainly the converse is not guaranteed to be true. > In some situations, I don't want the number-of-blocks of a > file to increase every time I change a X'00' to a X'01'. Whereas the opposite situation is preferrable? Hmm, I'm using Y bytes of storage within this directory tree, let's move that to another partition. I'll make that partition at least Y bytes big. Recursive copy-- whoa! Out of space? Darn. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 01:27:34 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A368216A4DF for ; Wed, 2 Aug 2006 01:27:34 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AD3543D6D for ; Wed, 2 Aug 2006 01:27:29 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k721RQdM024734; Tue, 1 Aug 2006 21:27:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060802001756.GB6671@megan.kiwi-computer.com> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171912.GC3413@megan.kiwi-computer.com> <20060802001756.GB6671@megan.kiwi-computer.com> Date: Tue, 1 Aug 2006 21:27:25 -0400 To: rick-freebsd@kiwi-computer.com From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 01:27:34 -0000 At 7:17 PM -0500 8/1/06, Rick C. Petty wrote: >On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote: >> >> I had understood this option as a request to "copy all the >> existing holes", which is not the same thing. I.e., I >> thought we wanted `cp' to create the new file such that it >> would take up exactly the same number of disk blocks, and >> have the same number of holes (in exactly the same places) >> as the original file. > >Which it currently doesn't, without any sparse option. Yes, but we know it doesn't, and we don't expect it to. I *thought* what this thread was asking was for someone to add some new option to `cp', where that new option would do the above. But I was wrong with that, and apparently people would be happy with a new option which says "sparse-ify the file". > > I agree that "sparse-ify" should be easy to implement, and >> could be useful. I'm not fond of the idea, but I can see >> how people might want it. I do would not like it, because >> the user will have to know whether it is appropriate to use >> on a file-by-file basis. You can't just 'cp -rp' an entire >> directory, and feel confident that the "Right Thing(TM)" >> will happen for each file that is being copied. So, if I >> am copying directories, I'll still have to resort to some >> other tool to get the job done "Right(TM)". > >I don't see why not. I don't care if you don't see it. I am just stating my personal opinion, and apparently I am not even doing a good job at that. I will stop now. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 02:48:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A245C16A4E2 for ; Wed, 2 Aug 2006 02:48:18 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70EF543D67 for ; Wed, 2 Aug 2006 02:48:14 +0000 (GMT) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G86mI-0006O4-Tb for freebsd-hackers@freebsd.org; Wed, 02 Aug 2006 04:48:10 +0200 Received: from cmung1632.cmu.carnet.hr ([193.198.134.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Aug 2006 04:48:10 +0200 Received: from ivoras by cmung1632.cmu.carnet.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Aug 2006 04:48:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 02 Aug 2006 04:48:07 +0200 Lines: 15 Message-ID: References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171912.GC3413@megan.kiwi-computer.com> <20060802001756.GB6671@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cmung1632.cmu.carnet.hr User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) In-Reply-To: Sender: news Subject: Sparsifying X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 02:48:18 -0000 Garance A Drosehn wrote: > I *thought* what this thread was asking was for someone > to add some new option to `cp', where that new option It's a thread about several options to cp. > would do the above. But I was wrong with that, and > apparently people would be happy with a new option which > says "sparse-ify the file". Are you referring to the inablity to distinguish files with intentional NUL bytes and sparse files? Because of that, "copy sparse files as sparse files" and "sparsify files" are the same operation. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 05:22:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BF4416A4DD for ; Wed, 2 Aug 2006 05:22:33 +0000 (UTC) (envelope-from qdolan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7236D43D5F for ; Wed, 2 Aug 2006 05:22:32 +0000 (GMT) (envelope-from qdolan@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so1758932uge for ; Tue, 01 Aug 2006 22:22:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer; b=H1ndJv8rrKbrtC6mcbSLATuifNaFPk57aKyxObxQyhq1iEkL8Oh5vptBbJTxMETEvL1DH7fJhTIdw02rzABzpCXb5w/6G5qcAqu61bST1zmc6huCFG+5rOy+C5JInkLLS24A/22oNe6zUILd9imizE51jKJGpB+PPohXBQV6Ngg= Received: by 10.65.139.9 with SMTP id r9mr725489qbn; Tue, 01 Aug 2006 22:22:31 -0700 (PDT) Received: from ?172.22.1.30? ( [203.13.70.60]) by mx.gmail.com with ESMTP id 8sm747306nzn.2006.08.01.22.22.29; Tue, 01 Aug 2006 22:22:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Message-Id: <7F8170AC-5DFC-4C7B-BF2A-916AB7F73CC6@gmail.com> From: Q Date: Wed, 2 Aug 2006 15:22:26 +1000 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Req: Help tracking possible kernel memory leak. - possibly filesystem related X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 05:22:33 -0000 On 01/08/2006, at 3:10 PM, Q wrote: > I was wondering if someone could help point me in the direction of > how to go about trying to resolve what I assume to be a memory leak > in FreeBSD 6.x. I have made some more progress on identifying this problem. If I drop to single user mode, and then unmount the volume that houses the database and the raw data, the accumulated memory is released. When it did this earlier it dropping from 870M 'active' to 7M 'active' (according to top), just by unmounting the filesystem. If someone familiar with the memory handling of the ufs code could help shed some light on what this problem might be it would be much appreciated. Anyway.. off to grok some source code. > I have two database servers, one running 6.0 the other 6.1, both > are running PostgreSQL. They both have 4gig of memory, running a > generic kernel with the following sysctl's tweaked: > > kern.ipc.semmni=128 > kern.ipc.semmns=512 > kern.ipc.semume=100 > kern.ipc.semmnu=256 > kern.maxdsiz=1073741824 > kern.dfldsiz=1073741824 > kern.maxssiz=134217728 > kern.ipc.shmmax=536870912 > kern.ipc.shmall=262144 > kern.ipc.shm_use_phys=1 > net.inet.udp.maxdgram=63535 > > They are both used for processing an extremely large amount of data > collected from various sources every 5 minutes and therefore > perform virtually identical workloads. All processing is performed > locally, there is only 1 external connection being made to the > database, once a day to retrieve a small selection of data. > > Both machines are showing a constantly growing 'Active' memory > usage in 'top' until they reach a point where the database > performance drop dramatically and disk IO goes through the roof. If > the machine is left to run in this state it appears to eventually > just hang (at least this is what happened to one of the machines). > > Most recently one of the servers (running 6.1) had an "Active > Memory" total of 1.6Gig, database performance was significantly > worse than normal, and disk io was dramatically higher. Queries > that previously took a few seconds were taking several minutes. > > Using vmstat, ps and top, along with restarting the database I was > unable to find anything that would indicate a user space leak > consuming this 1.6Gig of memory. The only way I found to free this > memory and ultimately restore the database performance was to > reboot the machine. Which resulted in the "Active memory" resetting > back to virtually nothing and proceeded to slowly climb again > (after 4 days one server is up to about 380Mb, and the other server > is at about 680Mb after 7 days) and growing at an almost linear rate. > > If someone would be so kind as to provide some advice on how to > track down this issue it would be much appreciated. > > Having to reboot these machines every 15 days is simply not a > viable option. -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _____ / Quinton Dolan - q@OntheNet.com.au. __ __/ / / __/ / / OntheNet - Internet Provider / __ / _/ / / Gold Coast, QLD, Australia __/ __/ __/ ____/ / - / Ph: +61 419 729 806 _______ / _\ -- Seeya...Q -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _____ / Quinton Dolan - qdolan@gmail.com __ __/ / / __/ / / / __ / _/ / / Gold Coast, QLD, Australia __/ __/ __/ ____/ / - / Ph: +61 419 729 806 _______ / _\ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 06:28:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8605D16A4E1 for ; Wed, 2 Aug 2006 06:28:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A6843D4C for ; Wed, 2 Aug 2006 06:28:51 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.221] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k726SijU010756; Tue, 1 Aug 2006 23:28:51 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <44D0461C.40909@freebsd.org> Date: Tue, 01 Aug 2006 23:28:44 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171912.GC3413@megan.kiwi-computer.com> In-Reply-To: <20060801171912.GC3413@megan.kiwi-computer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Extended Attributes in Tar (was Re: [PATCH] adding two new options to 'cp') X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 06:28:52 -0000 Rick C. Petty wrote: > > ... I don't think cp or tar do [handle extended attributes] either. Actually, the OS-independent code for extended attributes has already been implemented in libarchive, thanks to Jaako Heinonen, who also wrote the Linux-specific portions for archive_extract (restore to disk) and tar/write.c (read from disk). All that's needed is for someone to write the FreeBSD-specific portions. I'd be happy to give pointers to anyone who has the time to finish this. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 06:35:11 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D7E216A4EA for ; Wed, 2 Aug 2006 06:35:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE03043D55 for ; Wed, 2 Aug 2006 06:35:03 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.221] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k726Z3jU010788; Tue, 1 Aug 2006 23:35:03 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <44D04797.1040201@freebsd.org> Date: Tue, 01 Aug 2006 23:35:03 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> In-Reply-To: <20060801174048.GE3413@megan.kiwi-computer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 06:35:11 -0000 Rick C. Petty wrote: > > While we're at it, I think we should add the -S option to bsdtar. I'm > willing to do the work ... I have pretty strong ideas about sparse file support for bsdtar. The "cheap" solution is to handle it purely on extract: Detect blocks of zeros when restoring files and seek over them. That would be pretty easy to implement: just add another option to archive_read_extract() and implement the logic to skip over blocks of zeros. Archiving sparse files as such is harder, although I do have an outline of a technique which would not only handle sparse files, but also allow archiving files whose size is not known in advance (something the GNU tar approach doesn't support). I simply dislike the GNU tar approach, in part because it requires two passes over the file (the map of holes is required before the file is written). Again, if someone is really interested, let me know. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 07:33:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C90FC16A4DA; Wed, 2 Aug 2006 07:33:47 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id B571743D5A; Wed, 2 Aug 2006 07:33:43 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail08.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k727XeZl000582 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Aug 2006 17:33:41 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k727XegJ000909; Wed, 2 Aug 2006 17:33:40 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k727Xewp000908; Wed, 2 Aug 2006 17:33:40 +1000 (EST) (envelope-from peter) Date: Wed, 2 Aug 2006 17:33:40 +1000 From: Peter Jeremy To: Tim Kientzle Message-ID: <20060802073340.GA713@turion.vk2pj.dyndns.org> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44D04797.1040201@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <44D04797.1040201@freebsd.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 07:33:47 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote: >The "cheap" solution is to handle it purely on >extract: Detect blocks of zeros when restoring >files and seek over them. The downside is that you wind up with a sparse file whether or not you wanted one. > I simply dislike >the GNU tar approach, in part because it requires >two passes over the file (the map of holes is required >before the file is written). Actually, the only real solution to copying sparse files is to add a system call that can return a map of holes. This would neatly address the "needs two passes" problem with tar. As a general comment (not addressed to Tim): There _is_ a downside to sparsifying files. If you take a sparse file and start filling in the holes, the net result will be very badly fragmented and hence have very poor sequential I/O performance. If you're never going to update a file then making it sparse makes sense, if you will be updating it, you will get better performance by making it non-sparse. --=20 Peter Jeremy --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE0FVU/opHv/APuIcRAiy3AJwNeZ3VgF2T69oKJlImDOw/bkCToACeMCXT TjXcuJ866a2PuQ6+fbSbaxE= =p4ti -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 07:55:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA38B16A4DA for ; Wed, 2 Aug 2006 07:55:32 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD21A43D45 for ; Wed, 2 Aug 2006 07:55:31 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail14.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k727tTrH013872 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Aug 2006 17:55:29 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k727tSPY001005; Wed, 2 Aug 2006 17:55:28 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k727tSAh001004; Wed, 2 Aug 2006 17:55:28 +1000 (EST) (envelope-from peter) Date: Wed, 2 Aug 2006 17:55:28 +1000 From: Peter Jeremy To: Q Message-ID: <20060802075528.GB713@turion.vk2pj.dyndns.org> References: <7F8170AC-5DFC-4C7B-BF2A-916AB7F73CC6@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <7F8170AC-5DFC-4C7B-BF2A-916AB7F73CC6@gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: Req: Help tracking possible kernel memory leak. - possibly filesystem related X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 07:55:32 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 2006-Aug-02 15:22:26 +1000, Q wrote: >I have made some more progress on identifying this problem. If I drop =20 >to single user mode, and then unmount the volume that houses the =20 >database and the raw data, the accumulated memory is released. When =20 >it did this earlier it dropping from 870M 'active' to 7M =20 >'active' (according to top), just by unmounting the filesystem. I'm sure that's not supposed to happen... You might like to capture the output from 'sysctl vm' and see how it changes over time. If you can identify what particular variable is leaking, it might help locate the problem. --=20 Peter Jeremy --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE0Fpw/opHv/APuIcRAsNkAJ9j7Qwj8kBoL0Tn9MvS+490gJfgjgCfeJVS RzzUJzPqfs0j1HU0tE4KtoE= =SATk -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 10:51:05 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73D016A4E6 for ; Wed, 2 Aug 2006 10:51:05 +0000 (UTC) (envelope-from dave@horsfall.org) Received: from dave.horsfall.org (mrdavi2.lnk.telstra.net [139.130.75.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96BF543D45 for ; Wed, 2 Aug 2006 10:51:01 +0000 (GMT) (envelope-from dave@horsfall.org) Received: from localhost (dave@localhost) by dave.horsfall.org (8.11.4/8.11.4) with ESMTP id k72Aovt25311 for ; Wed, 2 Aug 2006 20:50:58 +1000 (EST) Date: Wed, 2 Aug 2006 20:50:57 +1000 (EST) From: Dave Horsfall To: FreeBSD Hackers In-Reply-To: <20060802073340.GA713@turion.vk2pj.dyndns.org> Message-ID: References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44D04797.1040201@freebsd.org> <20060802073340.GA713@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 10:51:06 -0000 On Wed, 2 Aug 2006, Peter Jeremy wrote: > As a general comment (not addressed to Tim): There _is_ a downside to > sparsifying files. If you take a sparse file and start filling in the > holes, the net result will be very badly fragmented and hence have very > poor sequential I/O performance. If you're never going to update a file > then making it sparse makes sense, if you will be updating it, you will > get better performance by making it non-sparse. Aha! Thanks for that, Peter. -- Dave, wondering why anyone would *not* want sparse files... From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 12:37:55 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2790916A4DD for ; Wed, 2 Aug 2006 12:37:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C2D343D4C for ; Wed, 2 Aug 2006 12:37:50 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: 1rcm8C/pG43AzMhanPJHZA== X-Cloudmark-Score: 0.000000 [] Received: from [193.216.121.206] (HELO [10.0.0.249]) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 253186996 for freebsd-hackers@freebsd.org; Wed, 02 Aug 2006 14:37:47 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 2 Aug 2006 14:37:55 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608021437.55500.hselasky@c2i.net> Subject: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 12:37:55 -0000 Hi, I am currently in the progress of porting "if_aue.c" to my new USB API, and have hit a problem that needs to be solved. The problem is that the USB system sleeps under "miibus_xxx". Questions are: Is this allowed? What locks are held when these functions are called ? Reference: /* MII interface */ DEVMETHOD(miibus_readreg, aue_miibus_readreg), DEVMETHOD(miibus_writereg, aue_miibus_writereg), DEVMETHOD(miibus_statchg, aue_miibus_statchg), The problem with USB devices, is that the read-register process is very slow. It can take up to several milliseconds. And if the device is suddenly detached one has to think about adding exit code everywhere. The solution I see with USB devices is something like this: if (sc->device_gone) { exit mutexes ; kthread_exit(0); } Of course I cannot "kthread_exit()" when the call comes from read/write/ioctl, because there is a stack, that expects a returning call. If the kernel code was objective C, then maybe one could throw an exception or do something alike so that the processor gets out of the USB-read procedure. Solutions: 1) use USB hardware polling, not releasing any mutexes, simply using DELAY(), until read/writes complete. 2) pre-read all read registers regularly. How can I do this with "miibus"? Anyone have any comments? --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 14:54:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11D2F16A4DD; Wed, 2 Aug 2006 14:54:26 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7819D43D72; Wed, 2 Aug 2006 14:54:22 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 11A9C2948D; Wed, 2 Aug 2006 07:54:22 -0700 (PDT) To: Peter Jeremy In-reply-to: Your message of "Wed, 02 Aug 2006 17:33:40 +1000." <20060802073340.GA713@turion.vk2pj.dyndns.org> Date: Wed, 02 Aug 2006 07:54:22 -0700 From: Bakul Shah Message-Id: <20060802145422.11A9C2948D@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org, Tim Kientzle Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 14:54:26 -0000 > As a general comment (not addressed to Tim): There _is_ a downside > to sparsifying files. If you take a sparse file and start filling > in the holes, the net result will be very badly fragmented and hence > have very poor sequential I/O performance. If you're never going to > update a file then making it sparse makes sense, if you will be > updating it, you will get better performance by making it non-sparse. Except for database tables how common is this? And for such files how important is the sequntial I/O performance? For database tables perhaps there is a size range where not making them sparse helps but for really large tables you wouldn't want to fill in the holes. I suspect that making not writing zeroes the default would actually help overall performance. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 15:45:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EBC016A4E8 for ; Wed, 2 Aug 2006 15:45:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2152E43D76 for ; Wed, 2 Aug 2006 15:45:25 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.221] (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id k72FjPjU013620; Wed, 2 Aug 2006 08:45:25 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <44D0C895.8070301@freebsd.org> Date: Wed, 02 Aug 2006 08:45:25 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44D04797.1040201@freebsd.org> <20060802073340.GA713@turion.vk2pj.dyndns.org> In-Reply-To: <20060802073340.GA713@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Sparsifying Files (was Re: [PATCH] adding two new options to 'cp') X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 15:45:34 -0000 Peter Jeremy wrote: > As a general comment (not addressed to Tim): There _is_ a downside > to sparsifying files. How people use (or misuse) such a feature is just not my concern. I've not seen anyone on this thread suggest that such sparsification be done by default, and there are certainly rare situations where sparsification is useful. The tar implementation is about 95% system-independent file format work and 5% system-dependent hole mapping. The mapping process is the easy part. (And therefore, for me, the least interesting part.) A system call could make it accurate, but it's not enough code to fuss over either way. Tim From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 16:54:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202AD16A4DD for ; Wed, 2 Aug 2006 16:54:48 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 6CFB743D6D for ; Wed, 2 Aug 2006 16:54:47 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 13462 invoked by uid 2001); 2 Aug 2006 16:54:46 -0000 Date: Wed, 2 Aug 2006 11:54:46 -0500 From: "Rick C. Petty" To: Peter Jeremy Message-ID: <20060802165446.GD13312@megan.kiwi-computer.com> References: <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> <44CF8F1A.5090506@centtech.com> <20060801174048.GE3413@megan.kiwi-computer.com> <44D04797.1040201@freebsd.org> <20060802073340.GA713@turion.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060802073340.GA713@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 16:54:48 -0000 On Wed, Aug 02, 2006 at 05:33:40PM +1000, Peter Jeremy wrote: > On Tue, 2006-Aug-01 23:35:03 -0700, Tim Kientzle wrote: > >The "cheap" solution is to handle it purely on > >extract: Detect blocks of zeros when restoring > >files and seek over them. > > The downside is that you wind up with a sparse file whether or not you > wanted one. No, you wind up with a sparse file if you specify the "-S" option to tar. If you didn't want one, don't specify the option. > Actually, the only real solution to copying sparse files is to add > a system call that can return a map of holes. This would neatly > address the "needs two passes" problem with tar. You don't need two passes-- you advance the file pointer whenever you detect a block of zeros. Note: care must be taken to only do this for newly-created or otherwise truncated files, otherwise the skip ahead wouldn't work. > As a general comment (not addressed to Tim): There _is_ a downside > to sparsifying files. If you take a sparse file and start filling > in the holes, the net result will be very badly fragmented and hence > have very poor sequential I/O performance. If you're never going to > update a file then making it sparse makes sense, if you will be > updating it, you will get better performance by making it non-sparse. Agreed, with a minor correction/elaboration. By "updating" you mean specifically "updating but not appending". And another note: a good way to defragment a file is to sequentially copy it. (The "best" way is to copy the file to a new filesystem, that way you guarantee the blocks allocated to the file are contiguous.) -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 17:46:26 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA8D16A4DE for ; Wed, 2 Aug 2006 17:46:26 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24EA143D53 for ; Wed, 2 Aug 2006 17:46:25 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (wxklmr@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k72HkIAU004012 for ; Wed, 2 Aug 2006 19:46:24 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k72HkIRO004011; Wed, 2 Aug 2006 19:46:18 +0200 (CEST) (envelope-from olli) Date: Wed, 2 Aug 2006 19:46:18 +0200 (CEST) Message-Id: <200608021746.k72HkIRO004011@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20060802145422.11A9C2948D@mail.bitblocks.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 02 Aug 2006 19:46:24 +0200 (CEST) X-Mailman-Approved-At: Wed, 02 Aug 2006 20:40:27 +0000 Cc: Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 17:46:27 -0000 Bakul Shah wrote: > Peter Jeremy wrote: > > As a general comment (not addressed to Tim): There _is_ a downside > > to sparsifying files. If you take a sparse file and start filling > > in the holes, the net result will be very badly fragmented and hence > > have very poor sequential I/O performance. If you're never going to > > update a file then making it sparse makes sense, if you will be > > updating it, you will get better performance by making it non-sparse. > > Except for database tables how common is this? For example image files of media, e.g. ISO9660 images or images of hard disk partitions. I often have to handle such images, and I certainly do _not_ want them to be sparse. Before someone adds a bogus "sparse file support" option to cp(1), I would rather prefer that someone fixes the existing -R option which currently doesn't handle hard- links correctly. That flaw is documented in the manual page, so it might not count as a "bug", but it's a flaw nevertheless. A lot of people -- even so-called professional admins -- use "cp -Rp" to copy directory hierarchies, and afterwards they wonder why the copy takes up much more space than the original, because all hardlinks have been copied as separate files (if they notice at all). Oh by the way: Linux' option for sparse file handling is "--sparse", and there is no one-letter option (both -s and -S exist, but have nothing to do with sparse files). So there wouldn't be an easy way for FreeBSD to stay compatible with Linux. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 20:59:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C441816A4DF for ; Wed, 2 Aug 2006 20:59:41 +0000 (UTC) (envelope-from prvs=julian=362ec947a@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725D743D4C for ; Wed, 2 Aug 2006 20:59:41 +0000 (GMT) (envelope-from prvs=julian=362ec947a@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 02 Aug 2006 13:59:41 -0700 Message-ID: <44D1123C.6080601@elischer.org> Date: Wed, 02 Aug 2006 13:59:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200608021746.k72HkIRO004011@lurza.secnetix.de> In-Reply-To: <200608021746.k72HkIRO004011@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 20:59:41 -0000 Oliver Fromme wrote: >Bakul Shah wrote: > > Peter Jeremy wrote: > > > As a general comment (not addressed to Tim): There _is_ a downside > > > to sparsifying files. If you take a sparse file and start filling > > > in the holes, the net result will be very badly fragmented and hence > > > have very poor sequential I/O performance. If you're never going to > > > update a file then making it sparse makes sense, if you will be > > > updating it, you will get better performance by making it non-sparse. > > > > Except for database tables how common is this? > >For example image files of media, e.g. ISO9660 images >or images of hard disk partitions. I often have to handle >such images, and I certainly do _not_ want them to be >sparse. > > well then you'd be silly to go to the extra work fo specifying --sparse (or whatever) wouldn't you? >Before someone adds a bogus "sparse file support" option >to cp(1), I would rather prefer that someone fixes the >existing -R option which currently doesn't handle hard- >links correctly. > > It never worked as you suppose. Changing it would be a surprise (though to me a pleasant one) to many. >That flaw is documented in the manual page, so it might >not count as a "bug", but it's a flaw nevertheless. A lot >of people -- even so-called professional admins -- use >"cp -Rp" to copy directory hierarchies, and afterwards >they wonder why the copy takes up much more space than >the original, because all hardlinks have been copied as >separate files (if they notice at all). > > I ALWAYS use find . -depth -print0|cpio -pdmuv0 {dest} or -pdlmuv (poodle-move-0?) if I want links from old to new. because it is guaranteed to do that but cp is not. >Oh by the way: Linux' option for sparse file handling >is "--sparse", and there is no one-letter option (both >-s and -S exist, but have nothing to do with sparse >files). So there wouldn't be an easy way for FreeBSD to >stay compatible with Linux. > >Best regards > Oliver > > > From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 23:14:40 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0050E16A4DA for ; Wed, 2 Aug 2006 23:14:39 +0000 (UTC) (envelope-from psthomso@hotmail.com) Received: from bay0-omc3-s28.bay0.hotmail.com (bay0-omc3-s28.bay0.hotmail.com [65.54.246.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C89E43D78 for ; Wed, 2 Aug 2006 23:14:39 +0000 (GMT) (envelope-from psthomso@hotmail.com) Received: from BAY102-W3 ([64.4.61.103]) by bay0-omc3-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Aug 2006 16:14:39 -0700 X-Originating-IP: [143.182.124.4] X-Originating-Email: [psthomso@hotmail.com] Message-ID: MIME-Version: 1.0 From: "Sean Thomson" To: freebsd-hackers@freebsd.org Date: Wed, 2 Aug 2006 17:14:39 -0600 X-OriginalArrivalTime: 02 Aug 2006 23:14:39.0431 (UTC) FILETIME=[6DB9DD70:01C6B689] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question on SATA Hotplug, NCQ and Port Multiplier support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 23:14:40 -0000 Howdy Folks, =20 I'm trying to find out what the current/future support for SATA hotplug, NC= Q, and Port Multiplier is. Specifically, I'm tied to intel's ICH9 SATA cont= roller and pegged to implement the features if they aren't planned or avail= able. That last part is up in the air, pending what I find out and how long= it'll take. =20 After poking around the mailing list, I found that Soren had mentioned that= he is working on NCQ and I can really only find references to hot plug in = the context of RAID. Is hot plug generally supported for controllers that s= upport it? From experience in another OS, port multiplier was not even on t= he radar as nobody was asking for it, so I'm guessing that the level of int= erest is just as low here. =20 Anyway, any guidance would be greatly appreciated! =20 Thanks! Pat Thomson _________________________________________________________________ Try Live.com - your fast, personalized homepage with all the things you car= e about in one place. http://www.live.com/getstarted= From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 23:21:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADD6616A4F1 for ; Wed, 2 Aug 2006 23:21:43 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB84E43D7D for ; Wed, 2 Aug 2006 23:19:58 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by nf-out-0910.google.com with SMTP id n29so816664nfc for ; Wed, 02 Aug 2006 16:19:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cfIKB5HpdASOfpbRvfoIHimYfQhFTgiZU/zWWz21xuKGfYqdl6JSxKoF1tMOiIiwkw7krPzvkwKPmj5YCONvqWLyXTygMF52NMmu9TPYo/SrQPxQHDv2pBrZpTHfJhe9MAq1ZwY18sjDHg4IEXmm6FZwKoqfhbADahW5CkC49i4= Received: by 10.78.107.8 with SMTP id f8mr553631huc; Wed, 02 Aug 2006 16:19:46 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Wed, 2 Aug 2006 16:19:46 -0700 (PDT) Message-ID: <8e96a0b90608021619o67364f2cx59898ae2bf4db6d1@mail.gmail.com> Date: Thu, 3 Aug 2006 00:19:46 +0100 From: "mal content" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: systrace on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 23:21:43 -0000 I believe this question was asked before (it may have even been asked by me, but I couldn't find record of it): What happened to the effort to port systrace to FreeBSD? The last known information I could find was this: http://techie.devnull.cz/systrace/ Which shows FreeBSD 5.1, at best. I thoroughly enjoy using systrace on OpenBSD, it'd be nice to see this in ports. Unfortunately, I don't trust myself with kernel code, but I'd be happy to help out with the userland stuff if I could. MC From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 23:43:35 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7599216A4DE for ; Wed, 2 Aug 2006 23:43:35 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB45643D49 for ; Wed, 2 Aug 2006 23:43:34 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from [194.192.25.130] (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.13.6/8.13.4) with ESMTP id k72NhXJr083696; Thu, 3 Aug 2006 01:43:33 +0200 (CEST) (envelope-from sos@freebsd.org) Message-ID: <44D138A7.2000607@freebsd.org> Date: Thu, 03 Aug 2006 01:43:35 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: Sean Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-hackers@freebsd.org Subject: Re: Question on SATA Hotplug, NCQ and Port Multiplier support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 23:43:35 -0000 Sean Thomson wrote: > Howdy Folks, > > I'm trying to find out what the current/future support for SATA hotplug, NCQ, and Port Multiplier is. Specifically, I'm tied to intel's ICH9 SATA controller and pegged to implement the features if they aren't planned or available. That last part is up in the air, pending what I find out and how long it'll take. > > After poking around the mailing list, I found that Soren had mentioned that he is working on NCQ and I can really only find references to hot plug in the context of RAID. Is hot plug generally supported for controllers that support it? From experience in another OS, port multiplier was not even on the radar as nobody was asking for it, so I'm guessing that the level of interest is just as low here. > > Anyway, any guidance would be greatly appreciated! > SATA hotplug/hotremoval is implemented for all chips I have access to and that supports it. NCQ is planned and in the works but not for general consumption yet. Port multipliers, well, I have had lots of trouble even locating someone that actually has one, but a couble of days ago I got the word from one of our supporting vendors that an evalution version should be in the mail, more to follow on that as things unfold. Both NCQ and portmultipliers needs support from the chipset, so it depends on those features being present and that I can get docs on how its done. Docs are lacking here as usual, but at least chips that does AHCI (Intel, JMicron and VIA) and Promise chips will be supported. -Søren From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 02:24:23 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D317F16A505 for ; Thu, 3 Aug 2006 02:24:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA2A43D4C for ; Thu, 3 Aug 2006 02:24:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so2274972uge for ; Wed, 02 Aug 2006 19:24:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KrTtpKcSOZTcg2eV5qZcvLF+IdweUD0osOPja6o8nUUnCWS+AL6sAK1OXdjoCevsxHW/ZrX4qC3gNk8Dw5RfOTpD70FriKeyk4jtG9OiFp/UrKMNoYtlKbz5yP/WNJpjfZ3cauS4v57FzlZn0TIN0ctwb4H95PLO/9DCzXw1wAM= Received: by 10.65.114.16 with SMTP id r16mr2320928qbm; Wed, 02 Aug 2006 19:24:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id c12sm4276219nzc.2006.08.02.19.24.19; Wed, 02 Aug 2006 19:24:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k732PU0h049833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Aug 2006 11:25:30 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k732PQBQ049832; Thu, 3 Aug 2006 11:25:26 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 3 Aug 2006 11:25:26 +0900 From: Pyun YongHyeon To: Hans Petter Selasky Message-ID: <20060803022526.GB49195@cdnetworks.co.kr> References: <200608021437.55500.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608021437.55500.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 02:24:24 -0000 On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > Hi, > > I am currently in the progress of porting "if_aue.c" to my new USB API, and > have hit a problem that needs to be solved. The problem is that the USB > system sleeps under "miibus_xxx". Questions are: > > Is this allowed? > > What locks are held when these functions are called ? > > Reference: > > /* MII interface */ > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > AFAIK there is no locks held when MII layer calls above methods but it _is_ called with a driver lock from its ioctl handler. It seems that aue(4) needs to access its register space whilst serving above MII methods. This also means it needs a recursive mutex if it have to serve MII request in the context. So I think the driver should be prepared with protecting the MII methods with its own lock. I've not tried but if you can use MTX_DEF mutex instead of MTX_RECURSE mutex in aue(4) you may be able to sleep on the MII methods. But I think sleeping is not a good way in the MII methods as it would confuse MII layers. See below. Btw, it seems that aue_csr_{read,write} checks sc->aue_dying so it wouldn't block on these functions. But checking sc->aue_dying without a lock held is questionable and setting sc->aue_dying before aue_stop() may result in inconsistent state as all register operations would be nop if sc->aue_dying == 1. > The problem with USB devices, is that the read-register process is very slow. > It can take up to several milliseconds. And if the device is suddenly > detached one has to think about adding exit code everywhere. > > The solution I see with USB devices is something like this: > > if (sc->device_gone) { > > exit mutexes ; > > kthread_exit(0); > } > > Of course I cannot "kthread_exit()" when the call comes from read/write/ioctl, > because there is a stack, that expects a returning call. If the kernel code > was objective C, then maybe one could throw an exception or do something > alike so that the processor gets out of the USB-read procedure. > > > Solutions: > > 1) use USB hardware polling, not releasing any mutexes, simply using DELAY(), > until read/writes complete. > I think you can immediately return from register read/write routines without DELAY() if you know the hardware was gone. > 2) pre-read all read registers regularly. How can I do this with "miibus"? > Because you have a aue_tick() which is called every hz you can cache several registers regularly. Your MII methods can copy the value without accessing registers with proper locks. However, this may confuse MII layers because it needs successive register accesses to read/write media related settings and that defeats use of cached contents of the registers. > > Anyone have any comments? > > --HPS -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 09:33:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5402716A4EA for ; Thu, 3 Aug 2006 09:33:38 +0000 (UTC) (envelope-from freebsd4@fadesa.es) Received: from fuego.fadesa.es (fuego.fadesa.es [195.55.55.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4325943D68 for ; Thu, 3 Aug 2006 09:33:32 +0000 (GMT) (envelope-from freebsd4@fadesa.es) Received: (from root@localhost) by fuego.fadesa.es (8.9.3p2/8.8.8) id LAA11723 for ; Thu, 3 Aug 2006 11:28:26 +0200 Received: from tierra.fadesa.es(195.55.55.7) by fuego.fadesa.es Thu, 3 Aug 06 11:28:13 +0200 Received: from [195.55.55.6] (filemon.fadesa.es [195.55.55.6] (may be forged)) by tierra.fadesa.es (8.9.3p2/8.8.8) with ESMTP id LAA11687 for ; Thu, 3 Aug 2006 11:33:03 +0200 Message-ID: <44D1C2CF.1020403@fadesa.es> Date: Thu, 03 Aug 2006 11:33:03 +0200 From: =?UTF-8?B?Ikpvc8OpIE0uIEZhbmRpw7FvIg==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: gl, es, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <44CF7A28.6020704@fadesa.es> <200608011429.42407.jhb@freebsd.org> In-Reply-To: <200608011429.42407.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Logged: Logged by tierra.fadesa.es as LAA11687 at Thu Aug 3 11:33:03 2006 Subject: Re: ural(4) and panic on sleeping thread (6.1-R) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 09:33:38 -0000 John Baldwin wrote: > In kgdb, do 'proc 783', and then 'where' to get a stack trace of the th= read=20 > that did the wrong thing. (The thread that panics is just an innocent= =20 > victim that bumped into the miscreant.) (kgdb) proc 783 (kgdb) where #0 0xc065f2c7 in sched_switch (td=3D0xc283e900, newtd=3D0xc2535780, flag= s=3D1) at /usr/src/sys/kern/sched_4bsd.c:973 #1 0xc06544e2 in mi_switch (flags=3D1, newtd=3D0x0) at /usr/src/sys/kern/kern_synch.c:336 #2 0xc066c012 in sleepq_switch (wchan=3D0x0) at /usr/src/sys/kern/subr_sleepqueue.c:445 #3 0xc066c102 in sleepq_wait (wchan=3D0xc2cfda00) at /usr/src/sys/kern/subr_sleepqueue.c:525 #4 0xc065422d in msleep (ident=3D0xc2cfda00, mtx=3D0x0, priority=3D76, wmesg=3D0xc08a076d "usbsyn", timo=3D0) at /usr/src/sys/kern/kern_syn= ch.c:209 #5 0xc05ee105 in usbd_transfer (xfer=3D0xc2cfda00) at /usr/src/sys/dev/usb/usbdi.c:344 #6 0xc05ee125 in usbd_sync_transfer (xfer=3D0x0) at /usr/src/sys/dev/usb/usbdi.c:355 #7 0xc05ee901 in usbd_do_request_flags_pipe (dev=3D0xc276cc00, pipe=3D0x= 0, req=3D0xd4bf2a4c, data=3D0xd4bf2a4a, flags=3D0, actlen=3D0x0, timeou= t=3D5000) at /usr/src/sys/dev/usb/usbdi.c:982 #8 0xc05ee8a0 in usbd_do_request_flags (dev=3D0x0, req=3D0xd4bf2a4c, data=3D0xd4bf2a4a, flags=3D0, actlen=3D0x0, timo=3D5000) at /usr/src/sys/dev/usb/usbdi.c:953 #9 0xc05ee87e in usbd_do_request (dev=3D0xc276cc00, req=3D0xd4bf2a4c, data=3D0xd4bf2a4a) at /usr/src/sys/dev/usb/usbdi.c:945 #10 0xc05d7876 in ural_read (sc=3D0xc2768000, reg=3D0) at /usr/src/sys/dev/usb/if_ural.c:1545 #11 0xc05d7a43 in ural_bbp_write (sc=3D0xc2768000, reg=3D22 '\026', val=3D= 8 '\b') at /usr/src/sys/dev/usb/if_ural.c:1619 #12 0xc05d83d5 in ural_bbp_init (sc=3D0xc2768000) at /usr/src/sys/dev/usb/if_ural.c:1998 #13 0xc05d85bd in ural_init (priv=3D0xc2768000) at /usr/src/sys/dev/usb/if_ural.c:2104 #14 0xc05d76ae in ural_ioctl (ifp=3D0xc2796400, cmd=3D2149607696, data=3D0xd4bf2b08 "@1\222=C3=80|-\222=C3=800+=C2=BF=C3=94") at /usr/src/sys/dev/usb/if_ural.c:1470 #15 0xc06b9c54 in if_setflag (ifp=3D0xc2796400, flag=3D0, pflag=3D0, refcount=3D0xc2796444, onswitch=3D0) at /usr/src/sys/net/if.c:1664 From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 09:50:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB87616A4DA for ; Thu, 3 Aug 2006 09:50:34 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from hu-out-0102.google.com (hu-out-0102.google.com [72.14.214.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF9B843D49 for ; Thu, 3 Aug 2006 09:50:33 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by hu-out-0102.google.com with SMTP id 27so1892077hub for ; Thu, 03 Aug 2006 02:50:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=BgRbDJBHQW5EEemEQ5cuJ0Xn/Vdxb/bsaSEGY+O9VQW5dsjLgBL1ZC56Z/uvh9Hp0/SU/pw82mA3dxzUH6nVWUUcUdXV9mfks5CV8YKztXALGlU60N5BfVNVJsASwjdvKNcr0N99sZmltHH1pRpYzTe4/RzHqPSaeWTa7wB4AXE= Received: by 10.49.8.10 with SMTP id l10mr3479947nfi; Thu, 03 Aug 2006 02:48:45 -0700 (PDT) Received: from roadrunner.q.local ( [84.149.79.11]) by mx.gmail.com with ESMTP id c1sm803276nfe.2006.08.03.02.48.45; Thu, 03 Aug 2006 02:48:45 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k739mjs7002018 for ; Thu, 3 Aug 2006 11:48:45 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k72JP8vC069454 for freebsd-hackers@freebsd.org; Wed, 2 Aug 2006 21:25:08 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Wed, 2 Aug 2006 21:25:07 +0200 From: Ulrich Spoerlein To: freebsd-hackers@freebsd.org Message-ID: <20060802192507.GB1136@roadrunner.aventurien.local> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20060731203213.GA75233@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060731203213.GA75233@hades.panopticon> Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 09:50:34 -0000 Dmitry Marakasov wrote: > There are many weighty arguments for relative offsets: > - No confusion (once I did try to dd slice from one place on disk to > another to copy it, and was very surprised when changes made on one > partition appeared on another as well) > - Ability to copy and move slices with simple dd(1). Yes please! I am faced with the problem, that I want to offset my FreeBSD slice about -2GB, so I can use growfs to enlarge it. btw, how hard would it be to write a shrinkfs and perhaps movefs tool? Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 12:44:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B8C016A4E1 for ; Thu, 3 Aug 2006 12:44:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id A741643D5C for ; Thu, 3 Aug 2006 12:44:40 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from [193.217.134.95] (HELO [10.0.0.249]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 247854203; Thu, 03 Aug 2006 14:44:38 +0200 From: Hans Petter Selasky To: pyunyh@gmail.com Date: Thu, 3 Aug 2006 14:44:46 +0200 User-Agent: KMail/1.7 References: <200608021437.55500.hselasky@c2i.net> <20060803022526.GB49195@cdnetworks.co.kr> In-Reply-To: <20060803022526.GB49195@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200608031444.47566.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:44:42 -0000 On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote: > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > > Hi, > > > > I am currently in the progress of porting "if_aue.c" to my new USB API, > > and have hit a problem that needs to be solved. The problem is that the > > USB system sleeps under "miibus_xxx". Questions are: > > > > Is this allowed? > > > > What locks are held when these functions are called ? > > > > Reference: > > > > /* MII interface */ > > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > > AFAIK there is no locks held when MII layer calls above methods but > it _is_ called with a driver lock from its ioctl handler. Ok. > It seems that aue(4) needs to access its register space whilst > serving above MII methods.=20 =2E.. > But I think sleeping is not a good way in the MII methods as it would > confuse MII layers. See below. > Yes, "mii_tick()" can suddenly be executed while "mii_mediachg()" is being= =20 executed. But can I assume that everytime something inside the "mii" layer is called,= it=20 goes through my driver, "if_aue". =46rom what I can see, there are only three entry points into the MII layer: mii_mediachg(mii); mii_pollstat(mii); mii_tick(mii); The idea is to call these from a separate thread, that can sleep. But then= =20 comes the next question: Can I safely "kthread_exit" from the "miibus_xxx()" functions ? I can proba= bly=20 find the answer by looking at the sourcecode, but maybe someone already=20 knows? /* MII interface */ DEVMETHOD(miibus_readreg, aue_miibus_readreg), DEVMETHOD(miibus_writereg, aue_miibus_writereg), DEVMETHOD(miibus_statchg, aue_miibus_statchg), > > > I think you can immediately return from register read/write routines > without DELAY() if you know the hardware was gone. > > > 2) pre-read all read registers regularly. How can I do this with > > "miibus"? > > Because you have a aue_tick() which is called every hz you can cache > several registers regularly. Your MII methods can copy the value > without accessing registers with proper locks. However, this may > confuse MII layers because it needs successive register accesses to > read/write media related settings and that defeats use of cached > contents of the registers. I just have to cache the result: ifmr->ifm_active =3D mii->mii_media_active; ifmr->ifm_status =3D mii->mii_media_status; Thanks for any comments. =2D-HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 12:42:42 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ABB916A4DD for ; Thu, 3 Aug 2006 12:42:42 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C9443D45 for ; Thu, 3 Aug 2006 12:42:41 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dazwtc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k73CgXrs037545 for ; Thu, 3 Aug 2006 14:42:39 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k73CgXAk037544; Thu, 3 Aug 2006 14:42:33 +0200 (CEST) (envelope-from olli) Date: Thu, 3 Aug 2006 14:42:33 +0200 (CEST) Message-Id: <200608031242.k73CgXAk037544@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <44D1123C.6080601@elischer.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 03 Aug 2006 14:42:39 +0200 (CEST) X-Mailman-Approved-At: Thu, 03 Aug 2006 12:58:49 +0000 Cc: Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:42:42 -0000 Julian Elischer wrote: > Oliver Fromme wrote: > > Bakul Shah wrote: > > > Peter Jeremy wrote: > > > > As a general comment (not addressed to Tim): There _is_ a downside > > > > to sparsifying files. If you take a sparse file and start filling > > > > in the holes, the net result will be very badly fragmented and hence > > > > have very poor sequential I/O performance. If you're never going to > > > > update a file then making it sparse makes sense, if you will be > > > > updating it, you will get better performance by making it non-sparse. > > > > > > Except for database tables how common is this? > > > > For example image files of media, e.g. ISO9660 images > > or images of hard disk partitions. I often have to handle > > such images, and I certainly do _not_ want them to be > > sparse. > > well then you'd be silly to go to the extra work fo specifying --sparse > (or whatever) wouldn't you? Sure, in that case I wouldn't specify it (and I hope nobody intends to make it the default, as has been mentioned in this thread). > > Before someone adds a bogus "sparse file support" option > > to cp(1), I would rather prefer that someone fixes the > > existing -R option which currently doesn't handle hard- > > links correctly. > > It never worked as you suppose. I know. Probably because nobody cared to implement it, and there are other tools (cpio) that can do that job. > Changing it would be a surprise > (though to me a pleasant one) to many. I guess most users of cp(1) aren't aware of the flaw. > > That flaw is documented in the manual page, so it might > > not count as a "bug", but it's a flaw nevertheless. A lot > > of people -- even so-called professional admins -- use > > "cp -Rp" to copy directory hierarchies, and afterwards > > they wonder why the copy takes up much more space than > > the original, because all hardlinks have been copied as > > separate files (if they notice at all). > > I ALWAYS use find . -depth -print0|cpio -pdmuv0 {dest} > or -pdlmuv (poodle-move-0?) if I want links from old to new. because it > is guaranteed to do that but cp is not. Yes, exactly. I use: find -d . | cpio -dump /dest/dir (copy file hierarchy) or: find -d . | cpio -dumpl /dest/dir (link file hierarchy) "-dump" is pretty easy to remember. Of course, if there might be names with whitespaces, I add the -0 option, too. I've created aliases "hcp" (hierarchy copy) and "hln" (hierarchy link) to save typing. That's even shorter than "cp -al". ;-) For bourne shells (sh, zsh, bash), these functions work fine: hcp() { local dst dst=$(realpath "$2") && ( cd -- "$1" && \ find -d . -print0 | cpio -dump0 "$dst" ) } hln() { local dst dst=$(realpath "$2") && ( cd -- "$1" && \ find -d . -print0 | cpio -dumpl0 "$dst" ) } The hcp function _does_ copy hardlinks correctly (unlike cp), and cpio supports the --sparse option to create sparse files, so you can add that if you want. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 12:48:31 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E28616A4DD for ; Thu, 3 Aug 2006 12:48:31 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 789F243D46 for ; Thu, 3 Aug 2006 12:48:30 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (srqxab@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k73CmORu037729 for ; Thu, 3 Aug 2006 14:48:29 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k73CmOws037728; Thu, 3 Aug 2006 14:48:24 +0200 (CEST) (envelope-from olli) Date: Thu, 3 Aug 2006 14:48:24 +0200 (CEST) Message-Id: <200608031248.k73CmOws037728@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <20060802192507.GB1136@roadrunner.aventurien.local> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 03 Aug 2006 14:48:29 +0200 (CEST) X-Mailman-Approved-At: Thu, 03 Aug 2006 13:03:44 +0000 Cc: Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:48:31 -0000 Ulrich Spoerlein wrote: > btw, how hard would it be to write a shrinkfs and perhaps movefs tool? movefs shouldn't be very difficult, but shrinkfs is more complex, because you have to relocate files and metadata within the filesystem. The shrink operation can fail if there isn't enough space in the new size for all data (and you need to take into account that not only data space is reduced, but also the number of inodes). Snap- shots will make it even more complicated. But then again, harddisks tend to get bigger, so there is probably not much need for a shrinkfs tool. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. We're sysadmins. To us, data is a protocol-overhead. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 13:02:29 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E8BD16A4DE for ; Thu, 3 Aug 2006 13:02:29 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D104943D46 for ; Thu, 3 Aug 2006 13:02:27 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DC81.dip.t-dialin.net [84.165.220.129]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k73Cmaca041054; Thu, 3 Aug 2006 14:48:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k73D2Q1D077335; Thu, 3 Aug 2006 15:02:27 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Thu, 3 Aug 2006 15:04:07 +0200 From: Alexander Leidinger To: Ulrich Spoerlein Message-ID: <20060803150407.4fc4d53a@Magellan.Leidinger.net> In-Reply-To: <20060802192507.GB1136@roadrunner.aventurien.local> References: <20060731203213.GA75233@hades.panopticon> <20060802192507.GB1136@roadrunner.aventurien.local> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Thu, 03 Aug 2006 13:05:55 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 13:02:29 -0000 Quoting Ulrich Spoerlein (Wed, 2 Aug 2006 21:25:07 +0200): > btw, how hard would it be to write a shrinkfs and perhaps movefs tool? I've seen a commit to perforce which talked about shrinking an FS... I don't remember where. Bye, Alexander. -- That would be because the software doesn't work. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 14:35:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C134016A4E9 for ; Thu, 3 Aug 2006 14:35:06 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7141C43D53 for ; Thu, 3 Aug 2006 14:35:05 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by nz-out-0102.google.com with SMTP id 13so426727nzn for ; Thu, 03 Aug 2006 07:35:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=CtxRVwAqkXT6ENe9QG9lyVNS7HSfvXOqLMSwE3/CasMnaqlEcYfvXA32YixykcBaewQ1snHzSUrXv66eAqS5ElE1SiKRE2HQtqAVss6v2lyv0XGuh9MgN7N4Vv/npRz93GlDmnZ9n5bTcS49hyilnPA0oF7NSIC5+I9Qr6pmqow= Received: by 10.35.40.10 with SMTP id s10mr3437210pyj; Thu, 03 Aug 2006 07:35:04 -0700 (PDT) Received: by 10.35.112.18 with HTTP; Thu, 3 Aug 2006 07:35:04 -0700 (PDT) Message-ID: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> Date: Thu, 3 Aug 2006 15:35:04 +0100 From: "Joao Barros" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_148041_22325824.1154615704773" Cc: Gleb Smirnoff Subject: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 14:35:06 -0000 ------=_Part_148041_22325824.1154615704773 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I recently switched ISPs which in turn led me from a cablemodem to an ADSL modem. After setting PPPoE up I started noticing this messages in the daily run outputs that that nice guy Charlie root sends me at 3am: Aug 3 08:24:54 ultra5 kernel: session in wrong state I was a bit suspicious of anything PPPoE related and a little search confirmed that, pointing directly at ng_pppoe.c Being this a cryptic message to say the least and to probably save someone some time when presented with this message I attach a patch that adds the header "pppoe:" in every printf that didn't have it, making it consistent with the rest of the file. I also noticed this message appears right before the ISP closes the connection due to time limit. I'm CCing those I see were the last ones to commit to this file and will file a PR if asked to. -- Joao Barros ------=_Part_148041_22325824.1154615704773 Content-Type: application/octet-stream; name=ng_pppoe.c.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_eqf89nw3 Content-Disposition: attachment; filename="ng_pppoe.c.patch" LS0tIG5nX3BwcG9lLmMub3JpZ2luYWwJVGh1IEF1ZyAwMyAxNTowOTo1MSAyMDA2CisrKyBuZ19w cHBvZS5jCVRodSBBdWcgMDMgMTU6MTY6MTUgMjAwNgpAQCAtMTEwOCArMTEwOCBAQAotCQkJCXBy aW50ZigiY291bGRuJ3QgbV9wdWxsdXBcbiIpOworCQkJCXByaW50ZigicHBwb2U6IGNvdWxkbid0 IG1fcHVsbHVwXG4iKTsKQEAgLTExMjcgKzExMjcgQEAKLQkJCQkJCXByaW50ZigiY291bGRuJ3Qg bV9wdWxsdXBcbiIpOworCQkJCQkJcHJpbnRmKCJwcHBvZTogY291bGRuJ3QgbV9wdWxsdXBcbiIp OwpAQCAtMTE1MCArMTE1MCBAQAotCQkJCQlwcmludGYoInBhY2tldCBmcmFnbWVudGVkXG4iKTsK KwkJCQkJcHJpbnRmKCJwcHBvZTogcGFja2V0IGZyYWdtZW50ZWRcbiIpOwpAQCAtMTIwNyArMTIw NyBAQAotCQkJCQlwcmludGYoIm5vIGhvc3QgdW5pcXVlIGZpZWxkXG4iKTsKKwkJCQkJcHJpbnRm KCJwcHBvZTogbm8gaG9zdCB1bmlxdWUgZmllbGRcbiIpOwpAQCAtMTIxMyArMTIxMyBAQAotCQkJ CQlwcmludGYoIm5vIG1hdGNoaW5nIHNlc3Npb25cbiIpOworCQkJCQlwcmludGYoInBwcG9lOiBu byBtYXRjaGluZyBzZXNzaW9uXG4iKTsKQEAgLTEyMjMgKzEyMjMgQEAKLQkJCQkJcHJpbnRmKCJz ZXNzaW9uIGluIHdyb25nIHN0YXRlXG4iKTsKKwkJCQkJcHJpbnRmKCJwcHBvZTogc2Vzc2lvbiBp biB3cm9uZyBzdGF0ZVxuIik7Cg== ------=_Part_148041_22325824.1154615704773-- From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 14:52:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8AEB16A4DA for ; Thu, 3 Aug 2006 14:52:16 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 580AC43D4C for ; Thu, 3 Aug 2006 14:52:16 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 867CE20A5 for ; Thu, 3 Aug 2006 16:52:11 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tim.des.no Received: from xps.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 150832085 for ; Thu, 3 Aug 2006 16:52:11 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id E227633C28; Thu, 3 Aug 2006 16:52:10 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: freebsd-hackers@freebsd.org References: <20060731203213.GA75233@hades.panopticon> Date: Thu, 03 Aug 2006 16:52:10 +0200 In-Reply-To: <20060731203213.GA75233@hades.panopticon> (Dmitry Marakasov's message of "Tue, 1 Aug 2006 00:32:13 +0400") Message-ID: <864pwtoorp.fsf@xps.des.no> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 14:52:16 -0000 Dmitry Marakasov writes: > Recent `disklabel differences FreeBSD, DragonFly' thread gave me a > thought - why do we have absolute offsets in disklabel? We don't, AFAIK. Since the transition to GEOM, the offsets are relative to the start of the containing provider. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 22:01:01 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2D0216A4DA; Thu, 3 Aug 2006 22:01:01 +0000 (UTC) (envelope-from psthomso@hotmail.com) Received: from bay0-omc3-s13.bay0.hotmail.com (bay0-omc3-s13.bay0.hotmail.com [65.54.246.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6523E43D45; Thu, 3 Aug 2006 22:01:01 +0000 (GMT) (envelope-from psthomso@hotmail.com) Received: from BAY102-W6 ([64.4.61.106]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Aug 2006 15:01:01 -0700 X-Originating-IP: [143.182.124.3] X-Originating-Email: [psthomso@hotmail.com] Message-ID: MIME-Version: 1.0 From: "Sean Thomson" To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 3 Aug 2006 16:01:01 -0600 X-OriginalArrivalTime: 03 Aug 2006 22:01:01.0376 (UTC) FILETIME=[4EC5EC00:01C6B748] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: RE: Question on SATA Hotplug, NCQ and Port Multiplier support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 22:01:01 -0000 > Sean Thomson wrote:> > Howdy Folks,> > > > I'm trying to find out what t= he current/future support for SATA hotplug,=20 > > NCQ, and Port Multiplier is. Specifically, I'm tied to intel's ICH9 SAT= A controller=20 > >and pegged to implement the features if they aren't planned or available= . That=20 > > last part is up in the air, pending what I find out and how long it'll = take.> > > > After poking around the mailing list, I found that Soren had = mentioned=20 > > that he is working on NCQ and I can really only find references to > > hot plug in the context of RAID. Is hot plug generally supported for=20 > > controllers that support it? From experience in another OS, port=20 > >multiplier was not even on the radar as nobody was asking for=20 > > it, so I'm guessing that the level of interest is just as low here.> > = > > Anyway, any guidance would be greatly appreciated!> > > SATA hotplug= /hotremoval is implemented for all chips I have access to > and that suppor= ts it.> > NCQ is planned and in the works but not for general consumption y= et.> Port multipliers, well, I have had lots of trouble even locating someo= ne > that actually has one, but a couble of days ago I got the word from on= e > of our supporting vendors that an evalution version should be in the > = mail, more to follow on that as things unfold.> > Both NCQ and portmultipli= ers needs support from the chipset, so it > depends on those features being= present and that I can get docs on how > its done. Docs are lacking here a= s usual, but at least chips that does > AHCI (Intel, JMicron and VIA) and P= romise chips will be supported.> > -S=F8ren> > =20 Thanks S=F8ren, I appreciate the response. The chipset is an intel AHCI chi= pset,=20 so its covered. =20 As far as the port multiplier is concerned, I found one by Silicon Image=20 (CGS-3726-A1). It should work. If you don't get one from your supporting vendor, let me know and I'll see if I can get the one I just mentioned =20 thanks! Sean _________________________________________________________________ Try Live.com: where your online world comes together - with news, sports, w= eather, and much more. http://www.live.com/getstarted= From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 20:07:02 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 862D216A4F5 for ; Thu, 3 Aug 2006 20:07:02 +0000 (UTC) (envelope-from rik@inse.ru) Received: from mail.inse.ru (inse.ru [144.206.128.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F7BE43D76 for ; Thu, 3 Aug 2006 20:07:01 +0000 (GMT) (envelope-from rik@inse.ru) Received: from [127.0.0.1] (www.inse.ru [144.206.128.1]) by mail.inse.ru (Postfix) with ESMTP id 9924833C66 for ; Fri, 4 Aug 2006 00:06:59 +0400 (MSD) Message-ID: <44D2590A.7020100@inse.ru> Date: Fri, 04 Aug 2006 00:14:02 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.12) Gecko/20060103 ASPLinux/1.7.12-1.5.1.1asp X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Aug 2006 23:24:24 +0000 Cc: Subject: [Fwd: bsdlabel: potential bug and/or question about it] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 20:07:02 -0000 Forwarded to hackers since no reply on geom@ Hi, I am trying to understand filesystem structure to extract data from half-broken hard drive and I've started to read sources of bsdlabel (if someone know any articles about bsdlabel and/or ufs2 structure please let me know). My question is what for mbroffset and what is it? I have only some surmises about it, but it looks that this code could lead to filesystem corruption. But I hope I am wrong :-) http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb.cgi/src/sbin/bsdlabel/bsdlabel.c.diff?r1=1.89&r2=1.90 My train of thought was that in case we have the mbroffset not equal to offset of c (raw) partition we wouldn't substruct mbroffset from all offsets. Lets also assume that this case we meet while we started to edit such slice. We've finished editing and started to write results. In case of write we would add mbroffset unconditionally and thus we get wrong offsets and corrupted partition table. Best regards, rik _______________________________________________ freebsd-geom@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 00:08:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFCFF16A4E5 for ; Fri, 4 Aug 2006 00:08:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B1643D5D for ; Fri, 4 Aug 2006 00:08:21 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so20841pyb for ; Thu, 03 Aug 2006 17:08:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=jE42oFzV9UTiiQige277CcaEaVrSjWJvtjbLpPqfDeYQCVO88aA6WMUdPwjnKLWrBpaaO4XU1n0D2pTOuHBYo9K6PCy6KQi7Vxj2X55RdWwz9NzOxu9VxriuDAN9pOyvcpaaFbka9DPtGtOXNgKIS0smH3hLUO/88/Ji9Yj05Gk= Received: by 10.35.38.17 with SMTP id q17mr4011762pyj; Thu, 03 Aug 2006 17:08:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 64sm78081wra.2006.08.03.17.08.18; Thu, 03 Aug 2006 17:08:19 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7409eYD053438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 09:09:40 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7409dh5053437; Fri, 4 Aug 2006 09:09:39 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 4 Aug 2006 09:09:39 +0900 From: Pyun YongHyeon To: Hans Petter Selasky Message-ID: <20060804000939.GA53215@cdnetworks.co.kr> References: <200608021437.55500.hselasky@c2i.net> <20060803022526.GB49195@cdnetworks.co.kr> <200608031444.47566.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608031444.47566.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 00:08:23 -0000 On Thu, Aug 03, 2006 at 02:44:46PM +0200, Hans Petter Selasky wrote: > On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote: > > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > > > Hi, > > > > > > I am currently in the progress of porting "if_aue.c" to my new USB API, > > > and have hit a problem that needs to be solved. The problem is that the > > > USB system sleeps under "miibus_xxx". Questions are: > > > > > > Is this allowed? > > > > > > What locks are held when these functions are called ? > > > > > > Reference: > > > > > > /* MII interface */ > > > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > > > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > > > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > > > > AFAIK there is no locks held when MII layer calls above methods but > > it _is_ called with a driver lock from its ioctl handler. > > Ok. > > > It seems that aue(4) needs to access its register space whilst > > serving above MII methods. > > ... > > > But I think sleeping is not a good way in the MII methods as it would > > confuse MII layers. See below. > > > > Yes, "mii_tick()" can suddenly be executed while "mii_mediachg()" is being > executed. > > But can I assume that everytime something inside the "mii" layer is called, it > goes through my driver, "if_aue". > > >From what I can see, there are only three entry points into the MII layer: > > mii_mediachg(mii); > mii_pollstat(mii); > mii_tick(mii); > > The idea is to call these from a separate thread, that can sleep. But then > comes the next question: > > Can I safely "kthread_exit" from the "miibus_xxx()" functions ? I can probably > find the answer by looking at the sourcecode, but maybe someone already > knows? > > /* MII interface */ > DEVMETHOD(miibus_readreg, aue_miibus_readreg), > DEVMETHOD(miibus_writereg, aue_miibus_writereg), > DEVMETHOD(miibus_statchg, aue_miibus_statchg), > I can't sure why you need to invoke kthread_exit(9) in aue_miibus_xxx. If you want to kill the kernel thread in aue_miibus_xxx you can simply send a termination message to kernel thread. Your kernel thread can decide when it should terminate if it recevied a termination message. Invoking mii_mediachg/mii_tick will end up with calling miibus_xxx to to read/write PHY registers from MII layer. So I think you still need to handle PHY read/write operations in aue_miibus_xxx. If the PHY operation was failed due to removal of hardware it could simply return fake value and send a message to terminate the kernel thread. -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 00:14:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B412116A4E1; Fri, 4 Aug 2006 00:14:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3400543D45; Fri, 4 Aug 2006 00:14:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k740CuYv084256; Thu, 3 Aug 2006 18:12:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Aug 2006 15:33:37 -0600 (MDT) Message-Id: <20060802.153337.-432837969.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200607311638.15298.jhb@freebsd.org> References: <44CE4AD0.60409@centtech.com> <17614.20892.315747.115331@bhuda.mired.org> <200607311638.15298.jhb@freebsd.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 03 Aug 2006 18:13:04 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, mwm-keyword-freebsdhackers2.e313df@mired.org, dougb@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 00:14:44 -0000 In message: <200607311638.15298.jhb@freebsd.org> John Baldwin writes: : On Monday 31 July 2006 14:53, Mike Meyer wrote: : > Which points up an obvious question: other than compatibility with : > Linux, is there any reason this functionaly shouldn't be added to the : > ln command instead? : : Umm, because ln doesn't copy hierarchies? Using that argument we'd remove : support for hard-links from tar and cpio. I think cp -a is harmless (just as : I use rsync -a all the time rather than rsync -rlptgoD) and cp -l is probably : useful. Really, it is more intuitive to be able to copy a hierarchy using : the 'copy' command (cp) directly rather than a convoluted pair of find | : cpio. In this case I think you might be overly paranoid. :) I tend to agree here. The bloat is minimal, and if there's ever a need to create minimal versions of cp, et al, at that time we can provide ways to optimize for space. We've done it in the past, and as we're pushing down into the embedded space, we may need to do it again. But we may not... Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 10:55:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C34B16A4E0 for ; Fri, 4 Aug 2006 10:55:12 +0000 (UTC) (envelope-from mario.lobo@ipad.com.br) Received: from recife.ipad.com.br (recife.ipadnet.com.br [200.249.204.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F6CF43D5C for ; Fri, 4 Aug 2006 10:55:09 +0000 (GMT) (envelope-from mario.lobo@ipad.com.br) Received: from lobo.ipad.com.br ([192.168.64.1]) (authenticated bits=0) by recife.ipad.com.br (8.12.8/8.12.8) with ESMTP id k74BLfZX000544 for ; Fri, 4 Aug 2006 08:21:41 -0300 From: Mario Lobo Organization: IPAD To: freebsd-hackers@freebsd.org Date: Fri, 4 Aug 2006 07:59:48 +0000 User-Agent: KMail/1.9.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608040759.49390.mario.lobo@ipad.com.br> Subject: getting interface MAC addr from C X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 10:55:12 -0000 Hi; Would anyone have a tip on how to get the MAC from a C program? I tried: struct ifreq ifreq; unsigned char *hw; strcpy(ifreq.ifr_name, "rl0"); ioctl(fd, SIOCGIFMAC, &ifreq); hw = ifreq.ifr_ifru.ifru_data; ???? but i don't know if this is right or, if it is, where to get the MAC from the structure. I doesn't issue any error compiling or running though. In linux i used: struct ifreq ifreq; unsigned char *hw; strcpy(ifreq.ifr_name, "rl0"); ioctl(fd, SIOCGIFHWADDR, &ifreq); hw = ifreq.ifr_hwaddr.sa_data; Thanks, Mario From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 11:13:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BAB316A4DE for ; Fri, 4 Aug 2006 11:13:33 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DC2B43D49 for ; Fri, 4 Aug 2006 11:13:31 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5ECE0.dip.t-dialin.net [84.165.236.224]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k74AxVXi047326; Fri, 4 Aug 2006 12:59:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k74BDYqm066864; Fri, 4 Aug 2006 13:13:34 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Fri, 4 Aug 2006 13:15:17 +0200 From: Alexander Leidinger To: freebsd-hackers@freebsd.org Message-ID: <20060804131517.4b43311c@Magellan.Leidinger.net> In-Reply-To: <200608031248.k73CmOws037728@lurza.secnetix.de> References: <20060802192507.GB1136@roadrunner.aventurien.local> <200608031248.k73CmOws037728@lurza.secnetix.de> X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Fri, 04 Aug 2006 11:38:49 +0000 Cc: olli@lurza.secnetix.de Subject: Re: absolute vs. relative offsets in disklabel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 11:13:33 -0000 Quoting Oliver Fromme (Thu, 3 Aug 2006 14:48:24 +0200 (CEST)): > But then again, harddisks tend to get bigger, so there is > probably not much need for a shrinkfs tool. Sometimes it's not an availability decision... think about EMC, disk pools and changing requirements in an environment where the decision makers know enough to use their desktop system. Bye, Alexander. -- "Maybe you can't understand this, but I finally found what I need to be happy, and it's not friends, it's things." -Fry http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 12:43:57 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E96C516A4DA for ; Fri, 4 Aug 2006 12:43:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C9FC43D45 for ; Fri, 4 Aug 2006 12:43:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C2B2046D22; Fri, 4 Aug 2006 08:43:56 -0400 (EDT) Date: Fri, 4 Aug 2006 13:43:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mario Lobo In-Reply-To: <200608040759.49390.mario.lobo@ipad.com.br> Message-ID: <20060804134258.R56045@fledge.watson.org> References: <200608040759.49390.mario.lobo@ipad.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: getting interface MAC addr from C X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 12:43:58 -0000 On Fri, 4 Aug 2006, Mario Lobo wrote: > Would anyone have a tip on how to get the MAC from a C program? > > I tried: > > struct ifreq ifreq; > unsigned char *hw; > > strcpy(ifreq.ifr_name, "rl0"); > ioctl(fd, SIOCGIFMAC, &ifreq); > hw = ifreq.ifr_ifru.ifru_data; ???? > > but i don't know if this is right or, if it is, where to get the MAC from > the structure. I doesn't issue any error compiling or running though. Usually the general purpose interface recommended for inspecting interface information is getifaddrs(), which will build a userspace list of interfaces and their various addresses, including link-layer addresses. Something like the above will work, but may not be preferred. Robert N M Watson Computer Laboratory University of Cambridge > > In linux i used: > > struct ifreq ifreq; > unsigned char *hw; > > strcpy(ifreq.ifr_name, "rl0"); > ioctl(fd, SIOCGIFHWADDR, &ifreq); > hw = ifreq.ifr_hwaddr.sa_data; > > Thanks, > > Mario > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 15:03:06 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5244216A4E5; Fri, 4 Aug 2006 15:03:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EF9043D46; Fri, 4 Aug 2006 15:03:05 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k74F33eL036781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 19:03:03 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k74F335Q036780; Fri, 4 Aug 2006 19:03:03 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 4 Aug 2006 19:03:02 +0400 From: Gleb Smirnoff To: Joao Barros Message-ID: <20060804150302.GD96644@cell.sick.ru> References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BghK6+krpKHjj+jk" Content-Disposition: inline In-Reply-To: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> User-Agent: Mutt/1.5.6i Cc: freebsd-hackers@FreeBSD.org, Julian Elischer Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 15:03:06 -0000 --BghK6+krpKHjj+jk Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: J> I recently switched ISPs which in turn led me from a cablemodem to an J> ADSL modem. J> After setting PPPoE up I started noticing this messages in the daily J> run outputs that that nice guy Charlie root sends me at 3am: J> J> Aug 3 08:24:54 ultra5 kernel: session in wrong state J> J> I was a bit suspicious of anything PPPoE related and a little search J> confirmed that, pointing directly at ng_pppoe.c J> Being this a cryptic message to say the least and to probably save J> someone some time when presented with this message I attach a patch J> that adds the header "pppoe:" in every printf that didn't have it, J> making it consistent with the rest of the file. J> I also noticed this message appears right before the ISP closes the J> connection due to time limit. J> J> I'm CCing those I see were the last ones to commit to this file and J> will file a PR if asked to. I've attached a patch that cleans a bit logging in ng_pppoe. It changes all printf(9) to log(9). The latter is better since it spams console less, if event occurs many times per second. Also I've made the messages more clear - prepended node ID where possible, function name when it starts with ng_pppoe, or just "ng_pppoe". Can you please try out this patch and tell whether you like it. If you do I will commit it soon. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --BghK6+krpKHjj+jk Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_pppoe.log.diff" Index: ng_pppoe.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v retrieving revision 1.78 diff -u -p -r1.78 ng_pppoe.c --- ng_pppoe.c 27 Jan 2006 10:56:22 -0000 1.78 +++ ng_pppoe.c 4 Aug 2006 15:00:30 -0000 @@ -48,6 +48,7 @@ #include #include #include +#include #include #include @@ -261,7 +262,7 @@ union uniq { #define LEAVE(x) do { error = x; goto quit; } while(0) static void pppoe_start(sessp sp); -static void sendpacket(sessp sp); +static void ng_pppoe_sendpacket(sessp sp); static void pppoe_ticker(node_p node, hook_p hook, void *arg1, int arg2); static const struct pppoe_tag *scan_tags(sessp sp, const struct pppoe_hdr* ph); @@ -383,7 +384,8 @@ insert_tag(sessp sp, const struct pppoe_ if ((i = neg->numtags++) < NUMTAGS) { neg->tags[i] = tp; } else { - printf("pppoe: asked to add too many tags to packet\n"); + log(LOG_NOTICE, "ng_pppoe: asked to add too many tags to " + "packet\n"); neg->numtags--; } } @@ -406,7 +408,7 @@ make_packet(sessp sp) { uint16_t length = 0; KASSERT((sp->neg != NULL) && (sp->neg->m != NULL), - ("%s: make_packet called from wrong state", __func__)); + ("%s: called from wrong state", __func__)); CTR2(KTR_NET, "%20s: called %d", __func__, sp->Session_ID); dp = (char *)wh->ph.tag; @@ -415,7 +417,7 @@ make_packet(sessp sp) { tag++, count++) { tlen = ntohs((*tag)->tag_len) + sizeof(**tag); if ((length + tlen) > (ETHER_MAX_LEN - 4 - sizeof(*wh))) { - printf("pppoe: tags too long\n"); + log(LOG_NOTICE, "ng_pppoe: tags too long\n"); sp->neg->numtags = count; break; /* XXX chop off what's too long */ } @@ -714,18 +716,21 @@ ng_pppoe_rcvmsg(node_p node, item_p item case NGM_PPPOE_SERVICE: ourmsg = (struct ngpppoe_init_data *)msg->data; if (msg->header.arglen < sizeof(*ourmsg)) { - printf("pppoe: init data too small\n"); + log(LOG_ERR, "ng_pppoe[%x]: init data too " + "small\n", node->nd_ID); LEAVE(EMSGSIZE); } if (msg->header.arglen - sizeof(*ourmsg) > PPPOE_SERVICE_NAME_SIZE) { - printf("pppoe_rcvmsg: service name too big"); + log(LOG_ERR, "ng_pppoe[%x]: service name " + "too big\n", node->nd_ID); LEAVE(EMSGSIZE); } if (msg->header.arglen - sizeof(*ourmsg) < ourmsg->data_len) { - printf("pppoe: init data has bad length," - " %d should be %zd\n", ourmsg->data_len, + log(LOG_ERR, "ng_pppoe[%x]: init data has bad " + "length, %d should be %zd\n", node->nd_ID, + ourmsg->data_len, msg->header.arglen - sizeof (*ourmsg)); LEAVE(EMSGSIZE); } @@ -767,7 +772,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item break; if (sp->state != PPPOE_SNONE) { - printf("pppoe: Session already active\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: Session already " + "active\n", node->nd_ID); LEAVE(EISCONN); } @@ -882,7 +888,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item * If you do it twice you just overwrite. */ if (sp->state != PPPOE_PRIMED) { - printf("pppoe: Session not primed\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: session not " + "primed\n", node->nd_ID); LEAVE(EISCONN); } neg = sp->neg; @@ -1012,7 +1019,7 @@ pppoe_start(sessp sp) insert_tag(sp, &uniqtag.hdr); insert_tag(sp, &sp->neg->service.hdr); make_packet(sp); - sendpacket(sp); + ng_pppoe_sendpacket(sp); } static int @@ -1105,7 +1112,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite if( m->m_len < sizeof(*wh)) { m = m_pullup(m, sizeof(*wh)); /* Checks length */ if (m == NULL) { - printf("couldn't m_pullup\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: couldn't " + "m_pullup(wh)\n", node->nd_ID); LEAVE(ENOBUFS); } } @@ -1124,7 +1132,10 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite if( m->m_len < m->m_pkthdr.len) { m = m_pullup(m, m->m_pkthdr.len); if (m == NULL) { - printf("couldn't m_pullup\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: " + "couldn't " + "m_pullup(pkthdr)\n", + node->nd_ID); LEAVE(ENOBUFS); } } @@ -1147,7 +1158,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite } } if (m == NULL) { - printf("packet fragmented\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: packet " + "fragmented\n", node->nd_ID); LEAVE(EMSGSIZE); } } @@ -1204,13 +1216,15 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite utag = get_tag(ph, PTT_HOST_UNIQ); if ((utag == NULL) || (ntohs(utag->tag_len) != sizeof(sp))) { - printf("no host unique field\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: no host " + "unique field\n", node->nd_ID); LEAVE(ENETUNREACH); } sendhook = pppoe_finduniq(node, utag); if (sendhook == NULL) { - printf("no matching session\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: no " + "matching session\n", node->nd_ID); LEAVE(ENETUNREACH); } @@ -1220,7 +1234,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite */ sp = NG_HOOK_PRIVATE(sendhook); if (sp->state != PPPOE_SINIT) { - printf("session in wrong state\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: session " + "in wrong state\n", node->nd_ID); LEAVE(ENETUNREACH); } neg = sp->neg; @@ -1249,7 +1264,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite scan_tags(sp, ph); make_packet(sp); sp->state = PPPOE_SREQ; - sendpacket(sp); + ng_pppoe_sendpacket(sp); break; case PADR_CODE: @@ -1311,7 +1326,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite scan_tags(sp, ph); make_packet(sp); sp->state = PPPOE_NEWCONNECTED; - sendpacket(sp); + ng_pppoe_sendpacket(sp); /* * Having sent the last Negotiation header, * Set up the stored packet header to @@ -1560,7 +1575,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite insert_tag(sp, &uniqtag.hdr); scan_tags(sp, ph); make_packet(sp); - sendpacket(sp); + ng_pppoe_sendpacket(sp); break; /* @@ -1655,8 +1670,9 @@ ng_pppoe_disconnect(hook_p hook) /* Generate a packet of that type. */ MGETHDR(m, M_DONTWAIT, MT_DATA); - if(m == NULL) - printf("pppoe: Session out of mbufs\n"); + if (m == NULL) + log(LOG_NOTICE, "ng_pppoe[%x]: session out of " + "mbufs\n", node->nd_ID); else { m->m_pkthdr.rcvif = NULL; m->m_pkthdr.len = m->m_len = sizeof(*wh); @@ -1749,13 +1765,14 @@ pppoe_ticker(node_p node, hook_p hook, v break; default: /* Timeouts have no meaning in other states. */ - printf("pppoe: unexpected timeout\n"); + log(LOG_NOTICE, "ng_pppoe[%x]: unexpected timeout\n", + node->nd_ID); } } static void -sendpacket(sessp sp) +ng_pppoe_sendpacket(sessp sp) { struct mbuf *m0 = NULL; hook_p hook = sp->hook; @@ -1770,7 +1787,8 @@ sendpacket(sessp sp) case PPPOE_DEAD: case PPPOE_SNONE: case PPPOE_CONNECTED: - printf("pppoe: sendpacket: unexpected state\n"); + log(LOG_NOTICE, "%s: unexpected state %d\n", + __func__, sp->state); break; case PPPOE_NEWCONNECTED: @@ -1807,7 +1825,7 @@ sendpacket(sessp sp) default: error = EINVAL; - printf("pppoe: timeout: bad state\n"); + log(LOG_NOTICE, "%s: bad state %d\n", __func__, sp->state); } } --BghK6+krpKHjj+jk-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 15:12:21 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAB4916A4DA for ; Fri, 4 Aug 2006 15:12:21 +0000 (UTC) (envelope-from benlutz@datacomm.ch) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C296E43D72 for ; Fri, 4 Aug 2006 15:12:20 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id k74FCIZk027419 for ; Fri, 4 Aug 2006 17:12:19 +0200 (CEST) (envelope-from benlutz@datacomm.ch) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 02DAE2E109 for ; Fri, 4 Aug 2006 17:12:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTH1XAL5w-ad for ; Fri, 4 Aug 2006 17:12:12 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id C89FE2E05C for ; Fri, 4 Aug 2006 17:12:12 +0200 (CEST) From: Benjamin Lutz To: freebsd-hackers@freebsd.org Date: Fri, 4 Aug 2006 17:12:11 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline X-Length: 2016 X-UID: 50 X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"_+R 2@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@g?4f,\c7|Gh wb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200608041712.11939.benlutz@datacomm.ch> X-Scanned-By: MIMEDefang 2.57 on 213.160.40.60 Subject: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 15:12:21 -0000 Hello, I've noticed that FreeBSD does not by default comply to RFC 919, Chapter 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle IP packets with a destination address of 255.255.255.255 properly. 255.255.255.255 is a "limited broadcast address" (the term is not mentioned in the RFC, but seems to be in use everywhere else). An IP packet send to that address should be broadcast to the whole IP subnet of the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does not work, as is evident by this tcpdump output: 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id 33319, seq 0, length 64 The destination MAC address is that of my gateway, but it should be ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip proto 1" and "ping 255.255.255.255". I found a discussion from 2003 about this, but it seems to have trailed off without coming to a conclusion: http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The intention seems to be to enable packets to 255.255.255.255. However a test with a small program showed that this option seems to have no effect, outgoing packets still carried the gateway's MAC address as destination. Btw, Linux and NetBSD both handle packets to 255.255.255.255 as broadcasts. Now, is this behaviour intentional? Is there a way to turn on RFC 919 compliance? If not, would someone be willing to add this to the kernel? Should I submit a PR? Cheers Benjamin From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 15:38:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6058516A4DA for ; Fri, 4 Aug 2006 15:38:30 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mfront7.mail.yandex.net (mfront7.mail.yandex.net [213.180.223.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id E65B443D49 for ; Fri, 4 Aug 2006 15:38:13 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (mfront7.yandex.ru) by mail.yandex.ru id ; Fri, 4 Aug 2006 19:37:58 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Fri, 4 Aug 2006 19:37:58 +0400 (MSD) Date: Fri, 4 Aug 2006 19:37:58 +0400 (MSD) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <44D369D6.000001.22168@mfront7.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: benlutz@datacomm.ch In-Reply-To: <200608041712.11939.benlutz@datacomm.ch> References: <200608041712.11939.benlutz@datacomm.ch> X-Source-Ip: 82.211.152.12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 15:38:30 -0000 >I found a discussion from 2003 about this, but it seems to have trailed off >without coming to a conclusion: >http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html I've opened a similar PR http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558 -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 15:48:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A03F16A4DF for ; Fri, 4 Aug 2006 15:48:52 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F96343D45 for ; Fri, 4 Aug 2006 15:48:50 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so115270wxd for ; Fri, 04 Aug 2006 08:48:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FIHRG0O/tmN5EcJGMbbWgwM+3DIVhfLro+0iU75t0gpDCrVoxdV8DywmhZ88EPVNCK7TtuZnEjLITfVidnmY3daQRGWGUiT546kSbANX/xiYUG2s0A303VaThRgHMH8PgchLlJHcE1UFxQq3bxSdlsVNmNCNJ4c2VXF7wrP34lM= Received: by 10.70.67.2 with SMTP id p2mr2841182wxa; Fri, 04 Aug 2006 08:48:50 -0700 (PDT) Received: by 10.35.112.18 with HTTP; Fri, 4 Aug 2006 08:48:49 -0700 (PDT) Message-ID: <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> Date: Fri, 4 Aug 2006 16:48:49 +0100 From: "Joao Barros" To: "Gleb Smirnoff" In-Reply-To: <20060804150302.GD96644@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 15:48:52 -0000 On 8/4/06, Gleb Smirnoff wrote: > On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: > J> Being this a cryptic message to say the least and to probably save > J> someone some time when presented with this message I attach a patch > J> that adds the header "pppoe:" in every printf that didn't have it, > J> making it consistent with the rest of the file. > > I've attached a patch that cleans a bit logging in ng_pppoe. It changes > all printf(9) to log(9). The latter is better since it spams console > less, if event occurs many times per second. Also I've made the messages > more clear - prepended node ID where possible, function name when it > starts with ng_pppoe, or just "ng_pppoe". > > Can you please try out this patch and tell whether you like it. If you > do I will commit it soon. Hi, I've looked at the patch and it looks ok. It serves the purpose: make the messages more clear with the added bonus of more info. Thanks for taking the time to look into this :-) -- Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 16:16:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58AE716A4DE for ; Fri, 4 Aug 2006 16:16:17 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B1C243D64 for ; Fri, 4 Aug 2006 16:16:08 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k74GG4mX042720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 4 Aug 2006 18:16:05 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Mario Lobo In-Reply-To: <200608040759.49390.mario.lobo@ipad.com.br> References: <200608040759.49390.mario.lobo@ipad.com.br> Content-Type: multipart/mixed; boundary="=-tOklOyZQSH+iNYW5Ud0j" Date: Fri, 04 Aug 2006 18:15:47 +0200 Message-Id: <1154708147.3222.15.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: getting interface MAC addr from C X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 16:16:17 -0000 --=-tOklOyZQSH+iNYW5Ud0j Content-Type: text/plain Content-Transfer-Encoding: 7bit Mario Lobo wrote: > Hi; > > Would anyone have a tip on how to get the MAC from a C program? > > I tried: > > struct ifreq ifreq; > unsigned char *hw; > > strcpy(ifreq.ifr_name, "rl0"); > ioctl(fd, SIOCGIFMAC, &ifreq); > hw = ifreq.ifr_ifru.ifru_data; ???? This is probably very far from what you want. MAC stands here for MAC(4) - e.g. security related stuff as opposed to something network (did you read MAC as Media Access Control?). I don't know it that is the easiest/right way to get this information but you can use getifaddrs(3). Attached find a simple program which prints out the interfaces and their MAC addresses using getifaddrs(). The code for getting the printable address is taken from function fmt_sockaddr() from src/usr.bin/netstat/route.c. You can also probably use SIOCGIFADDR with the right socket passed in as fd or with sysctl(3) (int mib[] = { CTL_NET, AF_ROUTE, 0, AF_LINK, NET_RT_IFLIST, 0}). > but i don't know if this is right or, if it is, where to get the MAC from the > structure. I doesn't issue any error compiling or running though. > > In linux i used: > > struct ifreq ifreq; > unsigned char *hw; > > strcpy(ifreq.ifr_name, "rl0"); > ioctl(fd, SIOCGIFHWADDR, &ifreq); > hw = ifreq.ifr_hwaddr.sa_data; > > Thanks, > > Mario > HTH Michal --=-tOklOyZQSH+iNYW5Ud0j-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 18:04:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2009F16A4DD for ; Fri, 4 Aug 2006 18:04:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A62643D55 for ; Fri, 4 Aug 2006 18:04:12 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 13581 invoked from network); 4 Aug 2006 17:55:20 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 4 Aug 2006 17:55:19 -0000 Message-ID: <44D38C1B.1070107@freebsd.org> Date: Fri, 04 Aug 2006 20:04:11 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: bu7cher@yandex.ru References: <200608041712.11939.benlutz@datacomm.ch> <44D369D6.000001.22168@mfront7.yandex.ru> In-Reply-To: <44D369D6.000001.22168@mfront7.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: benlutz@datacomm.ch, freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:04:15 -0000 Andrey V. Elsukov wrote: >>I found a discussion from 2003 about this, but it seems to have trailed off >>without coming to a conclusion: >>http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > > I've opened a similar PR > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/99558 This PR is in the works and I have produced a first (non-working unfortunately) patch some time ago. I've just come back from two+half week vacation and have to catch up to things again. It is not forgotten. -- Andre From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 18:19:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3612716A4DA; Fri, 4 Aug 2006 18:19:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from soapbox.mail.yandex.net (soapbox.mail.yandex.net [213.180.223.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE1343D70; Fri, 4 Aug 2006 18:19:30 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (soapbox.yandex.ru) by mail.yandex.ru id ; Fri, 4 Aug 2006 22:19:19 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Fri, 4 Aug 2006 22:19:19 +0400 (MSD) Date: Fri, 4 Aug 2006 22:19:19 +0400 (MSD) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <44D38FA7.000004.02618@soapbox.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: andre@freebsd.org In-Reply-To: <44D38C1B.1070107@freebsd.org> References: <200608041712.11939.benlutz@datacomm.ch> <44D369D6.000001.22168@mfront7.yandex.ru> <44D38C1B.1070107@freebsd.org> X-Source-Ip: 82.211.152.12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:19:33 -0000 >This PR is in the works and I have produced a first (non-working unfortunately) >patch some time ago. I've just come back from two+half week vacation and have >to catch up to things again. It is not forgotten. Ok :) Thanks for your work! -- WBR, Andrey V. Elsukov From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 18:21:28 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AF4916A4DA; Fri, 4 Aug 2006 18:21:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC47443D5D; Fri, 4 Aug 2006 18:21:27 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k74ILOuE037815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 22:21:25 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k74ILOCf037813; Fri, 4 Aug 2006 22:21:24 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 4 Aug 2006 22:21:23 +0400 From: Gleb Smirnoff To: Joao Barros Message-ID: <20060804182123.GH96644@cell.sick.ru> References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> User-Agent: Mutt/1.5.6i Cc: freebsd-hackers@FreeBSD.org, Julian Elischer Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 18:21:28 -0000 On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote: J> On 8/4/06, Gleb Smirnoff wrote: J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: J> >J> Being this a cryptic message to say the least and to probably save J> >J> someone some time when presented with this message I attach a patch J> >J> that adds the header "pppoe:" in every printf that didn't have it, J> >J> making it consistent with the rest of the file. J> > J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes J> >all printf(9) to log(9). The latter is better since it spams console J> >less, if event occurs many times per second. Also I've made the messages J> >more clear - prepended node ID where possible, function name when it J> >starts with ng_pppoe, or just "ng_pppoe". J> > J> >Can you please try out this patch and tell whether you like it. If you J> >do I will commit it soon. J> J> Hi, J> J> I've looked at the patch and it looks ok. J> It serves the purpose: make the messages more clear with the added J> bonus of more info. J> Thanks for taking the time to look into this :-) Since I don't use ng_pppoe now much, I'd appreciate if you do at brief test of this patch, before I commit it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 20:22:23 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85B8D16A4DF; Fri, 4 Aug 2006 20:22:23 +0000 (UTC) (envelope-from prvs=julian=3646b5a3c@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C13543D5A; Fri, 4 Aug 2006 20:22:22 +0000 (GMT) (envelope-from prvs=julian=3646b5a3c@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 04 Aug 2006 13:22:22 -0700 Message-ID: <44D3AC7D.2040606@elischer.org> Date: Fri, 04 Aug 2006 13:22:21 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> In-Reply-To: <20060804150302.GD96644@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Joao Barros , Julian Elischer Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 20:22:23 -0000 Gleb Smirnoff wrote: >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: >J> I recently switched ISPs which in turn led me from a cablemodem to an >J> ADSL modem. >J> After setting PPPoE up I started noticing this messages in the daily >J> run outputs that that nice guy Charlie root sends me at 3am: >J> >J> Aug 3 08:24:54 ultra5 kernel: session in wrong state >J> >J> I was a bit suspicious of anything PPPoE related and a little search >J> confirmed that, pointing directly at ng_pppoe.c >J> Being this a cryptic message to say the least and to probably save >J> someone some time when presented with this message I attach a patch >J> that adds the header "pppoe:" in every printf that didn't have it, >J> making it consistent with the rest of the file. >J> I also noticed this message appears right before the ISP closes the >J> connection due to time limit. >J> >J> I'm CCing those I see were the last ones to commit to this file and >J> will file a PR if asked to. > > >I've attached a patch that cleans a bit logging in ng_pppoe. It changes >all printf(9) to log(9). The latter is better since it spams console >less, if event occurs many times per second. Also I've made the messages >more clear - prepended node ID where possible, function name when it >starts with ng_pppoe, or just "ng_pppoe". > >Can you please try out this patch and tell whether you like it. If you >do I will commit it soon. > > > I like the look of it.. much of my code should use log() instead of printf() in such cases I think. >------------------------------------------------------------------------ > >Index: ng_pppoe.c >=================================================================== >RCS file: /home/ncvs/src/sys/netgraph/ng_pppoe.c,v >retrieving revision 1.78 >diff -u -p -r1.78 ng_pppoe.c >--- ng_pppoe.c 27 Jan 2006 10:56:22 -0000 1.78 >+++ ng_pppoe.c 4 Aug 2006 15:00:30 -0000 >@@ -48,6 +48,7 @@ > #include > #include > #include >+#include > #include > > #include >@@ -261,7 +262,7 @@ union uniq { > > #define LEAVE(x) do { error = x; goto quit; } while(0) > static void pppoe_start(sessp sp); >-static void sendpacket(sessp sp); >+static void ng_pppoe_sendpacket(sessp sp); > static void pppoe_ticker(node_p node, hook_p hook, void *arg1, int arg2); > static const struct pppoe_tag *scan_tags(sessp sp, > const struct pppoe_hdr* ph); >@@ -383,7 +384,8 @@ insert_tag(sessp sp, const struct pppoe_ > if ((i = neg->numtags++) < NUMTAGS) { > neg->tags[i] = tp; > } else { >- printf("pppoe: asked to add too many tags to packet\n"); >+ log(LOG_NOTICE, "ng_pppoe: asked to add too many tags to " >+ "packet\n"); > neg->numtags--; > } > } >@@ -406,7 +408,7 @@ make_packet(sessp sp) { > uint16_t length = 0; > > KASSERT((sp->neg != NULL) && (sp->neg->m != NULL), >- ("%s: make_packet called from wrong state", __func__)); >+ ("%s: called from wrong state", __func__)); > CTR2(KTR_NET, "%20s: called %d", __func__, sp->Session_ID); > > dp = (char *)wh->ph.tag; >@@ -415,7 +417,7 @@ make_packet(sessp sp) { > tag++, count++) { > tlen = ntohs((*tag)->tag_len) + sizeof(**tag); > if ((length + tlen) > (ETHER_MAX_LEN - 4 - sizeof(*wh))) { >- printf("pppoe: tags too long\n"); >+ log(LOG_NOTICE, "ng_pppoe: tags too long\n"); > sp->neg->numtags = count; > break; /* XXX chop off what's too long */ > } >@@ -714,18 +716,21 @@ ng_pppoe_rcvmsg(node_p node, item_p item > case NGM_PPPOE_SERVICE: > ourmsg = (struct ngpppoe_init_data *)msg->data; > if (msg->header.arglen < sizeof(*ourmsg)) { >- printf("pppoe: init data too small\n"); >+ log(LOG_ERR, "ng_pppoe[%x]: init data too " >+ "small\n", node->nd_ID); > LEAVE(EMSGSIZE); > } > if (msg->header.arglen - sizeof(*ourmsg) > > PPPOE_SERVICE_NAME_SIZE) { >- printf("pppoe_rcvmsg: service name too big"); >+ log(LOG_ERR, "ng_pppoe[%x]: service name " >+ "too big\n", node->nd_ID); > LEAVE(EMSGSIZE); > } > if (msg->header.arglen - sizeof(*ourmsg) < > ourmsg->data_len) { >- printf("pppoe: init data has bad length," >- " %d should be %zd\n", ourmsg->data_len, >+ log(LOG_ERR, "ng_pppoe[%x]: init data has bad " >+ "length, %d should be %zd\n", node->nd_ID, >+ ourmsg->data_len, > msg->header.arglen - sizeof (*ourmsg)); > LEAVE(EMSGSIZE); > } >@@ -767,7 +772,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item > break; > > if (sp->state != PPPOE_SNONE) { >- printf("pppoe: Session already active\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: Session already " >+ "active\n", node->nd_ID); > LEAVE(EISCONN); > } > >@@ -882,7 +888,8 @@ ng_pppoe_rcvmsg(node_p node, item_p item > * If you do it twice you just overwrite. > */ > if (sp->state != PPPOE_PRIMED) { >- printf("pppoe: Session not primed\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: session not " >+ "primed\n", node->nd_ID); > LEAVE(EISCONN); > } > neg = sp->neg; >@@ -1012,7 +1019,7 @@ pppoe_start(sessp sp) > insert_tag(sp, &uniqtag.hdr); > insert_tag(sp, &sp->neg->service.hdr); > make_packet(sp); >- sendpacket(sp); >+ ng_pppoe_sendpacket(sp); > } > > static int >@@ -1105,7 +1112,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > if( m->m_len < sizeof(*wh)) { > m = m_pullup(m, sizeof(*wh)); /* Checks length */ > if (m == NULL) { >- printf("couldn't m_pullup\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: couldn't " >+ "m_pullup(wh)\n", node->nd_ID); > LEAVE(ENOBUFS); > } > } >@@ -1124,7 +1132,10 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > if( m->m_len < m->m_pkthdr.len) { > m = m_pullup(m, m->m_pkthdr.len); > if (m == NULL) { >- printf("couldn't m_pullup\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: " >+ "couldn't " >+ "m_pullup(pkthdr)\n", >+ node->nd_ID); > LEAVE(ENOBUFS); > } > } >@@ -1147,7 +1158,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > } > } > if (m == NULL) { >- printf("packet fragmented\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: packet " >+ "fragmented\n", node->nd_ID); > LEAVE(EMSGSIZE); > } > } >@@ -1204,13 +1216,15 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > utag = get_tag(ph, PTT_HOST_UNIQ); > if ((utag == NULL) > || (ntohs(utag->tag_len) != sizeof(sp))) { >- printf("no host unique field\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: no host " >+ "unique field\n", node->nd_ID); > LEAVE(ENETUNREACH); > } > > sendhook = pppoe_finduniq(node, utag); > if (sendhook == NULL) { >- printf("no matching session\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: no " >+ "matching session\n", node->nd_ID); > LEAVE(ENETUNREACH); > } > >@@ -1220,7 +1234,8 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > */ > sp = NG_HOOK_PRIVATE(sendhook); > if (sp->state != PPPOE_SINIT) { >- printf("session in wrong state\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: session " >+ "in wrong state\n", node->nd_ID); > LEAVE(ENETUNREACH); > } > neg = sp->neg; >@@ -1249,7 +1264,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > scan_tags(sp, ph); > make_packet(sp); > sp->state = PPPOE_SREQ; >- sendpacket(sp); >+ ng_pppoe_sendpacket(sp); > break; > case PADR_CODE: > >@@ -1311,7 +1326,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > scan_tags(sp, ph); > make_packet(sp); > sp->state = PPPOE_NEWCONNECTED; >- sendpacket(sp); >+ ng_pppoe_sendpacket(sp); > /* > * Having sent the last Negotiation header, > * Set up the stored packet header to >@@ -1560,7 +1575,7 @@ ng_pppoe_rcvdata(hook_p hook, item_p ite > insert_tag(sp, &uniqtag.hdr); > scan_tags(sp, ph); > make_packet(sp); >- sendpacket(sp); >+ ng_pppoe_sendpacket(sp); > break; > > /* >@@ -1655,8 +1670,9 @@ ng_pppoe_disconnect(hook_p hook) > > /* Generate a packet of that type. */ > MGETHDR(m, M_DONTWAIT, MT_DATA); >- if(m == NULL) >- printf("pppoe: Session out of mbufs\n"); >+ if (m == NULL) >+ log(LOG_NOTICE, "ng_pppoe[%x]: session out of " >+ "mbufs\n", node->nd_ID); > else { > m->m_pkthdr.rcvif = NULL; > m->m_pkthdr.len = m->m_len = sizeof(*wh); >@@ -1749,13 +1765,14 @@ pppoe_ticker(node_p node, hook_p hook, v > break; > default: > /* Timeouts have no meaning in other states. */ >- printf("pppoe: unexpected timeout\n"); >+ log(LOG_NOTICE, "ng_pppoe[%x]: unexpected timeout\n", >+ node->nd_ID); > } > } > > > static void >-sendpacket(sessp sp) >+ng_pppoe_sendpacket(sessp sp) > { > struct mbuf *m0 = NULL; > hook_p hook = sp->hook; >@@ -1770,7 +1787,8 @@ sendpacket(sessp sp) > case PPPOE_DEAD: > case PPPOE_SNONE: > case PPPOE_CONNECTED: >- printf("pppoe: sendpacket: unexpected state\n"); >+ log(LOG_NOTICE, "%s: unexpected state %d\n", >+ __func__, sp->state); > break; > > case PPPOE_NEWCONNECTED: >@@ -1807,7 +1825,7 @@ sendpacket(sessp sp) > > default: > error = EINVAL; >- printf("pppoe: timeout: bad state\n"); >+ log(LOG_NOTICE, "%s: bad state %d\n", __func__, sp->state); > } > } > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 21:59:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F262C16A4DE for ; Fri, 4 Aug 2006 21:59:17 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx01.cablebg.net [217.9.224.226]) by mx1.FreeBSD.org (Postfix) with SMTP id ED56043D46 for ; Fri, 4 Aug 2006 21:59:16 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 57183 invoked from network); 4 Aug 2006 21:59:13 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 0.87053 secs); 04 Aug 2006 21:59:13 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx01.interbgc.com with SMTP; 4 Aug 2006 21:59:12 -0000 Received: (qmail 33190 invoked from network); 4 Aug 2006 21:59:12 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 4 Aug 2006 21:59:12 -0000 Message-ID: <44D3C333.3030702@cytexbg.com> Date: Sat, 05 Aug 2006 00:59:15 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: linux ioremap equivalent on freebsd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 21:59:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm in the middle of a struggle to port the linux nozomi(Option GloberTrotter 3G+ HSDPA cardbus adapter) driver to freebsd. And given the fact that i have very little previous kernel coding experience i can't find what i can use in freebsd as equivalent of linux's ioremap(). Any ideas are appreciated. Thanks! P.S.: here is the original linux driver http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz Regards, Niki Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE08MzHNAJ/fLbfrkRAgjHAJ9diB4h2nsrGKZyznNl3nzlRPgQfQCgkN/3 6LsQAU03xH9+gaARrzoevIE= =2iMR -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 4 23:42:14 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB58C16A4E2 for ; Fri, 4 Aug 2006 23:42:14 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2984B43D46 for ; Fri, 4 Aug 2006 23:42:13 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so286142pyc for ; Fri, 04 Aug 2006 16:42:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DtOod3DedhdMlW7CVbIqQksbmU8aWp0WP6btlD1J1Iu1q6G6xnR0l5xqNdKtnCS0F4LpuA2AjG4qsrC0V7lj7wWMaP/Q7PRxYFtmrZ4Xo/X83ef/ila2Cnfxi+JYbkoGee6mppbRAuC2r1RzKGZ33bqHJW6ewB8+o+IPopPPahQ= Received: by 10.35.66.12 with SMTP id t12mr5995123pyk; Fri, 04 Aug 2006 16:42:12 -0700 (PDT) Received: by 10.35.112.18 with HTTP; Fri, 4 Aug 2006 16:42:12 -0700 (PDT) Message-ID: <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com> Date: Sat, 5 Aug 2006 00:42:12 +0100 From: "Joao Barros" To: "Gleb Smirnoff" In-Reply-To: <20060804182123.GH96644@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> <20060804182123.GH96644@cell.sick.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2006 23:42:14 -0000 On 8/4/06, Gleb Smirnoff wrote: > On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote: > J> On 8/4/06, Gleb Smirnoff wrote: > J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: > J> >J> Being this a cryptic message to say the least and to probably save > J> >J> someone some time when presented with this message I attach a patch > J> >J> that adds the header "pppoe:" in every printf that didn't have it, > J> >J> making it consistent with the rest of the file. > J> > > J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes > J> >all printf(9) to log(9). The latter is better since it spams console > J> >less, if event occurs many times per second. Also I've made the messages > J> >more clear - prepended node ID where possible, function name when it > J> >starts with ng_pppoe, or just "ng_pppoe". > J> > > J> >Can you please try out this patch and tell whether you like it. If you > J> >do I will commit it soon. > J> > J> Hi, > J> > J> I've looked at the patch and it looks ok. > J> It serves the purpose: make the messages more clear with the added > J> bonus of more info. > J> Thanks for taking the time to look into this :-) > > Since I don't use ng_pppoe now much, I'd appreciate if you > do at brief test of this patch, before I commit it. > I patched and recompiled the kernel. After booting I notice that no messages from ppp are logged by syslog (messages|ppp.log) If I restart ppp the messages are all logged. I can't say if this was happening because after setting ppp up I didn't reboot the machine. I didn't browse the startup scripts but maybe syslog is not started before pppoe. Now it will take more than 17 hours for the session limit to be exceeded and only then I can say how your patch worked out. I'll make an update then. -- Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 05:19:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 003D916A4DA for ; Sat, 5 Aug 2006 05:19:02 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (ki.iif.hu [193.6.222.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id F034743D6E for ; Sat, 5 Aug 2006 05:18:55 +0000 (GMT) (envelope-from mohacsi@niif.hu) Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 7F68E55A9; Sat, 5 Aug 2006 07:18:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 7E3BF54F6; Sat, 5 Aug 2006 07:18:54 +0200 (CEST) Date: Sat, 5 Aug 2006 07:18:54 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Benjamin Lutz In-Reply-To: <200608041712.11939.benlutz@datacomm.ch> Message-ID: <20060805071620.D83852@mignon.ki.iif.hu> References: <200608041712.11939.benlutz@datacomm.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 05:19:03 -0000 On Fri, 4 Aug 2006, Benjamin Lutz wrote: > Hello, > > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter 7 > (http://tools.ietf.org/html/rfc919). Specifically, it does not handle IP > packets with a destination address of 255.255.255.255 properly. > > 255.255.255.255 is a "limited broadcast address" (the term is not mentioned in > the RFC, but seems to be in use everywhere else). An IP packet send to that > address should be broadcast to the whole IP subnet of the broadcasting > device. However, in FreeBSD (4.11, 5.5, 6.1) this does not work, as is > evident by this tcpdump output: > > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id 33319, > seq 0, length 64 > > The destination MAC address is that of my gateway, but it should be > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip proto 1" > and "ping 255.255.255.255". > > I found a discussion from 2003 about this, but it seems to have trailed off > without coming to a conclusion: > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The intention > seems to be to enable packets to 255.255.255.255. However a test with a small > program showed that this option seems to have no effect, outgoing packets > still carried the gateway's MAC address as destination. > > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as broadcasts. > > Now, is this behaviour intentional? Is there a way to turn on RFC 919 > compliance? If not, would someone be willing to add this to the kernel? Should > I submit a PR? Does this feature really necessary? For waht purpose? I believe this feature is more harmful than useful. Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > Cheers > Benjamin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 08:51:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C34816A4E1 for ; Sat, 5 Aug 2006 08:51:24 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id D888943D4C for ; Sat, 5 Aug 2006 08:51:22 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so58659pyc for ; Sat, 05 Aug 2006 01:51:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Uuop/++hAQ9Y8oX4fwqUkKu20Y7rd4pywG0g1oBb+uzzN148/j/AmLXTlIr7cJs6f9fS99u56zWZ/pS63TZJf7ZdBlDQKnj7rVa4ORXXNY31g/PTF1n/b/idaS+B7+NLMBkxhgeJFzN+IilsZrF8aZy42w16JL0KawabxKj+E0s= Received: by 10.35.87.8 with SMTP id p8mr6921707pyl; Sat, 05 Aug 2006 01:51:22 -0700 (PDT) Received: by 10.35.112.18 with HTTP; Sat, 5 Aug 2006 01:51:22 -0700 (PDT) Message-ID: <70e8236f0608050151p5582e45ck5b9a5c4f2145c7fa@mail.gmail.com> Date: Sat, 5 Aug 2006 09:51:22 +0100 From: "Joao Barros" To: "Gleb Smirnoff" In-Reply-To: <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> <20060804182123.GH96644@cell.sick.ru> <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 08:51:24 -0000 On 8/5/06, Joao Barros wrote: > On 8/4/06, Gleb Smirnoff wrote: > > On Fri, Aug 04, 2006 at 04:48:49PM +0100, Joao Barros wrote: > > J> On 8/4/06, Gleb Smirnoff wrote: > > J> >On Thu, Aug 03, 2006 at 03:35:04PM +0100, Joao Barros wrote: > > J> >J> Being this a cryptic message to say the least and to probably save > > J> >J> someone some time when presented with this message I attach a patch > > J> >J> that adds the header "pppoe:" in every printf that didn't have it, > > J> >J> making it consistent with the rest of the file. > > J> > > > J> >I've attached a patch that cleans a bit logging in ng_pppoe. It changes > > J> >all printf(9) to log(9). The latter is better since it spams console > > J> >less, if event occurs many times per second. Also I've made the messages > > J> >more clear - prepended node ID where possible, function name when it > > J> >starts with ng_pppoe, or just "ng_pppoe". > > J> > > > J> >Can you please try out this patch and tell whether you like it. If you > > J> >do I will commit it soon. > > J> > > J> Hi, > > J> > > J> I've looked at the patch and it looks ok. > > J> It serves the purpose: make the messages more clear with the added > > J> bonus of more info. > > J> Thanks for taking the time to look into this :-) > > > > Since I don't use ng_pppoe now much, I'd appreciate if you > > do at brief test of this patch, before I commit it. > > > > I patched and recompiled the kernel. > After booting I notice that no messages from ppp are logged by syslog > (messages|ppp.log) > If I restart ppp the messages are all logged. > I can't say if this was happening because after setting ppp up I > didn't reboot the machine. > I didn't browse the startup scripts but maybe syslog is not started > before pppoe. > > Now it will take more than 17 hours for the session limit to be > exceeded and only then I can say how your patch worked out. I'll make > an update then. Ok, here's the new output just before the connection was dropped (earlier than usual): Aug 5 07:28:50 ultra5 kernel: ng_pppoe[5]: session in wrong state Aug 5 07:28:50 ultra5 last message repeated 3 times Looks fine to me :-) -- Joao Barros From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 09:38:49 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A57AE16A4DA for ; Sat, 5 Aug 2006 09:38:49 +0000 (UTC) (envelope-from viaprog@gmail.com) Received: from hu-out-0102.google.com (hu-out-0102.google.com [72.14.214.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id E72F843D53 for ; Sat, 5 Aug 2006 09:38:48 +0000 (GMT) (envelope-from viaprog@gmail.com) Received: by hu-out-0102.google.com with SMTP id 27so278714hub for ; Sat, 05 Aug 2006 02:38:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:subject:from:content-type:mime-version:content-transfer-encoding:date:message-id:user-agent; b=WROmMQS4hVUI8/w/ItKsq52gAa0UawCSVxSZ3O46X7hoiYasivLvvFy94Jei3V6MbJ7jLcPxTd8Qw9Zbjudsqk9DFdbClDidfCv5pBJ6iOkpu3Gcrl5dzJCxR3lsX4wHVz/BuXxaFDPFy0eSuIuYBIz+/rM5/FNI6jimKZldG0Y= Received: by 10.49.92.18 with SMTP id u18mr6471646nfl; Sat, 05 Aug 2006 02:38:47 -0700 (PDT) Received: from s4.hibet.ru ( [212.248.26.95]) by mx.gmail.com with ESMTP id p43sm3467569nfa.2006.08.05.02.38.46; Sat, 05 Aug 2006 02:38:46 -0700 (PDT) To: freebsd-hackers@freebsd.org From: "Igor A. Valcov" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Date: Sat, 05 Aug 2006 13:38:48 +0400 Message-ID: User-Agent: Opera Mail/9.00 (Linux) Subject: pthreads memoty leak? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 09:38:49 -0000 Hi The startup of this program causes memory leak, doesn't it? What's the reason? Tested on FreeBSD-6.1 and 5.4 with the same effect. On Linux work fine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= #include #include #include void* mythread(void* arg) { return NULL; } void threaded() { #define size 1 int ret, i; for (i =3D 0; i < size; i++) { pthread_t t_id; pthread_attr_t pthread_attr; pthread_attr_init (&pthread_attr); pthread_attr_setdetachstate (&pthread_attr, PTHREAD_CREATE_DETACHED); ret =3D pthread_create (&t_id, &pthread_attr, mythread, NULL)= ; pthread_attr_destroy (&pthread_attr); if (ret) printf ("pthread_create() returned error value %d\n", ret= ); } } int main() { int i; for (i =3D 0; i < 10000000; i++) { if (i % 1000 =3D=3D 0) printf ("main() iteration: %d\n", i); threaded(); } printf ("FINISHED.\n"); sleep (3600); return 0; } =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 -- = Igor A. Valcov From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 09:58:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B61B116A4DE for ; Sat, 5 Aug 2006 09:58:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2002343D53 for ; Sat, 5 Aug 2006 09:58:33 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from [193.216.120.137] (HELO [10.0.0.249]) by mailfe07.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 249508784; Sat, 05 Aug 2006 11:58:32 +0200 From: Hans Petter Selasky To: pyunyh@gmail.com Date: Sat, 5 Aug 2006 11:58:39 +0200 User-Agent: KMail/1.7 References: <200608021437.55500.hselasky@c2i.net> <200608031444.47566.hselasky@c2i.net> <20060804000939.GA53215@cdnetworks.co.kr> In-Reply-To: <20060804000939.GA53215@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608051158.39850.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: miibus + USB = problem ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 09:58:34 -0000 On Friday 04 August 2006 02:09, Pyun YongHyeon wrote: > On Thu, Aug 03, 2006 at 02:44:46PM +0200, Hans Petter Selasky wrote: > > On Thursday 03 August 2006 04:25, Pyun YongHyeon wrote: > > > On Wed, Aug 02, 2006 at 02:37:55PM +0200, Hans Petter Selasky wrote: > > I can't sure why you need to invoke kthread_exit(9) in aue_miibus_xxx. > If you want to kill the kernel thread in aue_miibus_xxx you can simply > send a termination message to kernel thread. Your kernel thread can > decide when it should terminate if it recevied a termination message. > Invoking mii_mediachg/mii_tick will end up with calling miibus_xxx to > to read/write PHY registers from MII layer. So I think you still need > to handle PHY read/write operations in aue_miibus_xxx. If the PHY > operation was failed due to removal of hardware it could simply return > fake value and send a message to terminate the kernel thread. Yes, I was thinking about the same. I changed the behaviour to return zero if the thread is gone, and delays are just short-circuited. That way the code will return to the main thread in a short time, hopefully, where I do a kthread_exit(0). --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 11:51:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652C616A4DA for ; Sat, 5 Aug 2006 11:51:30 +0000 (UTC) (envelope-from benlutz@datacomm.ch) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7167D43D53 for ; Sat, 5 Aug 2006 11:51:29 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id k75BpOxZ025215; Sat, 5 Aug 2006 13:51:26 +0200 (CEST) (envelope-from benlutz@datacomm.ch) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 903F82E10A; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFoHekmwUFgu; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 530D52E0CE; Sat, 5 Aug 2006 13:51:19 +0200 (CEST) From: Benjamin Lutz To: Mohacsi Janos Date: Sat, 5 Aug 2006 13:51:12 +0200 User-Agent: KMail/1.9.1 References: <200608041712.11939.benlutz@datacomm.ch> <20060805071620.D83852@mignon.ki.iif.hu> In-Reply-To: <20060805071620.D83852@mignon.ki.iif.hu> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+R=0A?= 2@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@g?4f,=?iso-8859-1?q?=5Cc7=7CGh=0A?= =?iso-8859-1?q?_wb=26ky=24b2PJ=5E=5C0b83NkLsFKv=7CsmL/cI4UD=25Tu8alAD?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1559819.93zyx9al9W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200608051351.16071.benlutz@datacomm.ch> X-Scanned-By: MIMEDefang 2.57 on 213.160.40.60 Cc: freebsd-hackers@freebsd.org Subject: Re: RFC 919 compliance (broadcasts to 255.255.255.255) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 11:51:30 -0000 --nextPart1559819.93zyx9al9W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 05 August 2006 07:18, you wrote: > On Fri, 4 Aug 2006, Benjamin Lutz wrote: > > Hello, > > > > I've noticed that FreeBSD does not by default comply to RFC 919, Chapter > > 7 (http://tools.ietf.org/html/rfc919). Specifically, it does not handle > > IP packets with a destination address of 255.255.255.255 properly. > > > > 255.255.255.255 is a "limited broadcast address" (the term is not > > mentioned in the RFC, but seems to be in use everywhere else). An IP > > packet send to that address should be broadcast to the whole IP subnet = of > > the broadcasting device. However, in FreeBSD (4.11, 5.5, 6.1) this does > > not work, as is evident by this tcpdump output: > > > > 17:00:59.125132 00:12:17:5a:b3:b6 > 00:40:63:d9:a9:28, ethertype IPv4 > > (0x0800), length 98: 10.0.0.1 > 255.255.255.255: ICMP echo request, id > > 33319, seq 0, length 64 > > > > The destination MAC address is that of my gateway, but it should be > > ff:ff:ff:ff:ff:ff. You can reproduce this by running "tcpdump -en ip > > proto 1" and "ping 255.255.255.255". > > > > I found a discussion from 2003 about this, but it seems to have trailed > > off without coming to a conclusion: > > http://lists.freebsd.org/pipermail/freebsd-net/2003-July/000921.html > > > > I've noticed that the ip(7) manpage lists a SO_ONESBCAST option. The > > intention seems to be to enable packets to 255.255.255.255. However a > > test with a small program showed that this option seems to have no > > effect, outgoing packets still carried the gateway's MAC address as > > destination. > > > > Btw, Linux and NetBSD both handle packets to 255.255.255.255 as > > broadcasts. > > > > Now, is this behaviour intentional? Is there a way to turn on RFC 919 > > compliance? If not, would someone be willing to add this to the kernel? > > Should I submit a PR? > > Does this feature really necessary? For waht purpose? I discovered it when playing with Wake-on-LAN packets. It is possible to se= nd=20 those with the real subnet's broadcast address, but then you first have to= =20 figure that one out. If you have a network device that doesn't have an IP=20 configured yet, it would not know the subnet broadcast address. > I believe this feature is more harmful than useful. Please elaborate. Remember that routers do not pass on packets to=20 255.255.255.255. The TTL is effectively 1. Cheers Benjamin --nextPart1559819.93zyx9al9W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBE1IY0gShs4qbRdeQRAgDFAJwIhjG/sqbgmTTxmNhKsyG5C2OCYQCfWyZ2 +K0xBHAMsZgnQNM9F0r3lo4= =wIRG -----END PGP SIGNATURE----- --nextPart1559819.93zyx9al9W-- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 14:06:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 628CC16A4DA for ; Sat, 5 Aug 2006 14:06:22 +0000 (UTC) (envelope-from nike_d@cytexbg.com) Received: from mail.interbgc.com (mx01.cablebg.net [217.9.224.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 6FBA243D46 for ; Sat, 5 Aug 2006 14:06:20 +0000 (GMT) (envelope-from nike_d@cytexbg.com) Received: (qmail 87532 invoked from network); 5 Aug 2006 14:06:19 -0000 Received: from nike_d@cytexbg.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(0.1/8.0):. Processed in 1.095461 secs); 05 Aug 2006 14:06:19 -0000 X-Spam-Status: No, hits=0.1 required=8.0 Received: from niked.ddns.cablebg.net (HELO tormentor.totalterror.net) (85.130.14.211) by mx01.interbgc.com with SMTP; 5 Aug 2006 14:06:18 -0000 Received: (qmail 48036 invoked from network); 5 Aug 2006 14:06:17 -0000 Received: from unknown (HELO ?10.0.0.3?) (10.0.0.3) by tormentor.totalterror.net with SMTP; 5 Aug 2006 14:06:17 -0000 Message-ID: <44D4A5DC.7080403@cytexbg.com> Date: Sat, 05 Aug 2006 17:06:20 +0300 From: Niki Denev User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.94.0.0 OpenPGP: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: jkh weird problem (reading pci device memory) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 14:06:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm trying to port a linux driver to freebsd (hsdpa/umts nozomi card), and i'm experiencing some really weird problem... probably due to my limited kernel knowledge/experience. Here it is the attach routine, which tries to read a portion of the device memory into a specially formatted struct. Then the first filed in the struct is compared to a predefined value (a signature) to make sure that the read was successfull. The problem is that right now this only works if i do the printfs marked with XXX. When i comment them the read returns something that looks to me like random garbage... probably i'm doing something very stupid, or missing something essential... any insight is greatly appreciated. Again, here is the original linux driver for reference : http://www.pharscape.org/3G/nozomi_2.1_060703.tar.gz P.S.: This is on 7.0-CURRENT Thanks in advance! Regards, Niki Denev [ code ] int nozomi_attach(device_t dev) { struct nozomi_softc *sc; int i; u_int8_t r; sc = device_get_softc(dev); sc->noz_dev = dev; sc->bar.id = PCIR_BAR(0); sc->bar.res = bus_alloc_resource(dev, SYS_RES_MEMORY, &sc->bar.id, 0, ~0, 1, RF_ACTIVE); sc->bar.tag = rman_get_bustag(sc->bar.res); sc->bar.hdl = rman_get_bushandle(sc->bar.res); sc->base_addr = rman_get_start(sc->bar.res); sc->virt_addr = rman_get_virtual(sc->bar.res); /* set card type to F32_8 on no match */ sc->card_type = rman_get_size(sc->bar.res) == 2048 ? F32_2 : F32_8; device_printf(sc->noz_dev, "card has %uKB memory\n", sc->card_type); /* XXX if i don't print these the reading of the bus memory will be incorrect */ printf("phys address 0x%08lx\n", sc->base_addr); printf("virt address 0x%p\n", sc->virt_addr); printf("cfg address 0x%p\n", &sc->cfg_table); for(i=0; i < sizeof(config_table_t); i++) { r = bus_space_read_1(sc->bar.tag, sc->bar.hdl, i); *((u_int8_t *)&sc->cfg_table + i) = r; } if(sc->cfg_table.signature != CONFIG_MAGIC) { printf("ConfigTable Bad! 0x%08X != 0x%08X\n", sc->cfg_table.signature, CONFIG_MAGIC); return(ENXIO); } [ code continues ... ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE1KXcHNAJ/fLbfrkRAhEZAKCvz1+ZBDH+mSMBLtoreAGDlzSL4wCgsZcL yxziRoie0cqIFYCzdI4gAkk= =6D/Y -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 09:35:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DDCC16A4DE for ; Sat, 5 Aug 2006 09:35:44 +0000 (UTC) (envelope-from viaprog@betline.ru) Received: from mail.betline.ru (ns.hibet.ru [212.248.26.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2269643D46 for ; Sat, 5 Aug 2006 09:35:43 +0000 (GMT) (envelope-from viaprog@betline.ru) Received: from s4.hibet.ru (s4.hibet.ru [212.248.26.95]) by mail.betline.ru (Postfix) with ESMTP id 3A1B010A4C34 for ; Sat, 5 Aug 2006 13:35:41 +0400 (MSD) Date: Sat, 05 Aug 2006 13:35:45 +0400 To: freebsd-hackers@freebsd.org From: "Igor A. Valcov" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Message-ID: User-Agent: Opera Mail/9.00 (Linux) X-Mailman-Approved-At: Sat, 05 Aug 2006 15:32:54 +0000 Subject: pthreads memoty leak? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 09:35:44 -0000 Hi The startup of this program causes memory leak, doesn't it? What's the = reason? Tested on FreeBSD-6.1 and 5.4 with the same effect. On Linux work fine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= #include #include #include void* mythread(void* arg) { return NULL; } void threaded() { #define size 1 int ret, i; for (i =3D 0; i < size; i++) { pthread_t t_id; pthread_attr_t pthread_attr; pthread_attr_init (&pthread_attr); pthread_attr_setdetachstate (&pthread_attr, = PTHREAD_CREATE_DETACHED); ret =3D pthread_create (&t_id, &pthread_attr, mythread, NULL);= pthread_attr_destroy (&pthread_attr); if (ret) printf ("pthread_create() returned error value %d\n", ret)= ; } } int main() { int i; for (i =3D 0; i < 10000000; i++) { if (i % 1000 =3D=3D 0) printf ("main() iteration: %d\n", i); threaded(); } printf ("FINISHED.\n"); sleep (3600); return 0; } =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 -- = Igor A. Valcov From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 15:51:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A35C16A4DE; Sat, 5 Aug 2006 15:51:25 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD6D743D58; Sat, 5 Aug 2006 15:51:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id k75FpNIY075688; Sat, 5 Aug 2006 08:51:23 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k75FpNhZ075687; Sat, 5 Aug 2006 08:51:23 -0700 (PDT) (envelope-from rizzo) Date: Sat, 5 Aug 2006 08:51:23 -0700 From: Luigi Rizzo To: Joao Barros Message-ID: <20060805085123.B74697@xorpc.icir.org> References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> <20060804182123.GH96644@cell.sick.ru> <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com>; from joao.barros@gmail.com on Sat, Aug 05, 2006 at 12:42:12AM +0100 Cc: freebsd-hackers@freebsd.org, Gleb Smirnoff Subject: syslog bug ? (was Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 15:51:25 -0000 On Sat, Aug 05, 2006 at 12:42:12AM +0100, Joao Barros wrote: ... > I patched and recompiled the kernel. > After booting I notice that no messages from ppp are logged by syslog > (messages|ppp.log) What is your OS version ? i hit a similar problem some time ago, and it seems that the syslog client code remembers any error on the socket (e.g. ICMP host/port unreachable messages) and does not retry afterwards (or for some time, or there is some bug in handling the error condition). I am a bit fuzzy on the details because this was some 3 years ago on a 4.x client. Your problem is likely because ppp starts before the syslog daemon, the initial message fails and then you get nothing anymore. the vsyslog code in 6.x (libc/gen/syslog.c) is slightly different from the one in 4.11. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Sat Aug 5 23:23:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D40B16A4E1 for ; Sat, 5 Aug 2006 23:23:54 +0000 (UTC) (envelope-from joao.barros@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3350443D45 for ; Sat, 5 Aug 2006 23:23:53 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so374901pyc for ; Sat, 05 Aug 2006 16:23:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yj4g64DWlgBwbr6iqUVoSRqgOSYcFD0vRORzRkLt1YPa+xKF/CM8pls2RK8q375Wvsf93nGBZ7p/IDw7zkZOz7bRRBvddCSk/ZEV4ZmePwR0tIH4ss+AmfirDcrhyH2rYQKseZHVJEXfs1wjhSycNZUHjsSWU4fXjCp7HBf8DKY= Received: by 10.35.20.14 with SMTP id x14mr8427989pyi; Sat, 05 Aug 2006 16:23:52 -0700 (PDT) Received: by 10.35.112.18 with HTTP; Sat, 5 Aug 2006 16:23:52 -0700 (PDT) Message-ID: <70e8236f0608051623i4f3dd10dy3c049807df49a894@mail.gmail.com> Date: Sun, 6 Aug 2006 00:23:52 +0100 From: "Joao Barros" To: "Luigi Rizzo" In-Reply-To: <20060805085123.B74697@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70e8236f0608030735m519d880fgebeca7108b859244@mail.gmail.com> <20060804150302.GD96644@cell.sick.ru> <70e8236f0608040848x304a671cle6d490f43735737b@mail.gmail.com> <20060804182123.GH96644@cell.sick.ru> <70e8236f0608041642v5c7a85a9u4e4422bb6f08822f@mail.gmail.com> <20060805085123.B74697@xorpc.icir.org> Cc: freebsd-hackers@freebsd.org, Gleb Smirnoff Subject: Re: syslog bug ? (was Re: [PATCH] add header "pppoe:" in ng_pppoe.c printfs) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 23:23:54 -0000 On 8/5/06, Luigi Rizzo wrote: > On Sat, Aug 05, 2006 at 12:42:12AM +0100, Joao Barros wrote: > ... > > I patched and recompiled the kernel. > > After booting I notice that no messages from ppp are logged by syslog > > (messages|ppp.log) > > What is your OS version ? FreeBSD ultra5.bsdtech.org 6.1-RELEASE-p1 FreeBSD 6.1-RELEASE-p1 #1: Fri Aug 4 23:18:19 WEST 2006 root@ultra5.bsdtech.org:/usr/obj/usr/src/sys/ultra5 sparc64 > Your problem is likely because ppp starts before the syslog daemon, > the initial message fails and then you get nothing anymore. I guessed that much but I still haven't verified the init scripts. -- Joao Barros